Configure a Live Trading Node

Set up a TradingNode for live market connectivity. For background on live trading architecture and reconciliation, see the Live trading concept guide.

TradingNodeConfig

TradingNodeConfig inherits from NautilusKernelConfig and adds live-specific options:

from nautilus_trader.config import TradingNodeConfig

config = TradingNodeConfig(
    trader_id="MyTrader-001",

    # Component configurations
    cache=CacheConfig(),
    message_bus=MessageBusConfig(),
    data_engine=LiveDataEngineConfig(),
    risk_engine=LiveRiskEngineConfig(),
    exec_engine=LiveExecEngineConfig(),
    portfolio=PortfolioConfig(),

    # Client configurations
    data_clients={
        "BINANCE": BinanceDataClientConfig(),
    },
    exec_clients={
        "BINANCE": BinanceExecClientConfig(),
    },
)

Core configuration parameters

Cache database configuration

from nautilus_trader.config import CacheConfig
from nautilus_trader.config import DatabaseConfig

cache_config = CacheConfig(
    database=DatabaseConfig(
        host="localhost",
        port=6379,
        username="nautilus",
        password="pass",
        timeout=2.0,
    ),
    encoding="msgpack",  # or "json"
    timestamps_as_iso8601=True,
    buffer_interval_ms=100,
    flush_on_start=False,
)

MessageBus configuration

from nautilus_trader.config import MessageBusConfig
from nautilus_trader.config import DatabaseConfig

message_bus_config = MessageBusConfig(
    database=DatabaseConfig(timeout=2),
    timestamps_as_iso8601=True,
    use_instance_id=False,
    types_filter=[QuoteTick, TradeTick],  # Filter specific message types
    stream_per_topic=False,
    autotrim_mins=30,  # Automatic message trimming
    heartbeat_interval_secs=1,
)

Multi-venue configuration

A node can connect to multiple venues. This example configures both spot and futures markets for Binance:

config = TradingNodeConfig(
    trader_id="MultiVenue-001",

    # Multiple data clients for different market types
    data_clients={
        "BINANCE_SPOT": BinanceDataClientConfig(
            account_type=BinanceAccountType.SPOT,
            testnet=False,
        ),
        "BINANCE_FUTURES": BinanceDataClientConfig(
            account_type=BinanceAccountType.USDT_FUTURES,
            testnet=False,
        ),
    },

    # Corresponding execution clients
    exec_clients={
        "BINANCE_SPOT": BinanceExecClientConfig(
            account_type=BinanceAccountType.SPOT,
            testnet=False,
        ),
        "BINANCE_FUTURES": BinanceExecClientConfig(
            account_type=BinanceAccountType.USDT_FUTURES,
            testnet=False,
        ),
    },
)

ExecutionEngine configuration

LiveExecEngineConfig controls order processing, execution events, and venue reconciliation. For full details see the API Reference.

Reconciliation

Recovers missed order and position events to keep system state consistent with the venue.

See Execution reconciliation for details.

Order filtering

Controls which order events and reports the system processes, preventing conflicts across trading nodes.

Continuous reconciliation

A background loop starts after startup reconciliation completes. It:

• Monitors in-flight orders for delays exceeding a configured threshold.
• Reconciles open orders with the venue at configurable intervals.
• Audits internal own order books against the venue's public books.

The loop waits for startup reconciliation to finish before starting periodic checks. The reconciliation_startup_delay_secs parameter adds a further delay after startup reconciliation completes, giving the system time to stabilize.

When retries are exhausted, the engine resolves the order as follows:

In-flight order timeout resolution (venue does not respond after max retries):

Order consistency checks (when cache state differs from venue state):

Retry coordination and lookback behavior

The inflight loop and open-order loop share a single retry counter (_recon_check_retries), bounded by inflight_check_retries and open_check_missing_retries respectively. The stricter limit wins, and avoids duplicate venue queries for the same order state.

When the open-order loop exhausts retries, the engine issues one targeted GenerateOrderStatusReport probe before applying a terminal state. If the venue returns the order, reconciliation proceeds and the retry counter resets.

Single-order query protection: the engine caps single-order queries per cycle via max_single_order_queries_per_cycle (default: 10). Remaining orders are deferred to the next cycle. A configurable delay (single_order_query_delay_ms, default: 100ms) spaces out consecutive queries to avoid rate limits. This handles bulk query failures across hundreds of orders without overwhelming the venue API.

Orders older than open_check_lookback_mins rely on this targeted probe. Keep the lookback generous for venues with short history windows. Increase open_check_threshold_ms if venue timestamps lag the local clock, so recently updated orders are not marked missing prematurely.

Additional options

Memory management

Periodically purges closed orders, closed positions, and account events from the in-memory cache, keeping memory bounded during long-running or HFT sessions.

Setting an interval enables the purge loop; leaving it unset disables scheduling and deletion. Database records are unaffected unless purge_from_database is true. Each loop delegates to the cache APIs described in Cache.

Queue management

Strategy configuration

For a complete parameter list see the StrategyConfig API Reference.

Identification

Order management

Windows signal handling

On Windows, asyncio event loops do not implement loop.add_signal_handler, so Unix-style signal integration is unavailable. TradingNode does not receive OS signals via asyncio on Windows and will not stop gracefully unless you intervene.

Recommended approaches:

• Wrap run with try/except KeyboardInterrupt and call node.stop() then node.dispose(). Ctrl+C raises KeyboardInterrupt in the main thread, giving you a clean teardown path.
• Publish a ShutdownSystem command programmatically (or call shutdown_system(...) from an actor/component) to trigger the same shutdown path.

The "inflight check loop task still pending" message appears because the normal graceful shutdown path is not triggered. This is tracked as #2785.

The v2 LiveNode already handles Ctrl+C via tokio::signal::ctrl_c() and a Python SIGINT bridge, so runner and tasks shut down cleanly.

Example pattern for Windows:

try:
    node.run()
except KeyboardInterrupt:
    pass
finally:
    try:
        node.stop()
    finally:
        node.dispose()