Looking for a User App or Add-On built by the NinjaTrader community?

Visit NinjaTrader EcoSystem and our free User App Share!

Have a question for the NinjaScript developer community? Open a new thread in our NinjaScript File Sharing Discussion Forum!
See more
See less

Partner 728x90


Really efficient way to synchronise VPS and Local NT strategies and indicators

  • Filter
  • Time
  • Show
Clear All
new posts

    Really efficient way to synchronise VPS and Local NT strategies and indicators

    I have found a very efficient way to keep synchronization between my VPS strategies and indicators folder and my PC folders,

    the reason I have done this is because I get sick of manually moving files between my PC and VPS and it is also very tedious to have to use visual studio on my VPS to make small changes to code, the mouse delay etc make this very time consuming.

    I wanted to be able to just make edits on my PC and have those edits auto sync to my VPS Ninjatrader 8 documents folder.

    here is what I have done.

    1. I Cut and pasted my Custom > Strategies folder and Custom > Indicator folder into onedrive (i do not sync my documents folder)

    2. I used Link Shell Extension to create a folder Junction so that the folders in my one drive are the source folders and then dropped the link folders into my Ninjatrader 8 > Custom folder

    3. I did the same thing on my VPS so now my desktop and VPS both use the onedrive strategy and indicator folders as the source

    now I can edit my files or folders from any app or device that I want an my changes will be synced almost instantly all my NT8 platforms

    I also got an IDE app on android so now I can code from my phone by opening the file in onedrive.

    The dangerous potential downside is that if you are running an active strategy and you edit it on one PC, it will instantly be edited on the PC that is trading live;

    for this reason and many others I always create a "Live trading 'v1.0'" version of a strategy when i make it go live, this version is never edited or opened under any circumstance to avoid tragedy.

    if I want to edit a system that is live I do it from my original file.

    hope this helps others who are sick of the tedium of running multiple platforms on multiple machines.
    Last edited by BurnOutTrader; 06-12-2022, 04:48 AM.

    as an observation, the ninjatrader slave wont actually auto compile so you have the safety measure of having to manually compile in code editor after any changes to the source folder.

    you also cant have the file open in code editor on the slave platform or the compile wont update from the newer file, this means if you want to protect a file such as a live system just leave it open in code editor on the slave.

    if all files are closed and you compile the slave the updates will be in effect as standard operation.
    Last edited by BurnOutTrader; 06-11-2022, 10:51 PM.


      That's outstanding!
      (I did something extremely similar using Dropbox.)


      I have an additional idea that might help you with versioning.

      I solved the production vs development strategy using a major version
      number tacked onto the end of the class name and filename.

      For example, if Red_01.cs was the production strategy, then Red_02.cs
      was the development version -- and the class names in the respective
      strategy source files would reflect Red_01 and Red_02, as necessary.

      The beauty of Red_01 and Red_02 having separate filenames and
      strategy class names
      is that they can run together, at the same time,
      on the same machine.

      For ex, while Red_01 trades the live account, Red_02 can be tested
      using Sim101 on the same production VPS machine, using the same
      real time data.

      As soon as Red_02 is moved into production, make a copy, call it
      Red_03.cs, then update the Strategy class name to Red_03, and
      the development-to-production editing cycle repeats.

      The code for strategy in production is always frozen, new edits and
      changes always go into the next 'N+1' version, which is always the
      current development version.

      This is a real boon for migrating updates into production, and it's
      a simple way to maintain some version control and historical file
      backups for your changes.

      In fact, I decided to use a single version number (no minor numbers
      dotted after the major number) -- so really high version numbers
      (like, for ex, Red_59.cs and Red_342.cs) are real possibilities.

      This idea effectively follows the example set by newer Chrome and Firefox
      versioning -- just use a single number -- then increment as necessary.

      The really masterful part of this idea is incorporating that single version
      number into the strategy filename and strategy class name -- that kind
      of naming convention can offer some real organizational improvements.


      Latest Posts


      Topics Statistics Last Post
      Started by 309338, Today, 12:06 PM
      0 responses
      Last Post 309338
      by 309338
      Started by AaronKoRn, Yesterday, 08:38 PM
      2 responses
      Last Post NinjaTrader_ChrisL  
      Started by rocketstock, 08-05-2022, 09:36 PM
      2 responses
      Last Post NinjaTrader_ChrisL  
      Started by ronyggg83, Yesterday, 03:48 PM
      4 responses
      Last Post NinjaTrader_ChelseaB  
      Started by preqc, 08-05-2022, 09:10 AM
      1 response
      Last Post NinjaTrader_Jim