VPS for trading bot: wetin really matter?

Trading bot dey need wetin from VPS

People dey judge VPS for trading bots with four things: process go come back after e die? Clock dey correct? API (application programming interface) keys hard to thief? And you go know when e stop? Raw speed no too high for that list for retail bot, because the slow part for your order path na your broker and the distance go broker, no be host wey dey run your Python.

This na engineering guide. Nothing for here be financial advice, and we no dey discuss any strategy.

Uptime na restart discipline, no be number for sales page

Every host for earth dey advertise 99.9 percent uptime. That figure describe the hypervisor, no be your bot. Bot fit die because of unhandled exception, websocket wey no reconnect, or OOM (out of memory) killer, while the server remain up the whole time. So the useful question na wetin happen for the ten seconds after your process exit.

Run the bot as systemd service and make the init system manage the restart. Unit file fit do this with six lines.

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

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 na the line wey people dey miss. By default, systemd go stop after 5 restarts for 10 seconds and leave the unit for failed state forever. Na exactly this behaviour you no want for 03:00. If you set am to 0, e go disable the rate limit. So bot wey dey crash-loop go continue to try instead of going quiet. RestartSec=10 go stop the loop from hammering the exchange with reconnects.

Check the file before you trust am, then start am:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable na the half wey go survive reboot, and kernel updates mean reboots. To see whether the bot don dey die quietly, ask systemd for the restart counter:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 after one week mean say the bot healthy. NRestarts=812 mean say you don dey trade with process wey reconnect all night. The complete unit file anatomy, including timers for scheduled jobs like daily report, dey covered for running a program as a systemd service.

Set the clock to UTC and prove say e synchronised

Exchange APIs dey sign requests with timestamp and reject anything wey dey outside time window, often 5 seconds or less. Clock wey dey drift dey produce errors wey look like authentication failures, so people fit rotate keys for hours before dem check the time. For Binance-style APIs, the message dey literal: Timestamp for this request was 1000ms ahead of the server's time.

Set the server to UTC. Local time zones fit introduce daylight saving jump wey go happen for middle of trading session.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu dey ship with systemd-timesyncd, wey be SNTP (simple network time protocol) client. E dey okay for logs, but e weak for anything wey need stay within few milliseconds, because e dey poll one server and e no dey discipline the clock continuously. Use chrony instead:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

The line to read from chronyc tracking na System time, for example System time : 0.000031415 seconds fast of NTP time. Anything under few milliseconds healthy. If e read Leap status : Not synchronised, chrony never reach any server yet, usually because outbound UDP 123 dey blocked. Wait one minute, then check again before you touch firewall rules.

Keep API keys away from places wey you dey copy

If exchange key leak, e worse pass SSH key leak, because withdrawal permission fit turn am to money immediately. Two habits fit cover most of the risk.

First, never give bot key withdrawal permission. If the exchange support am, tie the key to your server IP address. Na this control dey make stolen key almost useless.

Second, keep the secret outside the code directory. Anything wey dey inside /opt/tradingbot go enter git repository or backup archive sooner or later. Put am for file wey root own and only systemd dey read:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

The file get plain KEY=value lines, without quotes and without export. Mode 640 with group bot mean say the service user fit read am, but nobody else fit. Verify am with sudo -u bot cat /etc/tradingbot/api.env, then test with another user, where e must fail with Permission denied.

The bot itself no suppose run as root or as your login user. Create system account wey no get shell and no get home directory wey e fit log into:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

The reason for each of those flags, and how far ProtectSystem=strict really reach, dey for running services as an unprivileged user. The remaining server baseline, SSH keys and firewall, belong for the first ten minutes on a new VPS.

Find out say e don go down before your broker find out

systemctl status dey show say process dey run. E no mean say bot dey do anything. Process wey stuck for retry loop against dead websocket go pass every check wey systemd fit do.

Use heartbeat instead. Uptime Kuma get push monitors: e expect your bot to call URL on schedule, and e go alert when the call stop to arrive. Put the call for the end of your main loop, after the part wey prove say bot dey alive, like successful market data read.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Set monitor interval to about twice your loop time, so normal jitter no go trigger page. Run monitor for different server from bot, because monitor wey die together with the thing wey e dey watch no go report anything. Setup dey covered for self-hosted status monitoring with Uptime Kuma.

