VPS for Trading Bot: Wetin Really Matter?

Wetin trading bot need from a VPS

Dem dey judge VPS for trading bots by four things: whether the process go come back after e die, whether the clock dey correct, whether e hard to steal the API (application programming interface) keys, and whether you go know when e stop. Raw speed dey far down that list for retail bot, because the slow part for your order path na your broker and the distance to am, no be the host wey dey run your Python.

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

Uptime na restart discipline, e no be number for sales page

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

Run the bot as systemd service and make the init system control the restart. Unit file fit do this for 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 dey give up after 5 restarts for 10 seconds and leave the unit for failed state forever. Na exactly this behaviour you no want at 03:00. Set am to 0 to disable the rate limit, so bot wey dey crash-loop go keep trying instead of going quiet. RestartSec=10 dey 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 dey healthy. NRestarts=812 mean say you don dey trade with process wey dey reconnect all night. The full unit file anatomy, including timers for scheduled jobs like daily report, dey covered for running a program as systemd service.

Set clock to UTC and prove say synchronised

Exchange APIs dey sign requests with timestamp and dey reject anything wey pass a time window, often 5 seconds or less. Clock wey dey drift dey cause 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 dey introduce daylight saving jump wey go happen inside trading session.

sudo timedatectl set-timezone UTC
timedatectl

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

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

The line wey you need 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 reads 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.

API keys wetin you dey copy

Exchange key wey leak bad pass SSH key wey 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, bind the key to your server IP address. Na this control dey make stolen key almost useless.

Second, keep the secret commot from the code directory. Anything wey dey inside /opt/tradingbot go enter git repository or backup archive sooner or later. Put am inside file wey root own and only systemd fit 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, and nobody else fit. Verify am with sudo -u bot cat /etc/tradingbot/api.env, then try am with another user. 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 to 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 inside running services as an unprivileged user. The remaining server baseline, SSH keys and firewall, belong inside the first ten minutes on a new VPS.

Find out say e don dey down before your broker do

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 make.

Use heartbeat instead. Uptime Kuma get push monitors: e dey expect make your bot call one URL according to schedule, and e go alert when the calls stop to arrive. Put the call for 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 the monitor interval to about twice your loop time, so normal jitter no go page you. Run the monitor for different server from the bot, because monitor wey die together with the thing 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 go fill root filesystem within weeks, and full disk dey stop database write, not network call, so the symptoms go strange. journalctl --vacuum-time=14d and one SystemMaxUse= line for /etc/systemd/journald.conf dey keep the journal bounded.

The honest part: latency mostly no be your host

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

Your order dey travel from the bot go exchange or broker endpoint through public internet. Physical distance and peering between your provider and their provider dey control that path. Server for Frankfurt wey dey talk to endpoint for Tokyo go pay roughly 250 milliseconds round trip, no matter how fast the CPU be. Then broker own systems go add their queue, risk checks and rate limits. For retail account, these ones usually dey measure in 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 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, broker processing dey cause the remaining delay, and 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. 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 per loop. Na real latency be that, and you fit control am for free. Profile the loop before you begin find faster server.

For the host wey you choose, geography, stable networking, and enough memory matter. Make OOM killer never get chance to affect the system. As of July 2026, single-strategy Python bot with few hundred symbols for memory dey run comfortably with 2 GB of RAM and 2 vCPU. Add memory if you dey keep tick history for local database.

Small checklist before live launch

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 a few milliseconds.
3. API key get trading permission, e no get withdrawal permission, and e get IP allowlist if the exchange provide one.
4. If you kill the process with sudo systemctl kill -s SIGKILL tradingbot, e dey come back within RestartSec.
5. Heartbeat monitor dey page 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. For this kind setup, colocation dey usually better pass general purpose VPS. For retail bot, geography and the broker own processing dey mostly determine the round trip. So choose server wey dey near the API endpoint, and measure with curl and mtr before you pay for anything faster.

How much RAM and CPU trading bot need?

Most single-strategy bots dey network-bound and dey idle between events. As of July 2026, 2 vCPU and 2 GB of RAM fit handle Python bot wey dey track some 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 my requests with timestamp error?

The server clock don drift pass the exchange signing window, usually by some seconds. Install chrony, confirm say chronyc tracking dey show small System time offset and synchronised leap status, and set the machine to UTC so daylight saving change no go shift am. Rotating the API key no dey 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 go send after each successful loop. The restart dey handle the process. The heartbeat dey catch the case where the process dey alive but stuck.

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

You fit, but the monitoring go lie to you on the day wey e matter. This na because outage wey takes down the bot go also take down the monitor. Keep the alerting for separate machine, preferably with different provider or region, and use the bot server only for the bot and its logs.