Bot Runners: Cloud vs Self-Hosted Crypto Trading Bots

A bot that misses a stop-loss because its container restarted is not just an inconvenience — it can convert a -3% planned exit into a -12% surprise. The hosting model under your bot is the second-most consequential decision in algorithmic trading after the strategy itself, and most traders pick it by accident on day one. This guide walks through the trade-offs between cloud-managed runners and self-hosted infrastructure so you can pick the right model deliberately.

What Is a Bot Runner?

A bot runner is the execution environment where your trading bot's container actually runs. It pulls the Freqtrade image, mounts the trade database, injects encrypted exchange credentials, and exposes the bot's REST and WebSocket endpoints back to the VolatiCloud control plane. In short: the runner is the host, the bot is the guest.

Each runner is responsible for:

• Starting, stopping, and restarting bot containers
• Maintaining persistent state (open positions, trade history, custom tags)
• Exposing the trading engine's API for monitoring and live updates
• Detecting crashes and recovering bots automatically
• Forwarding trade events into VolatiCloud's WebSocket pipeline

In VolatiCloud, every bot is bound to exactly one runner at creation. The runner handles the underlying container orchestration — Docker on a VPS, a Kubernetes pod in a managed cluster, or a shared cloud node managed by VolatiCloud.

Cloud Runners vs Self-Hosted Runners

VolatiCloud supports two deployment models, and they differ on six axes that matter:

Dimension	Cloud Runner	Self-Hosted Runner
Setup effort	Zero — pre-provisioned	Install agent on your own server
Infrastructure cost	Included in plan	Your VPS / dedicated / k8s costs
Data sovereignty	VolatiCloud-managed	Your hardware, your control
Latency to exchange	Region-dependent	Pick your region or co-locate
Maintenance	Managed by VolatiCloud	You patch, update, monitor
Max bot density	Plan-bounded	Bounded by your hardware only

Cloud runners are the fastest path from sign-up to live execution. The infrastructure is already running when you create your account; assigning a bot to a cloud runner adds a container in seconds. VolatiCloud handles health checks, automatic restarts after node maintenance, and capacity scaling behind the scenes.

Self-hosted runners trade convenience for control. You install a small agent on a server you own, the agent registers itself with VolatiCloud over an authenticated WebSocket, and any bot you assign to that runner deploys onto your hardware. This is the right choice when you:

• Run latency-sensitive strategies (scalping, market-making) and need to co-locate near your exchange's matching engine
• Operate in a jurisdiction with data residency or audit-trail requirements
• Run a large bot fleet and want flat compute economics instead of per-bot pricing
• Want to keep exchange API keys inside your own network perimeter
• Already pay for a Hetzner / DigitalOcean / Vultr box and want to use it

Setting Up a Self-Hosted Docker Runner

The minimal self-hosted runner is a single Docker container on a Linux host. You need: Docker 24+, 2 GB RAM (plus ~512 MB per bot you plan to run), and outbound HTTPS access to api.volaticloud.com.

1. Create the runner record in VolatiCloud. Open the console, go to Runners, click New Runner, give it a name like hetzner-fsn1-prod, and select the Self-Hosted (Docker) type.

2. Copy the registration token. VolatiCloud generates a one-time registration token bound to your organization. Treat this like a password.

3. Run the agent. On your server:

   docker run -d \
     --name volaticloud-runner \
     --restart unless-stopped \
     -v /var/run/docker.sock:/var/run/docker.sock \
     -v /data/volaticloud:/data \
     -e RUNNER_TOKEN=your-registration-token \
     volaticloud/runner-agent:latest

4. Verify connectivity. Within ~10 seconds the runner appears as Online in the dashboard with the agent version and last heartbeat. Any bot you now assign to this runner deploys here.

The full step-by-step lives in the Docker runner docs — including TLS, custom Docker socket paths, and air-gapped registries.

tip

Each Freqtrade bot reserves roughly 250–512 MB of RAM under load. On a 4 GB VPS, plan for 5–6 bots maximum after leaving headroom for the host OS. Memory pressure is the most common cause of unexpected bot restarts on shared hardware.

Kubernetes Runners for Bot Fleets

Once you're past 10–15 bots on the same operator, Kubernetes starts paying for itself. The VolatiCloud Kubernetes runner deploys each bot as its own Pod with explicit resource requests and limits, which means:

• One bot's runaway memory usage cannot evict its neighbours
• Rolling upgrades replace bot containers one at a time without downtime
• Pod failures reschedule onto a healthy node automatically
• Resource usage is observable per bot via standard k8s metrics