Add disk alert too. Bot wey dey write verbose logs fit fill root filesystem within weeks, and full disk go stop database write, no be network call, so the symptoms go strange. journalctl --vacuum-time=14d and a SystemMaxUse= line for /etc/systemd/journald.conf go keep the journal bounded.

The honest part: latency mostly no be your host

Na this point market for trading VPS products stop being technical. Marketing pages dey quote sub-millisecond figures and dey imply say na host dey between you and successful fill. For almost every retail bot, e no be so.

Your order dey travel from bot go exchange or broker endpoint through public internet. Physical distance and peering between your provider and their provider mostly determine that path. Server wey dey Frankfurt and dey talk to endpoint for Tokyo go pay roughly 250 milliseconds round trip, no matter how fast the CPU be. Then broker own systems add their queue, risk checks, and rate limits. For retail account, these delays usually dey tens or hundreds of milliseconds.

Measure am instead of guessing. curl dey report connection and first-byte times for real endpoint:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Run that command from candidate server before you commit. If connect na 0.180 seconds, you dey wrong continent, and e make sense to fix that. If connect na 0.004 seconds and ttfb na 0.140 seconds, na broker processing remain as the delay. Changing host no go affect am.

So when host matter? E matter when you dey colocated or cross-connected to the venue and you dey compete for queue position. That one na different business with different budget. E also matter when your own code be the bottleneck. Bot wey dey recompute indicators over full history every tick fit use 200 milliseconds of CPU for each loop. Na real latency wey you fit control at no extra cost. Profile the loop before you shop for faster server.

For the host wey you choose, the things wey matter na geography, stable networking, and enough memory so OOM killer no ever get chance to act. As of July 2026, one Python bot for single strategy with few hundred symbols for memory dey run comfortably with 2 GB of RAM and 2 vCPU. Add more memory if you dey keep tick history for local database.

Checklist wey you suppose run before go live

1. systemctl is-enabled tradingbot dey print enabled, and the service dey survive sudo reboot.
2. chronyc tracking dey report say system time offset dey below some few milliseconds.
3. API key get trading permission, but e no get withdrawal permission. If the exchange support am, set IP allowlist too.
4. If you kill the process with sudo systemctl kill -s SIGKILL tradingbot, e dey come back within RestartSec.
5. Heartbeat monitor dey send page give you within one interval when you deliberately stop the bot.
6. Logs get limit, and root filesystem still get enough free space for df -h.

Run everything for the exchange sandbox or paper mode for one week before you use real funds. Every item above go fail at least once during that week. Na that be the reason for the week.

FAQ

Trading bot need low-latency or bare metal server?

Na only if you dey compete for execution speed against other automated participants for the same venue. Normally, this one mean colocation, no be general purpose VPS. For retail bot, geography and the broker own processing dey determine most of the round trip. So choose server wey dey near the API endpoint, then measure with curl and mtr before you pay for anything faster.

How much RAM and CPU trading bot need?

Most single-strategy bots dey depend on network and dey idle between events. As of July 2026, 2 vCPU and 2 GB of RAM fit handle Python bot wey dey track few hundred instruments. Memory go become the constraint when you keep tick history for process or run local database. So monitor free -h and the journal for OOM kill messages instead of guessing.

Why exchange API dey reject requests with timestamp error?

The server clock don drift pass the exchange signing window, usually by few seconds. Install chrony. Confirm say chronyc tracking dey show small System time offset and synchronised leap status. Set the machine to UTC so daylight saving change no go shift the time. Rotating the API key no go fix clock problem.

How I fit stop my bot from dying overnight without knowing?

Run am under systemd with Restart=always and StartLimitIntervalSec=0, so crash loop go keep retrying instead of stopping permanently. Then add heartbeat wey the bot dey send at the end of every successful loop. Restart dey handle the process. Heartbeat dey catch the case where process still dey alive but don stuck.

I fit run the bot and my monitoring for the same VPS?

You fit, but monitoring go deceive you on the day wey e matter, because outage wey take down the bot go take the monitor down too. Keep alerting for separate machine, preferably with different provider or region. Use the bot server only for the bot and its logs.