How to Deploy a Trading Strategy to Run 24/7

Writing a strategy that fires the right orders is the easy part. The hard part is keeping it alive at 3 a.m. when your process crashes, your token expires, or the venue rate-limits you. Prediction markets on Polymarket and Kalshi trade around the clock, so a bot that only runs while your laptop is open is a bot that misses fills and, worse, holds positions it can no longer manage. Here are the real options for running continuously and the operational failures each one has to survive.

Option 1: a plain VPS with a process supervisor

The default answer is a small always-on Linux box: a $5 to $10 VPS from any provider, running your bot as a supervised service. On modern distributions that supervisor is systemd. The point of running under systemd instead of just launching python bot.py in a terminal is that it treats your bot as a managed service. It can start on boot, restart on failure, and be monitored through the standard tooling.

The one line that matters is the restart policy. With Restart=always in the unit file, systemd keeps the process running after unexpected exits: if it exits unexpectedly, systemd starts it again for you.

[Unit]
Description=Trading bot
After=network-online.target

[Service]
ExecStart=/usr/bin/python3 /opt/bot/strategy.py
Restart=always
RestartSec=10
EnvironmentFile=/etc/bot/env
User=bot

[Install]
WantedBy=multi-user.target

One catch worth knowing: systemd has a start-rate limit enabled by default. If a service crashes more than five times within ten seconds (the defaults for StartLimitBurst and StartLimitIntervalSec), systemd stops attempting restarts and marks the unit failed. A bot that crashes on startup repeatedly can hit this ceiling quickly, and you are back to a dead bot with no alert. Tune StartLimitBurst and StartLimitIntervalSec in the [Unit] section alongside RestartSec, and never assume Restart=always means always without testing a crash loop. You read state with journalctl -u your-bot, which is where you go first when something failed and you need to know why.

A VPS gives you full control and a persistent process, which is what most order-book strategies actually want. The cost is that you own patching, monitoring, and the on-call pager.

Option 2: serverless, and why it usually does not fit

Serverless functions look tempting: no server to patch, pay per invocation. But they are built for short, stateless work. AWS Lambda, for example, is capped at a maximum execution timeout of 15 minutes per invocation, and Lambda is explicitly designed for short-lived compute tasks that do not retain or rely on state between invocations.

That model fights a trading bot in two ways. First, a strategy that maintains a live websocket to the order book cannot sit inside a function that gets forcibly terminated at the 15-minute mark. Second, position state has to live somewhere external, because the function forgets everything between runs. You can make serverless work for a poll-and-decide strategy triggered on a schedule, say checking a market every minute and placing an order, but the moment you need a persistent connection or fast reaction to book changes, you are pushed toward a long-running container or VM anyway. That is the exact path many teams take, moving off Lambda to a container service like Fargate specifically to escape the 15-minute limit.

Option 3: containers and managed runtimes

In between the bare VPS and serverless sits the container: a Docker image with your bot and its dependencies, run on a managed scheduler that restarts it, ships logs, and lets you roll new versions without SSHing into a box. This is the sane middle ground for most people who want reproducible deploys without hand-managing an OS.

A managed strategy runtime goes one step further and folds the trading-specific operations into the platform. Banger is built for this: you run banger run strategy.py, and the runtime handles the supervised process, the paper-trading harness, and the risk envelope, so 'keep it alive' and 'do not let it blow up' are the same system rather than two you bolt together. Banger never custodies funds; you bring your own venue keys, which keeps the secrets question (below) squarely under your control.

The operational concerns that actually break bots

Where you host matters less than whether you have handled these four things. Most blown-up bots failed on one of them, not on strategy logic.

• Restarts and recovery: assume the process will die mid-session. On restart, the bot must reconcile against the venue: what orders are open, what positions do I hold, before it places anything new. A bot that restarts and re-sends yesterday's orders is worse than one that stays down.
• Idempotency: give every order a client-generated ID and dedupe on it. If a restart or a retried request causes the same order to be sent twice, the client ID lets the venue reject the duplicate instead of doubling your position.
• Secrets: never bake API keys into the image or commit them to the repo. Inject them at runtime through environment variables or a secrets manager, scope them to the minimum permissions the venue allows, and rotate them. A leaked trading key is a direct path to your balance.
• Monitoring and a kill switch: a silent bot is not a healthy bot. You want a heartbeat, alerts on errors and on missed cycles, and a hard kill switch plus a daily loss stop that halts trading automatically. Discovering a runaway loop from your account balance is the expensive way.

Choosing

For a persistent order-book strategy, a supervised process on an always-on box, whether a raw VPS, a container, or a managed runtime, beats serverless. Reserve serverless for scheduled poll-and-decide logic that is genuinely stateless. Whichever you pick, paper-trade the full deploy first, including a forced crash and restart, so you find the reconciliation and idempotency bugs against a live book instead of against your money. The hosting choice is reversible. A double-sent order at 3 a.m. is not.