VPS voor tradingbots: wat is echt belangrijk?

Wat een tradingbot nodig heeft van een VPS

Een VPS voor tradingbots wordt op vier punten beoordeeld: start het proces opnieuw nadat het is gestopt, loopt de klok goed, zijn de API- (application programming interface-)sleutels moeilijk te stelen en merkt u het wanneer de bot stopt. Ruwe snelheid staat veel lager op die lijst voor een retailbot. Het trage deel van uw orderpad wordt namelijk bepaald door uw broker en de afstand tot de broker, niet door de host waarop uw Python-proces draait.

Dit is een technische handleiding. De inhoud vormt geen financieel advies en er wordt geen strategie besproken.

Uptime is herstartdiscipline, niet een getal op een verkooppagina

Elke host ter wereld adverteert met 99.9 procent uptime. Dat cijfer beschrijft de hypervisor, niet uw bot. Een bot stopt door een niet-afgehandelde uitzondering, een websocket die nooit opnieuw verbinding maakt of de OOM-killer (out of memory), terwijl de server de hele tijd actief blijft. De relevante vraag is dus wat er gebeurt in de tien seconden nadat uw proces stopt.

Voer de bot uit als een systemd-service en laat het init-systeem de herstart beheren. Een unit-bestand doet dit in zes regels.

