Workflow:Nautechsystems Nautilus trader Live trading deployment
| Knowledge Sources | |
|---|---|
| Domains | Algorithmic_Trading, Live_Trading, Exchange_Connectivity |
| Last Updated | 2026-02-10 09:00 GMT |
Overview
End-to-end process for deploying a trading strategy to live markets using the NautilusTrader TradingNode with real exchange adapters.
Description
This workflow covers deploying a NautilusTrader strategy from backtesting to live production trading. The TradingNode orchestrates real-time data feeds, execution clients, risk management, and strategy execution against live exchange venues. The platform supports 13+ exchange adapters (Binance, Bybit, OKX, Interactive Brokers, Kraken, dYdX, Hyperliquid, Polymarket, and others) through a unified adapter interface. The same strategy code used in backtesting runs unmodified in live mode, with the TradingNode handling connection management, order reconciliation, and position state recovery.
Usage
Execute this workflow when you have a backtested strategy ready for live deployment, valid exchange API credentials, and want to trade against real markets. The TradingNode manages the full lifecycle including connection establishment, instrument loading, order state reconciliation on startup, and graceful shutdown with position handling.
Execution Steps
Step 1: Configure the TradingNode
Create a TradingNodeConfig specifying the trader ID, logging configuration, execution engine settings (including reconciliation behavior), and optional infrastructure backends (Redis for caching, PostgreSQL for persistence). Configure connection and reconciliation timeouts.
Key considerations:
- Set reconciliation=True in LiveExecEngineConfig to sync order/position state on startup
- Configure timeout_connection and timeout_reconciliation for exchange-specific latency
- Optionally configure Redis-backed cache for state persistence across restarts
- Set appropriate logging level (INFO for production, DEBUG for troubleshooting)
Step 2: Configure Data and Execution Clients
Specify exchange-specific data client and execution client configurations. Each adapter requires API credentials (key and secret), account type selection, and optional parameters like testnet mode, rate limiting, and instrument filters. Multiple exchanges can be configured simultaneously for cross-venue strategies.
Key considerations:
- API keys can be loaded from environment variables for security
- Each exchange adapter has specific configuration options (e.g., BinanceAccountType.SPOT vs USDT_FUTURE)
- Data clients handle market data subscriptions (ticks, bars, order books)
- Execution clients handle order submission, modification, and cancellation
- Testnet configurations are available for most exchanges
Step 3: Register Client Factories
Register the adapter-specific factory classes that the TradingNode uses to instantiate data and execution clients. Each exchange adapter provides a LiveDataClientFactory and LiveExecClientFactory. This decoupled factory pattern enables the node to manage client lifecycle independently.
Key considerations:
- Each venue requires both a data client factory and an execution client factory
- Factory registration must happen before calling node.build()
- The factory pattern enables runtime adapter selection without code changes
Step 4: Add Strategies and Execution Algorithms
Instantiate strategy objects with their configurations and add them to the TradingNode's trader. Optionally add execution algorithms (such as TWAP) that strategies can delegate order execution to. The strategy configuration specifies which instruments to trade, indicator parameters, and risk limits.
Key considerations:
- The same strategy class used in backtesting works unmodified in live trading
- Execution algorithms like TWAP split large orders into smaller time-weighted slices
- Multiple strategies can run simultaneously across different instruments or venues
- Strategy state can be persisted and recovered across restarts via the cache
Step 5: Build and Run the TradingNode
Call node.build() to initialize all configured components, then node.run() to start the event loop. The node connects to exchanges, loads instruments, reconciles existing orders and positions, starts strategies, and begins processing real-time market data. The node runs until explicitly stopped or a fatal error occurs.
Key considerations:
- build() validates all configuration and instantiates clients via factories
- run() blocks the main thread, running the asyncio event loop
- On startup, the reconciliation engine syncs local state with exchange state
- Instrument providers load available instruments from the exchange
- Use try/finally to ensure node.dispose() is called for clean shutdown
Step 6: Monitor and Manage
While running, the TradingNode processes real-time data events, executes strategy logic, manages orders through the risk engine, and maintains portfolio state. The logging system provides real-time visibility into strategy decisions, order lifecycle events, and system health. Risk limits configured in the RiskEngine gate all outbound trading commands.
Key considerations:
- The RiskEngine enforces configurable limits on order rate, notional size, and position exposure
- Order state is tracked through the full lifecycle (submitted, accepted, filled, cancelled)
- The RetryManager handles transient connection failures with exponential backoff
- Position reconciliation runs periodically to detect and resolve state divergence