Strategy Versioning and Forking for Algorithmic Traders
You spend three days tuning an RSI mean-reversion strategy. The Sharpe ratio is finally where you wanted it. You change one parameter to test a hunch, hit save — and now the working version is gone, and you can't remember exactly what made it work. Every algorithmic trader has lived this moment. VolatiCloud's immutable strategy versioning makes it impossible: every save creates a new version, nothing is overwritten, and live bots stay pinned to the exact version they were created against.
Why Version Control Matters for Trading Strategies
Software developers take version control for granted — git means lost work is rare and recoverable. Traders editing strategies in spreadsheets, plain Python files, or platforms that overwrite on save have no equivalent safety net. A single misclick can erase days of tuning, and there's no way to compare "the version that made money" against "the version that didn't."
For algorithmic trading specifically, immutable versioning solves three concrete problems:
Backtest integrity. When you look at a backtest result six months later, you need to know exactly which strategy configuration produced it. Without immutable versions, the saved result and the current code can silently diverge — the chart says one thing, the live code does another.
Bot stability. A live bot running Version 3 should not change behavior because you saved Version 4 in another tab. It shouldn't even know Version 4 exists. Position sizing, exit logic, and indicator parameters must stay frozen for the lifetime of that bot's deployment.
Safe experimentation. Fear of breaking something that works is the single biggest reason traders stop iterating. When every save is non-destructive and every version is recoverable, you experiment freely.
How Immutable Versioning Works in VolatiCloud
Every time you click Save in the Strategy Studio, VolatiCloud:
- Freezes the current code and configuration as a new immutable version
- Increments the version number automatically (Version 1, 2, 3, …)
- Marks the new version as latest — surfaced in strategy lists and used as the default for new bots
- Leaves every existing bot running its previously-pinned version, untouched
The flow looks like this:
Version 1: RSI < 30 entry, RSI > 70 exit
↓ (save)
Version 2: Added EMA(200) trend filter
↓ (save)
Version 3 [LATEST]: Tuned RSI thresholds to 25/75
Versions 1 and 2 are locked. A bot deployed on Version 2 runs Version 2 forever — even after you save Version 3, Version 4, or Version 10. To switch a bot to a newer version, you create a new bot or explicitly update the bot's configuration. This is deliberate: a live bot's behavior should never change without a conscious decision.
What the Strategy Version History Shows You
From the strategy detail page, the Version History panel lists every version in reverse chronological order. Clicking a version reveals its full configuration — UI Builder logic nodes for visual strategies, raw Python for code-mode strategies. The full UI is documented in the strategy versioning docs.
More usefully, each version shows aggregated backtest statistics across every backtest you've run on it:
| Metric | What It Tells You |
|---|---|
| Best Profit | Peak performance across all backtests of this version |
| Worst Profit | Downside scenario — central to risk assessment |
| Average Profit | Typical performance, smoothed across configurations |
| Win Rate | Percentage of profitable trades |
| Max Drawdown | Worst peak-to-trough decline, averaged across backtests |
| Trade Count | Total trades — useful for statistical significance |
This answers "which version performs best?" at a glance, without re-running backtests or hunting through notes. Version 2 might post a higher average profit than Version 3 but a worse drawdown — that's exactly the kind of trade-off this view surfaces in seconds.
Run at least one backtest after each significant save. The version history statistics are only as useful as the backtest coverage behind them — a version with zero backtests gives you nothing to compare.
Backtests Are Bound to a Specific Strategy Version
A backtest is always tied to a specific strategy version — not to the strategy itself. Run a backtest on Version 2, then save Version 3, and that backtest still belongs to Version 2. The Version 3 entry in the version history starts with zero backtests until you run one.
This binding is intentional. The point is that you can look at any backtest result and know exactly what code produced it. If backtests floated freely between versions, that guarantee — and the comparative tables above — would silently break.
The discipline this encourages: save → backtest → compare → save again. The running backtests guide covers the full workflow. Each cycle produces a clean paper trail of what you tried and what it produced.
When to Fork Instead of Iterate
Versioning handles incremental refinement — you're tweaking the same strategy. But sometimes you want to rewrite the entry logic from scratch, or branch a long-only strategy into a long/short variant that will evolve separately. That's what forking is for.
A fork creates a completely new strategy with its own version chain. The fork starts as an exact copy of the source's current latest version. From that moment, changes to the fork don't affect the original, and changes to the original don't affect the fork. Both retain their full version history; the fork records its lineage so you can always trace back.
| Situation | Use Versioning | Use Forking |
|---|---|---|
| Tweaking RSI period from 14 to 20 | yes | |
| Adding an EMA filter to an existing signal | yes | |
| Rewriting entry logic from scratch | yes | |
| Creating a short variant of a long strategy | yes | |
| Sharing a strategy with a teammate | yes | |
| Adapting a BTC strategy for ETH | yes | |
| Building a long/short mirror-mode variant | yes |
The diagnostic question: are these the same strategy or different strategies? If you want to compare their backtest results in isolation and run separate bots on each, fork. If one is just a refined version of the other, save a new version. The strategy forking docs cover the fork lineage UI in detail.
A Disciplined Iteration Workflow
Here's what a clean iteration cycle looks like end to end:
1. Start from a working baseline. Confirm your current version has at least one backtest you trust. That number is your control — what each subsequent change has to beat.
2. Make one change at a time. Adjust the RSI period and the stoploss percentage simultaneously, see performance improve, and you have no idea which change drove it. Change one thing, save, backtest. Then the next thing.
3. Use version history to compare. After a handful of versions, the version history panel gives you a comparative view. Version 4 might have better average profit but Version 3 might have lower drawdown — the right choice depends on your risk tolerance and position sizing.
4. Fork for radical experiments. Trying a new indicator combination, an entirely different timeframe, or a complete rewrite of exit logic? Fork first. Your working version stays intact while you experiment freely on the fork.
5. Run hyperopt on the best structural version. Once you've identified a version with strong logic, hyperparameter optimization finds optimal parameter values within that structure. Each hyperopt run produces a new backtest result you can compare in the version history.
Fork Lineage and Team Workflows
Every forked strategy maintains a reference to its source. On the strategy detail page, you can see:
- Which strategy it was forked from
- Which version of that strategy was the fork point
- When the fork was created and by whom
This creates a traceable lineage. Six months on, looking at a strategy and wondering where the initial logic came from, the fork source tells you. In team settings, this is essential — multiple traders forking each other's work would otherwise turn into untraceable copies.
If a teammate forks your strategy and improves it, they can share the fork back with the team (by setting it to public) without modifying your original. Your bot keeps running the original; the fork goes through its own testing in parallel. The team management post covers shared resources and role-based access in detail.
Forking is available on Pro and Team plans. On the free tier, you can still create multiple independent strategies manually — you just won't have the automated fork with lineage tracking.
Versioning in Practice: A Real Iteration
A condensed example of how the system supports a single week of work:
- Monday. Build an EMA crossover strategy in the Visual Strategy Builder. Save → Version 1. Backtest on BTC/USDT 4h, 90 days. Sharpe 0.6.
- Tuesday. Add an RSI overbought filter on entries. Save → Version 2. Backtest. Sharpe 0.9, drawdown improved by 4%.
- Wednesday. Try a different EMA pair (12/26 instead of 20/50). Save → Version 3. Backtest. Sharpe drops to 0.4 — Version 2 was better.
- Thursday. Run hyperopt on Version 2 over the EMA periods and RSI threshold. Best result becomes a new backtest under Version 2's history.
- Friday. Deploy a paper-trading bot pinned to Version 2. Save Version 4 with experimental exit logic — your live paper bot keeps running Version 2 untouched.
That's six saves, four versions, multiple backtests per version, and a paper-trading bot running an explicitly-chosen version. None of it required manual file management.
The Bigger Picture
Immutable versioning feels like a quality-of-life improvement until the day it saves you from a costly mistake. When you accidentally tune away a profitable configuration, when a bot behaves unexpectedly and you need to audit which version was running, when you want to prove to yourself that Version 6 is genuinely better than Version 3 — versioning turns those moments from panic into straightforward lookups.
Combined with Monte Carlo simulation and hyperparameter optimization, versioning gives you a rigorous, evidence-based path through strategy development. Each version has its own backtest record. Each backtest is locked to a specific configuration. The history is always there when you need it.
Ready to try it? Sign in to console.volaticloud.com and open any strategy — the Version History panel is on the detail page. If you haven't built up multiple versions yet, follow the iteration cycle above and start the track record.