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.

:::danger[Jupyter notebooks not recommended for live trading] Do not run live trading nodes in Jupyter notebooks. Event loop conflicts and operational risks make them unsuitable:

• Jupyter runs its own asyncio event loop, which conflicts with TradingNode's event loop.
• Workarounds like nest_asyncio are not production-grade.
• Cells can run out of order, kernels can crash, and state can disappear.
• Notebooks lack the logging, monitoring, and graceful shutdown needed for production trading.

Use Jupyter for backtesting, analysis, and experimentation. For live trading, run nodes as standalone Python scripts or services. :::

:::warning[One TradingNode per process] Running multiple TradingNode instances concurrently in the same process is not supported due to global singleton state. Add multiple strategies to a single node, or run additional nodes in separate processes for parallel execution.

See Processes and threads for details. :::

:::warning[Do not block the event loop] User code on the event loop thread (strategy callbacks, actor handlers, on_event methods) must return quickly. This applies to both Python and Rust. Blocking operations like model inference, heavy calculations, or synchronous I/O cause missed fills, stale data, and delayed order submissions. Offload long-running work to an executor or a separate thread/process. :::

:::info[Platform differences] Windows signal handling differs from Unix-like systems. If you are running on Windows, please read the note on Windows signal handling for guidance on graceful shutdown behavior and Ctrl+C (SIGINT) support. :::

TradingNodeConfig

TradingNodeConfig inherits from NautilusKernelConfig and adds live-specific options. For background on how config structs handle defaults and Option<T> semantics, see the Configuration concept guide.

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

Rust-native live systems keep cache behavior in CacheConfig and Redis connection settings in RedisCacheConfig.

use nautilus_common::{
    cache::{CacheConfig, database::CacheDatabaseFactory},
    enums::SerializationEncoding,
};
use nautilus_infrastructure::redis::cache::RedisCacheConfig;

let config = CacheConfig {
    encoding: SerializationEncoding::MsgPack,
    timestamps_as_iso8601: true,
    buffer_interval_ms: Some(100),
    flush_on_start: false,
    ..Default::default()
};

let database = RedisCacheConfig {
    host: Some("localhost".to_string()),
    port: Some(6379),
    username: Some("nautilus".to_string()),
    password: Some("pass".to_string()),
    connection_timeout: 2,
    response_timeout: 2,
    ..Default::default()
};

let cache_database = database
    .create(trader_id, instance_id, config.clone())
    .await?;

MessageBus configuration

Message bus behavior stays in MessageBusConfig. Redis connection settings live in RedisMessageBusConfig, which constructs the backing through MessageBusBackingFactory.

use nautilus_common::{
    enums::SerializationEncoding,
    msgbus::{backing::MessageBusBackingFactory, config::MessageBusConfig},
};
use nautilus_infrastructure::redis::msgbus::RedisMessageBusConfig;

let config = MessageBusConfig {
    encoding: SerializationEncoding::Json,
    timestamps_as_iso8601: true,
    use_instance_id: false,
    types_filter: Some(vec!["QuoteTick".to_string(), "TradeTick".to_string()]),
    stream_per_topic: false,
    autotrim_mins: Some(30),
    heartbeat_interval_secs: Some(1),
    ..Default::default()
};

let backing = RedisMessageBusConfig {
    connection_timeout: 2,
    response_timeout: 2,
    ..Default::default()
};

let message_bus_backing = backing.create(
    trader_id,
    instance_id,
    config.clone(),
)?;

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,
            environment=BinanceEnvironment.LIVE,
        ),
        "BINANCE_FUTURES": BinanceDataClientConfig(
            account_type=BinanceAccountType.USDT_FUTURES,
            environment=BinanceEnvironment.LIVE,
        ),
    },

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

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.

:::note[Order tagging behavior] Reconciliation tags orders by origin:

• VENUE tag: external orders discovered at the venue (placed outside this system).
• RECONCILIATION tag: synthetic orders generated to align position discrepancies.

When filter_unclaimed_external_orders is enabled, only VENUE-tagged orders are filtered. RECONCILIATION-tagged orders are never filtered, so position alignment always succeeds. :::

Continuous reconciliation

Continuous reconciliation keeps runtime execution state aligned after startup by checking in-flight orders, polling open orders, checking position status, and auditing own order books. Configure the loop with these settings. For runtime state-transition rules, retry coordination, and caveats, see Runtime checks.

:::warning

• open_check_lookback_mins: do not reduce below 60 minutes. A short window triggers false "missing order" resolutions because orders fall outside the query range.
• open_check_threshold_ms: increase if venue timestamps lag the local clock, so recently updated orders are not marked missing prematurely.
• reconciliation_startup_delay_secs: do not reduce below 10 seconds in production. The delay lets the system stabilize after startup reconciliation before continuous checks begin.

:::

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

:::warning Windows: asyncio event loops do not implement loop.add_signal_handler. As a result, TradingNode does not receive OS signals via asyncio on Windows. Use Ctrl+C (SIGINT) handling or programmatic shutdown; SIGTERM parity is not expected on Windows. :::

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()