NautilusTrader: a Rust-native trading engine with Python as the control plane

What NautilusTrader is for, and who it is actually aimed at

The README frames the problem in one sentence: strategy research usually happens in Python with vectorised code, while production trading systems get rewritten separately in a compiled language with an event-driven design. NautilusTrader exists to remove that second rewrite. A Rust core provides the event-driven runtime; Python is described as the control plane for strategy logic, configuration and orchestration. The README also notes that trading systems can be written entirely in Rust for what it calls mission-critical workloads. The intended user is therefore not a discretionary trader clicking buttons. It is someone who already writes Python, wants the same strategy object to run in a backtest and in live execution, and is willing to learn a specific component model (strategies, adapters, a cache, a message bus) to get that. The topics list spans crypto, equities, FX, futures, options and sports betting, and the workspace Cargo.toml contains adapter crates for venues including binance, bybit, coinbase, databento, deribit, dydx, hyperliquid, interactive_brokers, kraken, okx, polymarket, tardis and betfair. Coverage is broad, but breadth is not the same as uniform depth; the adapter list is the first thing to check against your own venue.

The architecture: a Rust event loop with Python on top

The workspace in Cargo.toml is the clearest map of the design. The engine is split into crates such as core, model, data, execution, backtest, live, portfolio, risk, indicators, persistence, network, serialization, event_store and pyo3, with adapters under crates/adapters and a testkit crate. That separation matters because it tells you where behaviour lives. Market data and order events flow through the core; execution and portfolio crates track state; persistence can write that state out, and the README mentions optional Redis-backed state persistence. The pyo3 crate is the bridge that exposes the Rust engine to Python. The README states that the same strategy and execution-algorithm code can run across backtest and live systems, which is the intended benefit, and then adds a caveat in the same breath: live execution introduces venue, transport, timing, persistence, external-activity and reconciliation behaviour that a simulation may not reproduce, pointing to a Backtest and live differences page in the docs. That caveat is the honest part of the pitch. Determinism is a property of the engine's event ordering, not a guarantee that your live fills will match your simulated ones. Backtesting is described as supporting multiple venues, instruments and strategies at once, using quote ticks, trade ticks, bars, order books and custom data at nanosecond resolution.

Installing NautilusTrader and running a first backtest

The README does not print an installation command in the section shown here; it points to the docs at nautilustrader.io/docs, and the badges indicate a package on PyPI named nautilus_trader. The supported matrix in the README lists Python 3.12 to 3.14 and Rust 1.98.1 across Linux x86_64, Linux ARM64, macOS ARM64 and Windows x86_64. Note the absence of macOS x86_64 and of any Python below 3.12. If you intend to build the Rust crates yourself, the workspace pins edition 2024 and rust-version 1.98.1, and there is a rust-toolchain.toml at the repository root, so a toolchain manager will pick up the pinned version. The repository also ships a .env.example that documents a single variable, and it is worth copying because the data catalog location is derived from it:

cp .env.example .env

The file explains that NAUTILUS_PATH should point to the root directory containing your Nautilus data, and that the catalog will be automatically located at NAUTILUS_PATH/catalog. Backtest data therefore has a conventional home rather than being passed around as loose files. For a first real use, the repository keeps runnable code under examples/, with subdirectories for backtest, live, other, quickstarts and tutorials, plus an examples/README.md. The README does not reproduce a full example program, so the honest instruction is to open examples/quickstarts first and run one of those rather than to copy a snippet from the front page. Docker is listed as a deployment option, and the Makefile defines IMAGE, REGISTRY and IMAGE_FULL variables built from the project path and the current git branch, which is how the maintainers tag container images.

Where NautilusTrader stops being the right tool

The README is explicit that live execution carries venue, transport, timing, persistence, external-activity and reconciliation behaviour a simulation may not reproduce. That is not a small print disclaimer; it means a backtest that looks clean can still diverge in production, and the reconciliation machinery exists precisely because reality drifts from the model. Second, the release history is a constraint. The most recent releases listed are v2.0.0rc4 and v2.0.0rc3, release candidates, with v1.231.0 marked Beta before them. A release candidate on the default develop branch is a statement about API stability, and the repository carries a MIGRATION_V2.md file, which tells you that moving between major versions is a documented task rather than a non-event. Third, the LGPL-3.0-only licence in Cargo.toml is a real consideration if you ship a modified engine inside a closed product; the repository also has a CLA.md, a TRADEMARK.md and a SECURITY.md, so the project treats legal and security process as first-class. Finally, if your research style is vectorised and you want a backtest expressed as a few lines over a DataFrame, the event-driven model is overhead you will pay for and not use. This engine rewards people who want execution realism, not people who want a quick signal study.

How it compares with QuantConnect LEAN and vectorised backtesting stacks

The most common comparison in search data is against LEAN, and the difference is architectural rather than cosmetic. LEAN is C#-first with a hosted cloud product around it, and its strategy model is built around that ecosystem. NautilusTrader is Rust-first with Python as the control plane, and it is designed to be run by you, on your machines, with adapters in the same repository. That means you own the deployment, the data catalog and the persistence layer, and you get the engine's determinism without a platform in between. Against a vectorised backtesting library, the trade is the opposite: a pandas-style backtest is faster to write and easier to iterate on, but it does not execute the same code path as live trading. NautilusTrader's claim is that it does, with the caveat above about live differences. A reasonable split is to prototype signals in a vectorised tool and move to an event-driven engine once an idea needs order-book data, multiple venues, or execution instructions such as IOC, FOK, GTC, GTD, DAY, AT_THE_OPEN and AT_THE_CLOSE, post-only, reduce-only, icebergs, and contingency orders like OCO, OUO and OTO. Those order semantics are where a simple backtester stops being adequate.

Maintenance, releases and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-10, so the codebase is being worked on. That is a statement about activity, not about API stability. The version in Cargo.toml is 0.64.0 for the Rust workspace while the published Python packages are at 2.0.0rc4, so the two version lines do not move together, and anyone tracking both needs to read RELEASES.md rather than assume a single number. The repository also ships MIGRATION_V2.md, which is the concrete upgrade cost: a major-version move has its own document. For day-to-day work, the maintenance burden is mostly environmental. The README pins Rust 1.98.1 and Python 3.12 to 3.14, and the Makefile pulls pinned versions of a long list of Cargo tools (cargo-audit, cargo-deny, cargo-nextest, cargo-llvm-cov, cargo-vet and others) through scripts/cargo-tool-version.sh. Building from source means matching that toolchain. On licensing, the workspace declares LGPL-3.0-only and the repository includes LICENSE, CLA.md and TRADEMARK.md. The practical point is that LGPL obligations attach to distribution and modification of the library, so if you plan to embed a modified engine in a product you ship, read those files and take your own advice; this is not a legal opinion.

Editorial conclusion

Adopt NautilusTrader if you already write Python strategies and want one event-driven code path shared by backtest and live runs across several venues, and if you can accept the current 2.0.0 release candidates and the LGPL-3.0-only licence. Do not adopt it if you need a drag-and-drop strategy builder, or if your workflow is vectorised research where a backtest is a few lines of pandas. Before committing, verify three things: which Python versions your target branch supports, whether your venue has an adapter in crates/adapters, and whether your deployment can meet the LGPL-3.0-only terms for the way you distribute software. If you only need to check one thing, check the adapter list.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. nautechsystems/nautilus_trader on GitHub
3. Project website
4. README
5. Releases