Run NautilusTrader in the Cloud

Deploy Nautilus strategies against Polymarket, Lighter, and Hyperliquid.

NautilusTrader is the highest-performance open trading framework in Python — and the hardest to self-host well: it wants stable low-latency connectivity, correct venue adapters, and a process supervisor that understands its lifecycle. Superior runs it as a managed runtime with venue adapters already wired.

Where it runs

Instrument IDs come from /context/markets — use the framework_symbols.nautilus form verbatim in your strategy config (the top-level symbol is the canonical id for /context reads).

Deploying

Same surface as everything else — framework: "nautilus":

{
  "framework": "nautilus",
  "venue": "polymarket",
  "mode": "live",
  "alive_until": "2026-08-02T00:00:00Z",
  "name": "fed-cut-mispricing",
  "code": "from nautilus_trader.trading.strategy import Strategy\n\nclass FedCutMispricing(Strategy):\n    …",
  "config": {
    "instrument_ids": ["512329.POLYMARKET"],
    "trade_size_usd": 50
  }
}

Validation checks the strategy imports cleanly, the instrument IDs match the venue's grammar, and the config satisfies the venue adapter's requirements — failures return the diagnostic, not a generic 400.

How config maps to Nautilus: Nautilus strategies take a typed StrategyConfig class. The runtime constructs your strategy's config object from the config JSON by field name — declare instrument_ids and trade_size_usd (or whatever your config class defines) as fields on your StrategyConfig subclass, and the JSON keys are passed into it verbatim. Fields your config class doesn't declare are rejected at validation (config_invalid names the key), so a typo can't silently become a default.

Backtesting a Nautilus strategy is the same resource as freqtrade, with resolved-market data on Polymarket:

POST /runtime/backtests:

{
  "framework": "nautilus",
  "venue": "polymarket",
  "code": "<your Strategy subclass>",
  "config": { "instrument_ids": ["512329.POLYMARKET"], "trade_size_usd": 50 },
  "range": { "from": "2026-03-01", "to": "2026-06-30" }
}

Polymarket credentials: the wallet_address + private_key you attach are your Polymarket trading wallet — the wallet whose USDC.e funds your positions (for most Polymarket users, the proxy wallet their account operates through). Fund only that wallet; your main wallet never enters the system, per the BYOK rules.

Multi-strategy tenancy

Nautilus deployments from the same account run inside a shared, isolated per-account runtime — Nautilus is built for multi-strategy nodes, and this keeps per-strategy overhead low. Each deployment is still individually startable, stoppable, and deletable; isolation between accounts is absolute.

Research loop for prediction markets

Polymarket strategies get a two-step loop for now: backtest against resolved-market history (odds path + resolution), then a small, alive_until-bounded live run with your own wallet key — paper mode is freqtrade-only at launch (paper_supported: false on Nautilus venues), so the bounded live run is the rehearsal step. Resolved-market datasets — which markets are backtest-ready — are flagged per market in /context/markets (backtest_ready).

Honest current state

Nautilus support is newer than freqtrade support. The venue adapters (Polymarket, Lighter) are production; the public strategy-template library is thin. If you're porting an existing Nautilus strategy you're in good shape; if you're starting from zero, start from the freqtrade path or the templates in the leaderboard until the Nautilus template set fills out. This paragraph will change; the design log tracks it.