[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 is de regel die mensen vaak missen. Standaard geeft systemd het na 5 herstarts in 10 seconden op en laat het de unit voor altijd in de status failed staan. Dat is precies het gedrag dat u om 03:00 niet wilt. Als u dit instelt op 0, schakelt u de snelheidslimiet uit. Een bot die in een crashlus terechtkomt, blijft dan nieuwe pogingen doen in plaats van stil te vallen. RestartSec=10 voorkomt dat die lus de exchange blijft belasten met nieuwe verbindingen.

Controleer het bestand voordat u erop vertrouwt en start de service vervolgens:

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

enable is het deel dat een herstart overleeft. Kernelupdates vereisen namelijk herstarts. Vraag systemd naar de herstartteller om te controleren of de bot stilletjes is gestopt:

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

NRestarts=0 na een week betekent dat de bot gezond is. NRestarts=812 betekent dat u hebt gehandeld met een proces dat de hele nacht opnieuw verbinding maakte. De volledige opbouw van een unit-bestand, inclusief timers voor geplande taken zoals een dagelijks rapport, wordt behandeld in een programma uitvoeren als systemd-service.

Stel de klok in op UTC en toon aan dat deze is gesynchroniseerd

Exchange-API's ondertekenen aanvragen met een tijdstempel en weigeren alles buiten een tijdvenster, vaak van 5 seconden of minder. Een afwijkende klok veroorzaakt fouten die op authenticatiefouten lijken. Daardoor roteren mensen urenlang sleutels voordat ze de tijd controleren. Bij API's in de stijl van Binance is de melding letterlijk: Timestamp for this request was 1000ms ahead of the server's time.

Stel de server in op UTC. Lokale tijdzones veroorzaken een sprong vanwege zomertijd die midden in een handelssessie kan plaatsvinden.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu wordt geleverd met systemd-timesyncd. Dit is een SNTP-client (Simple Network Time Protocol). Deze is geschikt voor logboeken, maar niet betrouwbaar genoeg voor toepassingen die binnen enkele milliseconden moeten blijven. De client bevraagt één server en corrigeert de klok niet continu. Gebruik in plaats daarvan chrony:

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

De regel die u uit chronyc tracking moet lezen is System time, bijvoorbeeld System time : 0.000031415 seconds fast of NTP time. Een waarde onder enkele milliseconden is gezond. Als de waarde Leap status : Not synchronised is, heeft chrony nog geen server bereikt. Dit komt meestal doordat uitgaand UDP-verkeer op poort 123 wordt geblokkeerd. Wacht een minuut en controleer het daarna opnieuw voordat u firewallregels aanpast.

Houd API-sleutels buiten de locaties die u kopieert

Een gelekte exchange-sleutel is erger dan een gelekte SSH-sleutel, omdat opnamerechten de sleutel direct in geld kunnen omzetten. Met twee gewoonten dekt u het meeste risico af.

Geef een botsleutel nooit opnamerechten. Koppel de sleutel, als de exchange dit ondersteunt, aan het IP-adres van uw server. Dit is de belangrijkste maatregel om een gestolen sleutel vrijwel onbruikbaar te maken.

Houd het geheim bovendien buiten de codedirectory. Alles in /opt/tradingbot komt vroeg of laat in een git-repository of back-uparchief terecht. Plaats het in een bestand dat eigendom is van root en dat alleen systemd leest:

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

Het bestand bevat regels in platte KEY=value-notatie, zonder aanhalingstekens en zonder export. Modus 640 met groep bot betekent dat de servicegebruiker het bestand kan lezen en niemand anders dat kan. Controleer dit met sudo -u bot cat /etc/tradingbot/api.env en daarna met een andere gebruiker. Die controle moet mislukken met Permission denied.

De bot zelf mag niet als root of als uw aanmeldingsgebruiker worden uitgevoerd. Maak een systeemaccount zonder shell en zonder homedirectory om op aan te melden:

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

De reden voor elk van deze flags en wat ProtectSystem=strict precies doet, wordt uitgelegd in services uitvoeren als een gebruiker zonder beheervoorrechten. De overige basisconfiguratie van de server, SSH-sleutels en een firewall, hoort in de eerste tien minuten op een nieuwe VPS.

Ontdek dat de service uitvalt voordat uw broker dat doet

systemctl status geeft aan dat het proces actief is. Dat betekent niet dat de bot iets doet. Een proces dat vastzit in een retry-lus tegen een niet-beschikbare websocket doorstaat elke controle die systemd kan uitvoeren.

Gebruik in plaats daarvan een heartbeat. Uptime Kuma heeft push-monitors: de monitor verwacht dat uw bot volgens een schema een URL aanroept en stuurt een waarschuwing wanneer deze aanroepen stoppen. Plaats de aanroep aan het einde van uw hoofdlus, na het onderdeel dat aantoont dat de bot actief is, zoals het succesvol lezen van marktgegevens.

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

Stel het monitorinterval in op ongeveer tweemaal de duur van uw lus, zodat normale variaties geen melding veroorzaken. Voer de monitor uit op een andere server dan de bot, omdat een monitor die tegelijk met het bewaakte proces uitvalt niets rapporteert. De installatie wordt beschreven in self-hosted statusmonitoring met Uptime Kuma.

Voeg ook een schijfwaarschuwing toe. Een bot die uitgebreide logboeken schrijft, vult het root-bestandssysteem binnen enkele weken. Een volle schijf verhindert het schrijven naar de database, maar niet de netwerkoproep. Daardoor zijn de symptomen ongebruikelijk. journalctl --vacuum-time=14d en een SystemMaxUse=-regel in /etc/systemd/journald.conf houden het journal binnen de perken.

Het eerlijke deel: latency wordt meestal niet door uw host bepaald

Hier houdt de markt voor trading-VPS-producten op technisch te zijn. Marketingpagina's noemen cijfers onder een milliseconde en wekken de indruk dat de host bepaalt of uw order wordt uitgevoerd. Voor vrijwel elke retailbot is dat niet het geval.

Uw order gaat vanaf de bot via het openbare internet naar het endpoint van de exchange of broker. Die route wordt bepaald door de fysieke afstand en door de peering tussen uw provider en die van de exchange of broker. Een server in Frankfurt die verbinding maakt met een endpoint in Tokyo heeft ongeveer 250 milliseconden retourlatency, ongeacht hoe snel de CPU is. Daar komen de eigen systemen van de broker nog bij: wachtrij, risicocontroles en rate limits. Voor een retailaccount zijn die vertragingen meestal tientallen of honderden milliseconden.

Meet dit in plaats van te raden. curl rapporteert de verbindings- en first-byte-tijden voor een echt 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

Voer dit uit vanaf een kandidaatserver voordat u zich vastlegt. Als connect 0.180 seconden is, bevindt u zich op het verkeerde continent. Dat is de moeite waard om te corrigeren. Als connect 0.004 seconden is en ttfb 0.140 seconden, wordt de resterende vertraging veroorzaakt door de verwerking bij de broker. Geen wijziging van host kan daar iets aan veranderen.

Wanneer is de host dan wel van belang? Wanneer u colocated bent met de handelslocatie of via een cross-connect bent verbonden en concurreert om uw positie in de wachtrij. Dat is een andere bedrijfstak met een ander budget. De host is ook van belang wanneer uw eigen code de bottleneck vormt. Een bot die bij elke tick indicatoren over de volledige historie opnieuw berekent, kan per lus 200 milliseconden CPU-tijd verbruiken. Dat is echte latency die u kosteloos kunt verminderen. Profile de lus voordat u naar een snellere server zoekt.

Voor de host die u kiest, zijn geografie, stabiele netwerkverbindingen en voldoende geheugen wel belangrijk, zodat de OOM killer nooit hoeft in te grijpen. In juli 2026 draait een Python-bot met één strategie en enkele honderden symbolen in het geheugen comfortabel met 2 GB RAM en 2 vCPU. Voeg geheugen toe als u tickhistorie in een lokale database bewaart.

Korte checklist vóór ingebruikname

1. systemctl is-enabled tradingbot geeft enabled weer en de service blijft actief na sudo reboot.
2. chronyc tracking meldt een afwijking van de systeemtijd van minder dan enkele milliseconden.
3. De API-sleutel heeft handelsrechten, geen opnamerechten en een IP-allowlist als de exchange die aanbiedt.
4. Als u het proces met sudo systemctl kill -s SIGKILL tradingbot beëindigt, is het binnen RestartSec weer actief.
5. De heartbeat-monitor stuurt u binnen één interval een melding wanneer u de bot opzettelijk stopt.
6. De logbestanden zijn begrensd en het root-bestandssysteem heeft voldoende vrije ruimte in df -h.

Voer het geheel een week lang uit in de sandbox van de exchange of in paper mode voordat u echt geld gebruikt. Elk item hierboven faalt in die week minstens één keer. Dat is precies het doel van die week.

FAQ

Heeft een tradingbot een server met lage latentie of een bare-metalsysteem nodig?

Alleen als u op uitvoeringssnelheid concurreert met andere geautomatiseerde deelnemers op dezelfde handelsplaats. In dat geval gebruikt u doorgaans colocatie en geen algemene VPS. Bij een retailbot wordt de round-trip meestal bepaald door de geografische afstand en de eigen verwerking van de broker. Kies daarom een server dicht bij het API-eindpunt en meet met curl en mtr voordat u voor iets snellers betaalt.

Hoeveel RAM en CPU heeft een tradingbot nodig?

De meeste bots met één strategie zijn netwerkgebonden en inactief tussen gebeurtenissen. In juli 2026 kunnen 2 vCPU en 2 GB RAM een Python-bot uitvoeren die enkele honderden instrumenten volgt. Geheugen wordt de beperkende factor wanneer u tickgeschiedenis in het proces bewaart of een lokale database uitvoert. Monitor daarom free -h en het journal op OOM kill-meldingen in plaats van te raden.

Waarom weigert mijn exchange-API verzoeken met een timestamp-fout?

De serverklok is buiten het ondertekeningsvenster van de exchange geraakt, meestal met enkele seconden afwijking. Installeer chrony. Controleer of chronyc tracking een kleine afwijking van System time en een gesynchroniseerde leap-status toont. Stel de machine in op UTC, zodat een overgang naar zomertijd de klok nooit verschuift. Het roteren van de API-sleutel lost een klokprobleem niet op.

Hoe voorkom ik dat mijn bot 's nachts stopt zonder dat ik dit weet?

Voer de bot uit onder systemd met Restart=always en StartLimitIntervalSec=0. Zo blijft een crashlus nieuwe pogingen uitvoeren in plaats van permanent te stoppen. Voeg daarna een heartbeat toe die de bot aan het einde van elke geslaagde lus verzendt. De herstart handelt het proces af. De heartbeat detecteert het geval waarin het proces actief is maar vastloopt.

Kan ik de bot en mijn monitoring op dezelfde VPS uitvoeren?

Dat kan, maar op de dag waarop het ertoe doet geeft de monitoring u onjuiste informatie. Een storing die de bot uitschakelt, schakelt namelijk ook de monitoring uit. Houd de alarmering op een afzonderlijke machine, bij voorkeur bij een andere provider of in een andere regio. Gebruik de server van de bot alleen voor de bot en diens logs.