Runtime Overview

The execution layer — what deploys, where it runs, how it's isolated.

/runtime is the second pillar: a cloud runtime for open-source trading frameworks. You write the strategy in the framework's own idiom; Superior supplies the machine it runs on, the venue connectivity, and the operational plumbing a laptop can't.

Three resources cover it:

Both take the same core payload — framework, venue, code, config — so the path from research to live is changing one word, not learning a second API.

What a deployment actually gets

• An isolated, sandboxed runtime. Workloads run under gVisor kernel isolation with their own storage. Freqtrade deployments each get their own sandbox; Nautilus deployments run in a per-account runtime shared only by your strategies (Nautilus is built as a multi-strategy node). Isolation between accounts is absolute: your code and credentials are never co-resident with another tenant's.
• A pinned framework. GET /runtime/frameworks lists exact, digest-pinned versions of freqtrade and NautilusTrader. Runs are reproducible; upgrades are explicit, never silent.
• Venue proximity. Runtimes run in the region closest to the venue's infrastructure (/context/venues shows which).
• Lifecycle guarantees. Start, stop, and delete do what they say — and deletion is confirmed, not assumed: DELETE moves the deployment to deleting, and it reads deleted only once the runtime has verified the process is gone and the injected credential destroyed. A deleted deployment cannot keep trading.
• Observability. Logs stream the framework's own output; metrics normalize trades/PnL across frameworks.

What the runtime never does

It never originates transactions outside your strategy's instruction, and it never trades an account you didn't point it at. Custody is your choice per deployment: the default managed trading wallet handles funding, venue onboarding, and withdrawals-to-your-login-wallet for you; with BYOK Superior never holds your key outside the deployment you attached it to, and funding, withdrawals, and custody stay entirely yours.

Reliability — what happens when things break

The reason to move off a laptop is what happens at 3am, so this is spelled out rather than implied:

• Process crash: the runtime restarts the strategy automatically; health.restarts on the deployment GET counts it, so silent crash-loops are visible, not hidden.
• State survives restarts. Freqtrade's trade database and user data live on persistent storage attached to the deployment — after a restart the strategy reloads its open trades and continues managing them; it does not orphan a position it opened before the crash. (This is freqtrade's own persistence model, running on storage that outlives the process.)
• Open positions are never auto-closed by infrastructure. A restart, a stop, or an API outage does not market-close your position. The only things that close positions are your strategy's logic and your explicit instruction.
• Control plane ≠ runtime. If the API is briefly unreachable, running strategies are unaffected — they talk to the venue directly. You lose visibility, not execution.
• When we're at fault, you can see it: runtime_unavailable errors are our side, distinct from anything actionable by you, per the error taxonomy.

Validation before execution

Bad strategies fail at the API, not silently on a server at 3am. POST payloads are validated per framework — freqtrade strategies must compile and subclass IStrategy with the required populate methods; Nautilus configs are checked against the venue's instrument grammar — and errors come back structured, with line references where the framework provides them.