The Problem
Quant traders need a single code base that can back‑test strategies on historical market data and run the same logic live with minimal friction. Switching between a research environment and production often requires duplicated code, divergent dependencies, and manual re‑writes, which introduces bugs and latency.
What This Does
nautilustrader delivers a Rust‑centric core that implements an event‑driven engine for order management, market data ingestion, and risk checks. The core lives in the crates/ workspace; adapters (e.g., crates/adapters/architectax and crates/adapters/binance) translate exchange‑specific protocols into the common engine interfaces.
Key files:
crates/adapters/architectax/src/lib.rs – the primary library exposing the public API for the Architect‑AX exchange. crates/adapters/binance/src/common/sbe/.rs – generated SBE codecs for Binance spot and futures messages. Cargo.toml and crates/Cargo.toml – define the workspace and inter‑crate dependencies.
The platform also ships a Docker environment (.docker/DockerfileUbuntu, .docker/docker-compose.yml) that bundles the Rust binaries, a JupyterLab front‑end, and optional Python bindings (exposed via src/python/.rs).
How To Use It
Setup
Clone and enter the repo
git clone https://github.com/nautechsystems/nautilustrader.git cd nautilustrader
Build the Rust workspace
cargo build --release
Or spin up the provided Docker stack
docker compose -f .docker/docker-compose.yml up --build
The Makefile includes shortcuts (make build, make test) that wrap the above commands; inspect it for exact targets.
Configuration
Copy .env.example to .env and fill in required API keys (e.g., ARCHITECTAXAPIKEY, BINANCEAPIKEY). Adapter‑specific JSON fixtures in crates/adapters//testdata/ illustrate the expected request/response schema. Runtime parameters (log level, market data subscriptions) are read from the config.yaml located under .config/ (if present) or passed as CLI flags.
Running
The entry point for a live strategy is the binary produced by the nautilustrader crate (defined in the workspace root). After a successful cargo build, launch it with:
./target/release/nautilustrader --config .config/config.yaml
When using Docker, the service starts automatically under the nautilustrader container defined in docker-compose.yml. Logs are exposed on port 8080 (configurable).
Real‑World Use
A quant team can embed a Python strategy module that calls the Rust API via the pyo3 bindings in src/python/mod.rs. Example workflow:
from nautilustrader import Engine
engine = Engine(configpath="config.yaml") engine.loadstrategy("mystrategy.py") engine.start()
The engine consumes live Binance market data (via the Binance adapter), executes the Python strategy each tick, and routes orders back through the same adapter, preserving identical logic used during back‑testing.
Code Health & Issues
Low – Missing top‑level README for building the core binary – The repo documents Docker usage but does not explicitly list a cargo run command for the main engine. Medium – Adapter test coverage uneven – architectax has dedicated tests/http.rs and tests/websocket.rs; the Binance adapter only includes fixture JSON without corresponding Rust test modules. Low – Secrets in repository – No API keys are committed, but the .env.example hints at required env vars; ensure production keys are never added. Low – License duplication – Each adapter contains its own LICENSE file; while not a functional bug, it adds maintenance overhead. Low – CI pipelines present – Multiple GitHub Actions (build.yml, codeql-analysis.yml, coverage.yml) are configured and the repository includes a Cargo.lock, indicating reproducible builds.
Overall the codebase follows Rust conventions, includes pre‑commit hooks for style and safety (checktokiousage.sh, checkerrorconventions.sh), and ships a comprehensive Docker development stack.
The Bottom Line
nautilustrader offers a solid, Rust‑based engine with exchange adapters and optional Python bindings, making it suitable for teams that need high‑throughput back‑testing and live deployment without rewriting strategy code. The primary gaps are sparse documentation around the core binary launch and uneven test coverage across adapters; addressing these will smooth onboarding for new users.