Run Freqtrade in the Cloud

Move a local freqtrade bot to a managed runtime without changing the strategy.

You have a freqtrade strategy that works — and a laptop that sleeps, a home IP the exchange throttles, or a VPS you'd rather not babysit. This guide moves that exact bot to Superior Trade's managed runtime. The strategy file does not change.

Two scope facts up front, so you don't read ten minutes to learn them: freqtrade on Superior currently targets Hyperliquid and Binance — if your bot trades Kraken, Bybit, or another exchange, the runtime can't host it yet (the venue matrix is the live list). And the runtime executes live/paper strategies; hyperopt and FreqAI training jobs aren't part of the deployment surface today — validate and tune locally, deploy the result. Pricing: a Free tier exists (3 deployments); see Plans.

What carries over unchanged

Your strategy class. The same IStrategy subclass, same populate_indicators / populate_entry_trend / populate_exit_trend, same imports (talib.abstract as ta, qtpylib).
Your config keys. timeframe, stake_amount, max_open_trades, pair_whitelist, ROI/stoploss tables — passed through in config.
Freqtrade itself. The runtime runs the official freqtrade image at a pinned version, not a fork. Behavior you tested locally is behavior you get.

What Superior replaces

Local problem	Runtime answer
Machine must stay awake	Managed process, restarts on failure, `health.restarts` visible
Residential IP throttling / geo-blocks	Venue-proximate regions with clean egress
`config.json` holds your keys in plaintext	BYOK injection, destroyed on delete
Logs on a box you have to SSH into	`GET …/logs` over the API
"Is it still running?"	`GET /runtime/deployments/:id` from anywhere

The move, step by step

1. Backtest on our data first — same code, POST /runtime/backtests. This validates that the runtime's data and your local results agree before anything runs live.

2. Paper-deploy — "mode": "paper" with your real config. Let it run a few days; compare its entries to your local dry-run.

3. Choose the credential path — the default managed trading wallet needs no key handling at all: deposit USDC and skip to step 4. Bringing your own account instead (BYOK)? For Hyperliquid, create an agent wallet and send that key; for Binance, a trade-only API key. Never the master credential.

4. Go live — "mode": "live", then PUT /runtime/deployments/:id/status with { "action": "start" }. Set alive_until for a bounded first run — a bot that stops itself on schedule is a feature, not a failure. Check status, tail logs, read metrics.

5. Retire the local bot once fills line up. Or don't — nothing here locks you in; the same file still runs anywhere freqtrade does.

Differences to expect

The runtime injects exchange connection details into freqtrade's config (exchange section) from your attached credentials — don't ship an exchange block with secrets in config; it will be rejected as a credential-in-config violation.
Pairs in pair_whitelist use the framework_symbols.freqtrade form from /context/markets (e.g. BTC/USDC:USDC on Hyperliquid).
Strategies run under gVisor kernel isolation and are blocked from cluster-internal and private networks; general outbound HTTPS is currently permitted, so custom pairlist handlers and external data fetches work — but they're unsupported, invisible to our monitoring, and may be restricted in a future hardening pass. A strategy that depends on a third-party API fails at runtime if that API misbehaves, exactly as it would on your VPS.