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; Binance is coming soon. 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
IStrategysubclass, samepopulate_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 inconfig. - 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 | Live and paper deployments run in venue-proximate regions with clean egress |
config.json holds your keys in plaintext | Managed wallet credentials today; BYOK injection is coming soon |
| 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. Use the managed wallet — the default managed trading wallet needs no key handling at all: deposit USDC and skip to step 4. Bringing your own account with BYOK is coming soon.
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#
- Configure the public exchange name and pairs under
config.exchange; the runtime injects only the credential-backed connection details. Never put secrets in that block — it will be rejected as a credential-in-config violation. - Copy the
framework_symbols.freqtradeform from/context/marketsinto both runtime backtestsymbolsandconfig.exchange.pair_whitelist(e.g.BTC/USDC:USDCon Hyperliquid). Ifsymbolsis omitted, the runtime derives it frompair_whitelist; if both are present, they must match exactly. - Managed backtest runners deny all network egress and read their market data from the mounted Superior dataset. Custom pairlist handlers and external data fetches therefore cannot run during a managed backtest.
- Live and paper deployments are a separate workload: gVisor isolates them and blocks cluster-internal and private networks, while general outbound HTTPS is currently permitted. External dependencies remain unsupported and may be restricted in a future hardening pass; a third-party outage can still fail a deployment at runtime.