---
title: Run NautilusTrader in the Cloud
description: 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

| Venue | Instruments | Status |
|---|---|---|
| Hyperliquid | perps (`BTC-PERP.HYPERLIQUID`) | supported now |
| Polymarket | binary outcome markets (`512329.POLYMARKET`) | live Nautilus backtests; paper unsupported |
| Lighter | perps + spot (`SOL-PERP.LIGHTER`) | live Nautilus backtests; paper unsupported |

Instrument IDs come from [`/context/markets`](/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](/context/leaderboard) as a starting point.