Trading bot VPS hosting: run a bot 24/7 the right way

Why your laptop is the wrong place to run a bot

The moment your bot is supposed to react to the market without you, your personal machine becomes a liability. Laptops are built to save power — they sleep when the lid closes, they suspend network adapters, they reboot themselves at 3am to install an update. Every one of those is a window where your bot is unconscious. If the entry signal you waited weeks for fires while the lid is shut, the bot doesn't "catch up" — it simply missed it.

Home internet is the second weak link. A flaky Wi-Fi connection or an ISP hiccup will throw API errors, drop an order mid-flight, or leave the bot unsure whether its last request actually landed. A bot that loses connectivity at the wrong second can end up with a position it thinks it doesn't have, or vice versa. And the human factor is real too: you close the laptop to go out, the battery dies, a family member shuts it down. None of that is acceptable for software that is managing money around the clock. A bot's whole value is being awake when you aren't — so it has to live somewhere that is always awake.

What a VPS actually is

A VPS — virtual private server — is a slice of a larger physical server in a data center, rented to you as if it were your own little Linux machine. It has its own CPU allocation, RAM, disk and IP address, and it runs continuously on industrial power and networking with proper cooling and redundancy. You connect to it over SSH, install your bot, and walk away. Unlike your laptop, it has no lid to close, no battery to die, and no reason to sleep. That is the entire point: it is a computer whose only job is to stay on.

For an automated trading bot this is exactly the right tool. You don't need a desktop, a screen or a GUI — you need a small, reliable box with a stable internet connection that runs your trading bot 24 hours a day and restarts it if anything goes wrong. A VPS is the cheapest, simplest way to get that.

How to size the box — smaller than you think

This is where beginners overspend. A typical retail bot is tiny. It wakes up, fetches a handful of candles over a REST call, runs a few lines of math, maybe places an order, and then sleeps until the next interval. For most of every hour it is doing nothing at all. A single bot like that barely registers on a CPU graph.

So a 1–2 vCPU box with 1–2 GB of RAM is plenty for the great majority of retail bots — and the entry tier at most providers is exactly that. You do not need a beefy multi-core server unless you are running many bots at once, holding large in-memory datasets, or doing live machine-learning inference. The real resource hog is almost never compute; it's logging and data. Verbose logs, stored tick history and backtests run on the same box will eat disk and memory long before your strategy stresses the CPU. Size for storage and a little RAM headroom, keep your logs rotating, and run heavy backtests somewhere else.

Choose a region close to your exchange

When you spin up a VPS you pick a region — the city or country where the data center sits. The simple guideline is to choose one geographically near your exchange's matching engine. Doing so shaves tens of milliseconds off every API round-trip, which makes order placement feel snappier and reduces the chance of a stale price between decision and execution.

But keep this honest: retail timeframe strategies do not need colocation. If your bot trades on five-minute or hourly candles, a 40-millisecond latency difference is utterly irrelevant to your edge — the candle hasn't even closed. Co-located, microsecond-chasing infrastructure belongs to high-frequency firms, not to a moving-average bot. Pick a sensible nearby region for tidiness and a small comfort margin, then stop thinking about latency and go spend that energy on your risk rules instead.

Linux setup basics — do this before the bot

Start from a fresh Linux box and harden it before a single line of bot code lands. The defaults are not safe for something that holds exchange API keys. The non-negotiable basics are short and they matter more than anything fancy:

• Create a non-root user and run the bot as that user. Never run a trading bot as root — a bug or a bad dependency then has the keys to the whole machine.
• Use SSH key login, not passwords. Generate a key pair, install the public key, then disable password authentication entirely. Passwords get brute-forced; keys effectively don't.
• Turn on a firewall and allow only what you need — typically just SSH. Everything else stays closed.
• Enable automatic security updates so the OS patches known vulnerabilities without you remembering to.

Keep the bot alive with a process manager

Starting your bot by hand in an SSH session is a trap — close the terminal and it dies, and a reboot leaves it down for good. Instead, hand it to a process manager whose entire job is to keep it running: relaunch it if it crashes, and start it again automatically when the server reboots. You have three solid choices — a systemd service (built into Linux, nothing to install), pm2 (popular for Node bots), or Docker with a restart policy. They all achieve the same thing; pick the one you're comfortable with.

Here's a minimal systemd unit that runs the bot as a non-root user and restarts it on any failure or reboot:

systemd · /etc/systemd/system/tradingbot.service[Unit]
Description=Trading bot
After=network-online.target

[Service]
User=botuser                 # not root
WorkingDirectory=/home/botuser/bot
ExecStart=/home/botuser/bot/.venv/bin/python bot.py
Restart=always               # relaunch on crash
RestartSec=5                   # wait 5s, avoid hammering the API

[Install]
WantedBy=multi-user.target   # start on boot

Enable it once with systemctl enable --now tradingbot and the bot now survives crashes and reboots. If you prefer Node, pm2 start bot.js --name bot followed by pm2 startup and pm2 save gives you the same auto-restart-on-reboot behaviour. With Docker, --restart unless-stopped does the equivalent at the container level. The mechanism is interchangeable; the rule is not: the bot must come back by itself.

Logging, alerts, security and backups

Auto-restart keeps the bot running, but you still need to know when something went wrong. Write structured logs to a file (and let systemd's journal capture stdout), and rotate them so they don't fill the disk. More importantly, wire up an alert — a Telegram message, an email, anything — that fires when the bot errors, when it can't reach the exchange, or when it restarts unexpectedly. A bot that crashes and quietly restarts in a loop while you sleep is worse than one that simply stops, because you never find out. Make failure loud.

On security, the single most important rule lives off the server: the API keys you put on that VPS must be trade-only, never withdrawal-enabled, and IP-whitelisted to the box. If the server is ever compromised, the attacker can place trades but cannot drain your funds to their wallet. We cover this in full in trading bot API key security — read it before you paste a key anywhere. Finally, back up your config: keep your strategy parameters, environment file template (without the secrets) and unit files in version control or a copy off the box, so rebuilding the whole thing after a failure is a ten-minute job, not a forensic reconstruction from memory.

The cost reality is the happy part. All of this — the always-on box, the stable network, the 24/7 uptime — runs for roughly the price of a couple of coffees a month at the entry tier most retail bots need. Hosting is rarely the expensive part of automated trading; the strategy and the discipline are. Once your bot is built and your rules are set, see how it stacks up against managed services in best trading bot platforms 2026, or size your trades first with the position-size calculator.

Frequently asked questions