A typical pod spec looks like this:

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"

Each bot pod gets its own PersistentVolumeClaim for the SQLite trade database, so a pod restart — whether triggered by an upgrade, an OOM kill, or a node drain — never loses open position state. For disaster recovery on top of that, bot database backups to S3 snapshot the SQLite file on a schedule.

Namespace Sharding

At very high bot counts (~hundreds), VolatiCloud automatically shards bot pods across multiple Kubernetes namespaces to stay under per-namespace resource quotas and improve API server throughput. The dashboard shows aggregate counts per shard but the sharding itself is transparent — you never need to assign a namespace by hand. The full controller behavior is documented in the Kubernetes runner guide.

Persistent State and Trade Data

The single most important property of any runner — cloud or self-hosted — is how it handles state. A trading bot's internal database tracks:

• Every open and closed trade with entry / exit prices and fees
• Custom trade metadata (tags, partial-exit notes, strategy-emitted reasons)
• Internal strategy state (last-seen indicator values, cooldown timers)

VolatiCloud persists this database as a SQLite file inside the bot's mounted volume. Container restarts — for an upgrade, after a crash, or following a runner migration — resume the bot with full history intact. The bot does not lose track of an open position because its container restarted.

When migrating a bot from one runner to another, always export the trade database first. VolatiCloud provides a one-click export from the bot's settings page; importing on the new runner avoids the manual reconciliation that would otherwise be required to re-attach the bot to its open positions.

Monitoring Runner Health

Whether your runner sits on VolatiCloud's infrastructure or your own, the dashboard surfaces the same health signals:

• Status indicator — Online, Offline, Degraded
• Bot count — bots currently assigned and running
• Last heartbeat — timestamp of the most recent control-plane ping
• Resource pressure — CPU / memory utilization across bots on this runner

If a self-hosted runner stops sending heartbeats, VolatiCloud raises an alert and marks every affected bot as unhealthy. Critically, the platform does not attempt to execute trades through a disconnected runner — there is no risk of the bot acting on stale market data while you're scrambling to bring the runner back online. The full bot monitoring guide explains how the WebSocket pipeline keeps trade events streaming in real time even when REST polling backs off.

Choosing the Right Setup

For most traders the answer is: start on a cloud runner, migrate when you have a reason. A cloud runner removes every infrastructure concern, lets you focus on the Visual Strategy Builder and backtesting workflow, and gets you to a paper-trading bot in under five minutes.

Move to a self-hosted runner when one of these is true:

• You've validated a strategy through backtesting and a paper-trading window and are deploying meaningful capital
• Latency to your exchange genuinely matters for your edge (sub-second scalping, cross-exchange arbitrage)
• You already pay for a server and adding a Docker container is cheaper than the marginal plan cost
• You're running a multi-bot portfolio and want a single capacity pool you control
• Compliance, audit, or jurisdictional requirements forbid sending order flow through third-party infrastructure

There is no wrong answer, and you do not have to commit. VolatiCloud lets you run some bots on cloud runners and others on self-hosted runners simultaneously — pick the runner per bot.

info

The 7-day free trial includes access to cloud runners with no payment method required. You can deploy a real paper-trading bot, watch live execution, and never enter a credit card unless you decide to continue.

A Practical Migration Path

The cleanest sequencing for someone serious about going live:

1. Build and backtest on a cloud runner. Use the Strategy Builder and backtesting workflow to find a strategy with a defensible edge.
2. Paper-trade on a cloud runner. Validate live behavior against the backtest for at least a few weeks.
3. Provision a self-hosted runner near your exchange. Hetzner Falkenstein for Binance EU, AWS Tokyo for OKX Asia, etc.
4. Deploy the same strategy as a second bot on the new runner. Run cloud and self-hosted side by side for a week.
5. Compare slippage and fill quality. If the self-hosted runner shows measurably better execution, cut over the live capital.

This approach avoids the common mistake of self-hosting on day one — which usually means investing time in infrastructure for a strategy that won't survive its first paper-trading window.

Get Started

If you're new to VolatiCloud, the cloud runner is already there waiting:

1. Create or import a strategy with the Visual Strategy Builder
2. Run a backtest to confirm the strategy has a real edge
3. Create a bot, connect your exchange, and assign it to the default cloud runner
4. Start in dry-run mode to confirm execution is healthy before switching live capital on

If you're a team running self-hosted infrastructure or a Kubernetes cluster, the runner documentation walks through registration, TLS, multi-tenant deployment, and troubleshooting.

Open console.volaticloud.com — cloud runners are ready the moment you create your first bot.