NautilusTrader: A Rust Event Engine With Python as the Control Plane
Production-grade Rust-native trading engine with deterministic event-driven architecture
At a glance
- What is it?
- NautilusTrader puts a compiled, event-driven trading core under Python strategy code so the same strategy can be backtested and traded live. The design is coherent and the constraints are real: LGPL-3.0, a 2.0 release candidate on the develop branch, and a documented gap between simulation and live behaviour.
- Who is it for?
- Adopt NautilusTrader if you already write event-driven strategies and need one codebase for backtest and live, with Rust owning the runtime and Python owning strategy logic. Do not adopt it if you want vectorized research, since the README explicitly positions it against that workflow, or if you cannot accept LGPL-3.0 obligations in a distributed product.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The split NautilusTrader was built to remove
The README names the problem directly: strategy research is often done in Python with vectorized approaches, while production trading systems are built separately as event-driven systems in compiled languages. That split means two implementations of the same idea, and two places for them to disagree. NautilusTrader's answer is to keep one event-driven runtime for research and live execution, written in Rust, and to let Python act as the control plane for strategy logic, configuration and orchestration. The intended audience is therefore not someone exploring an idea in a notebook. It is someone who already thinks in events, orders and fills, and who wants the backtest and the live deployment to share code rather than share intent. The README also states that trading systems can be written entirely in Rust for mission-critical workloads, so Python is the default control plane, not a hard requirement.
What actually runs where: Rust core, Python control plane
The architecture described in the README is a Rust-native core providing a deterministic event-driven runtime, with Python layered on top for composition. The core uses tokio for asynchronous networking and the mimalloc allocator, both named in the features list. Portability is stated for Linux x86_64 and ARM64, macOS ARM64 and Windows x86_64, with Rust 1.98.1 and Python 3.12 through 3.14 as the supported versions in the platform table. Customisation is exposed through two documented concepts: the cache and the message bus, which the README links as the pieces you assemble a system from if you do not want the default components. That is the real shape of the project. It is not a strategy library with a runner attached. It is a message-passing engine with adapters, and the strategy is one participant among several. The README's own framing of the nautilus shell, modular chambers growing along a logarithmic spiral, is decorative, but the modularity claim underneath it is structural: adapters, components and execution algorithms are separate units that talk over the bus.
Getting a strategy onto the engine
The README does not reproduce install commands, so the concrete entry points it does give are the two distribution channels implied by its badges: a crate on crates.io (nautilus-core is the crate referenced in the rustc and crates.io badges) and a PyPI package named nautilus_trader. The docs live at nautilustrader.io/docs and are the place to confirm the exact install line, because the README itself does not state one. What the README does pin down is the version surface you will be writing against. The develop branch is the default, and the most recent release listed is v2.0.0rc4 from 2026-09-02, preceded by v2.0.0rc3 and, before the 2.0 line, v1.231.0 Beta. Three branches are maintained in parallel: master, nightly and develop, each with its own version file and build status. For a project at a release candidate, that branch structure is the practical detail that matters. Pinning to a release candidate on develop is a different risk posture from pinning to the v1.231.0 Beta line, and the README gives no migration guide between them.
Order semantics the engine commits to
The feature list is specific about execution behaviour, which is where a trading engine either holds up or does not. Time in force covers IOC, FOK, GTC, GTD, DAY, AT_THE_OPEN and AT_THE_CLOSE. Execution instructions include post-only, reduce-only and icebergs. Contingency orders cover OCO, OUO and OTO. Backtesting is described as supporting multiple venues, instruments and strategies at once, over historical quote ticks, trade ticks, bars, order books and custom data, at nanosecond resolution. That list is the contract you are adopting. If your strategy depends on a contingency type the engine does not model, you will be encoding it yourself in strategy code, which puts the logic outside the execution path and outside whatever the engine does deterministically. The README does not claim universal venue coverage; it says any venue with a REST API or WebSocket feed can be integrated through modular adapters, and that current integrations span crypto exchanges including CEX and DEX, traditional FX, equities, futures and options, and betting exchanges. The word can is doing work there. An adapter for your venue may exist, or you may be writing one.
Where the backtest stops being the live system
The README is unusually direct about this, and it is the limitation worth reading twice. The same strategy and execution-algorithm code can run across backtest and live systems, which reduces deployment divergence. But the project then states that live execution still introduces venue, transport, timing, persistence, external-activity and reconciliation behaviour that a simulation may not reproduce, and links to a section titled Backtest and live differences. So the honest reading is that NautilusTrader narrows the gap between research and production by removing the rewrite, not by promising that a passing backtest predicts live behaviour. Anyone adopting this for live trading needs to treat that documentation section as required reading rather than an appendix. The second constraint is state. Persistence is described as optional and Redis-backed, which means a process that dies without that configured has whatever recovery behaviour the engine provides by default, and the README does not spell that out. The third is the release candidate status itself. A v2.0.0rc4 on the default branch is a moving target, and the README offers no stability guarantee for it.
The alternative: vectorized research with a separate production stack
The workflow NautilusTrader is arguing against is the common one: research in Python using vectorized operations over arrays or dataframes, then a production system written separately in a compiled language. That approach is genuinely better at some things. Vectorized research iterates faster on parameter sweeps, because you are operating on whole arrays rather than replaying an event stream, and it needs no venue adapters, no message bus and no order state machine. The cost is the one the README identifies: two implementations, and the divergence between them. The difference in approach is not speed, it is where the abstraction sits. Vectorized research abstracts over time; NautilusTrader abstracts over events, and makes you pay for that abstraction with adapters, a cache, a bus and a persistence layer you have to configure. If your strategy is a cross-sectional signal evaluated on a schedule, the event-driven machinery is overhead you are carrying for a live path you may not need. If your strategy reacts to order book changes across several venues at once, the vectorized version of it is a fiction, and the event engine is the more honest model.
Licence and the cost of staying current
NautilusTrader is LGPL-3.0. That matters more here than for a typical library, because the README describes two deployment shapes: Python strategies running against the engine, and systems written entirely in Rust. Linking against an LGPL library imposes obligations that differ depending on how you link and whether you distribute the result, and those obligations are a question for your own counsel, not something this article can settle. What can be said plainly is that the licence is not permissive, and a team that has standardised on MIT or Apache-2.0 dependencies will need to make a deliberate decision rather than a default one. On maintenance, the repository shows three maintained branches, a version file per branch, and a release cadence that moved from v1.231.0 Beta to v2.0.0rc3 and v2.0.0rc4 within roughly six weeks. That cadence is a cost. You are tracking a project that is actively changing its major version, and the README gives no deprecation policy or upgrade path between the 1.x and 2.x lines. Budget for reading release notes before every upgrade, and pin your version rather than following develop.
Editorial conclusion
Adopt NautilusTrader if you already write event-driven strategies and need one codebase for backtest and live, with Rust owning the runtime and Python owning strategy logic. Do not adopt it if you want vectorized research, since the README explicitly positions it against that workflow, or if you cannot accept LGPL-3.0 obligations in a distributed product. Before committing, verify the 2.0.0rc4 API surface against the v1.231.0 Beta line you may already depend on, and read docs/concepts/live.md#backtest-and-live-differences, because the project itself states that live execution introduces venue, transport, timing, persistence, external-activity and reconciliation behaviour that a simulation may not reproduce.
Community notes