View Markdown

Run NautilusTrader in the Cloud

Deploy Nautilus strategies against the supported venue matrix.

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. Hyperliquid supports live execution and backtests; Lighter and Polymarket support live Nautilus backtests.

Where it runs#

VenueInstrumentsStatus
Hyperliquidperps (BTC-PERP.HYPERLIQUID)supported now
Polymarketbinary outcome markets (512329.POLYMARKET)live Nautilus backtests; paper unsupported
Lighterperps + spot (SOL-PERP.LIGHTER)live Nautilus backtests; paper unsupported

Instrument IDs come from /context/markets — use the framework_symbols.nautilus form verbatim in both runtime backtest symbols and your strategy config's instrument_ids (the top-level symbol is the canonical id for Context and dataset reads).

Deploying#

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

json
{
  "framework": "nautilus",
  "venue": "hyperliquid",
  "mode": "live",
  "alive_until": "2026-08-02T00:00:00Z",
  "name": "btc-nautilus-live",
  "code": "from nautilus_trader.trading.strategy import Strategy\n\nclass BtcNautilusLive(Strategy):\n    …",
  "config": {
    "instrument_ids": ["BTC-PERP.HYPERLIQUID"],
    "trade_size_usd": 50
  },
  "credentials": { "type": "managed" }
}

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:

POST /runtime/backtests:

json
{
  "framework": "nautilus",
  "venue": "hyperliquid",
  "symbols": ["BTC-PERP.HYPERLIQUID"],
  "code": "<your Strategy subclass>",
  "config": { "instrument_ids": ["BTC-PERP.HYPERLIQUID"], "trade_size_usd": 50 },
  "range": { "from": "2026-03-01T00:00:00Z", "to": "2026-06-30T00:00:00Z" }
}

Backtests for Lighter and Polymarket use the live managed credential path. BYOK remains coming soon.

Hyperliquid results include funding in total_pnl, ending_balance, and the equity curve, and expose it separately as funding_pnl. Per-trade profit_abs, win/loss counts, and win rate remain price-and-fee metrics and intentionally exclude funding; trade_pnl_model records that attribution explicitly.

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 are supported for live Nautilus backtests. Nautilus paper deployments are not supported for Polymarket or Lighter; use a live backtest to validate the strategy before considering deployment options.

Honest current state#

Nautilus support is newer than freqtrade support. Hyperliquid supports live execution and backtests; Lighter and Polymarket support live Nautilus backtests, but Nautilus paper deployments are unsupported for both. BYOK remains coming soon. If you're starting from zero, use the templates in the leaderboard as a starting point.