Live Deployment

Live deployment runs a compiled .rqc strategy in a dedicated trading session connected to Tradovate. Demo and Live use CME data for the same real-time strategy market-data path; the selected Tradovate account determines only where orders are routed and where account, order, position, and fill state comes from. Tradovate is not a RoboQuant market-data source.

This is the native RoboQuant Engine workflow. The production TradingView webhook connector is a separate product and deployment path; these native plan limits do not change its behavior.

Current live scope

Architecture

Deployments UI
      ↓
Backend creates a deployment job
      ↓
Worker starts an isolated trading pod with the .rqc artifact
      ↓
CME market data → compiled strategy → order-management engine → Tradovate execution
      ↓
Orders, positions, account P&L, logs, and status → Redis
      ↓
Backend WebSocket → Deployment detail

Each session gets an isolated pod and session ID. A stable deployment identity groups redeployments of the same strategy, account, symbol, timeframe, and broker so its durable track record can continue across sessions.

Before deploying

Confirm that:

1. The .rq source compiles and a current .rqc artifact exists.
2. The strategy has completed a realistic backtest with the intended parameters and costs.
3. A Tradovate account of the correct type—Demo or Live—is connected.
4. The deployment symbol and timeframe match what the strategy expects.
5. Contract sizing and risk limits fit the connected account.
6. A multi-symbol artifact is not selected; live sessions currently trade one symbol.

Deploy from the dashboard

From Strategies → select a strategy → Deploy:

1. Click New deployment.
2. Select a Tradovate Demo or Live mode and a matching connected account.
3. Choose a CME symbol and timeframe.
4. Set the order size and strategy parameters.
5. Set maximum order size, maximum position size, the order-rate limit, and a daily-loss limit.
6. For Live, type the displayed confirmation phrase.
7. Start the deployment and wait for status to become Running.

The deployment form reads the real Tradovate account balance before launch. This balance anchors live sizing and the equity baseline; RoboQuant does not silently fall back to the backtest's starting capital when the broker balance cannot be read.

Plan allowances

Demo and Live accounts share the connection allowance. Each enabled sub-account counts separately, even if several share one Tradovate login. RoboQuant lists the accounts exposed by that login; when they exceed your allowance, choose which to enable in Accounts.

Demo and Live native deployments share the deployment allowance. Each native deployment runs one strategy on one account and one symbol. A saved strategy does not consume a slot, and saved strategies have no plan-based count limit. The standalone TradingView webhook connector has its own subscription and execution behavior; RoboQuant 2.0 connection and native deployment allowances do not govern that product.

Starting, running, paused, degraded, halted and stopping pods occupy a slot until they terminate. Connection and deployment limits apply to new admissions. Existing enabled accounts and running bots remain usable after a downgrade or rollout, even above the current allowance. Adding or enabling an account requires room in the connection allowance; starting another deployment requires room in the deployment allowance. Having excess existing connections does not by itself block a new deployment when a deployment slot is available. Closing positions, cancelling orders and stopping bots remain available regardless of plan allowances.

Running the same strategy on multiple accounts

Native multi-account fan-out—one deployment copying trades to several accounts—is not currently supported on any RoboQuant 2.0 plan. The former Ultra-only “Multi-account fan-out across Tradovate” pricing label was inaccurate.

Create a separate deployment for each account instead. Elite includes three concurrent native deployments, so the same strategy can run on three accounts. Ultra includes seven concurrent native deployments across its twenty available connection slots. Demo and Live share deployment slots. Each deployment runs independently with its own sizing, risk controls and execution state; identical fills are not guaranteed.

The standalone production webhook connector is separate from this native deployment workflow.

Duplicate deployment protection

RoboQuant prevents two live pods from running the same strategy/account/symbol/timeframe/broker identity at once. This protects against duplicate orders and mixed trade history. The same strategy can run on a different account as a separate deployment, within the plan's slot allowance.

Stopping cancels working orders and flattens the bot's position (closes it) before the pod terminates. Wait for that shutdown to finish before redeploying the same identity. This duplicate guard is separate from the plan's slot limit; the old blanket five-session cap no longer applies.

Demo vs Live

The old generic Paper mode is no longer used. Tradovate Demo is the paper-trading path because it exercises the same account, contract, and order semantics as Live. Market data remains CME in both modes.

Tradovate prop-firm accounts use the same execution connection as personal accounts when the authorized login exposes them and the account permits API execution. Choose the actual Demo or Live environment for the account; a prop firm's “funded” label alone does not determine which API environment it uses. Confirm the firm's current automation rules and account agreement before deploying.

Safety controls

Compiled deployments include controls outside strategy code:

• Broker reconciliation at startup — the engine reads cash, net liquidation value, and the open position from Tradovate before it starts processing new signals.
• Maximum order size — rejects an entry that exceeds the configured contract count.
• Maximum position size — blocks an order that could exceed the allowed net exposure.
• Order-rate limit — supported by the deployment API and enforced before orders reach the broker.
• Daily-loss halt — when the configured dollar loss is reached, the engine cancels working orders, flattens, and halts the session.
• Exchange-resident protection — stop loss, take profit, and trailing protection are maintained at the broker where supported.
• Trap/stop flattening — a fatal strategy failure or an explicit stop cancels working orders and flattens the position.
• Broker-truth equity — the live equity stream is periodically corrected from Tradovate's account values rather than relying only on the latest market-data mark.
• Position mismatch guard — transient broker reads do not create phantom closes; reconciliation waits for repeated mismatches.

Risk-limit exits are exempt from entry caps so the engine can always reduce or close an existing position.

Parameters and code updates

Deployment parameters are applied when the .rqc session is created. A running compiled session does not hot-swap parameters.

To change code or parameters:

1. Stop the current deployment.
2. Edit the .rq source if needed.
3. Save and compile a fresh .rqc artifact.
4. Start a new deployment with the desired parameter values.

This makes the deployed artifact and its configuration explicit. Editing a source file does not mutate a pod that is already trading.

Live monitoring

Click a deployment row to open its detail view. The WebSocket stream carries:

The detail view provides Overview, Chart, Trades, and Logs views. Strategy ctx.log(...) messages are sent to both the live stream and pod logs.

Status meanings

The pod exposes /live for liveness and /ready for readiness. A halted or degraded engine remains live so Kubernetes does not restart it into trading, while readiness fails until the engine is running or paused.

Troubleshooting

Related docs

• Strategies — compile the artifact that gets deployed
• Backtesting — validate the same artifact first
• Runtime reference — live-supported hooks and methods