Beste VPS voor trading bots: waar moet u op letten?

Wat een trading bot nodig heeft van een VPS

Een VPS voor trading bots wordt beoordeeld op vier punten: start het proces automatisch opnieuw na een crash, loopt de klok gelijk, zijn de API (application programming interface) keys veilig tegen diefstal, en krijgt u een melding wanneer de bot stopt. Voor een retail-bot is rauwe snelheid ondergeschikt aan deze factoren, omdat de vertraging in uw orderpad meestal bij de broker ligt en de afstand daartoe, niet bij de host waarop uw Python-code draait.

Dit is een technische handleiding. Niets in deze tekst is financieel advies en er worden geen strategieën besproken.

Uptime is een kwestie van herstartdiscipline, geen getal op een verkooppagina

Elke host ter wereld adverteert met 99,9 procent uptime. Dat cijfer beschrijft de hypervisor, niet uw bot. Een bot crasht door een onafgehandelde exceptie, een websocket die niet opnieuw verbindt, of de OOM (out of memory) killer, terwijl de server zelf de hele tijd blijft draaien. De relevante vraag is dus wat er gebeurt in de tien seconden nadat uw proces is afgesloten.

Draai de bot als een systemd-service en laat het init-systeem het herstarten 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 vergeten. Standaard geeft systemd het op na 5 herstarts in 10 seconden en laat het de unit voor eeuwig in de status failed staan; dit is precies het gedrag dat u niet wilt om 03:00 uur. Door dit op 0 in te stellen, schakelt u de limiet uit, zodat een bot die in een crash-loop zit het blijft proberen in plaats van stil te vallen. RestartSec=10 voorkomt dat die loop de exchange bestookt met herverbindingspogingen.

Controleer het bestand voordat u het vertrouwt en start het 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 reboot overleeft, en kernel-updates betekenen reboots. Om te zien of de bot stilletjes is gestorven, vraagt u systemd om de herstartteller:

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

NRestarts=0 na een week duidt op een gezonde bot. NRestarts=812 betekent dat u heeft gehandeld met een proces dat de hele nacht opnieuw verbinding maakt. De volledige anatomie van het unit-bestand, inclusief timers voor geplande taken zoals een dagelijks rapport, wordt behandeld in een programma draaien als een systemd-service.

Stel de klok in op UTC en verifieer de synchronisatie

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

Stel de server in op UTC. Lokale tijdzones introduceren een zomertijdwissel die midden in een handelssessie kan vallen.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu wordt geleverd met systemd-timesyncd, een SNTP-client (Simple Network Time Protocol). Dit is voldoende voor logs, maar onvoldoende voor toepassingen die binnen enkele milliseconden nauwkeurig moeten blijven, omdat het slechts één server polt en de klok niet continu bijstuurt. 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. Alles onder enkele milliseconden is in orde. Als er Leap status : Not synchronised staat, heeft chrony nog geen server bereikt, meestal omdat uitgaand UDP 123 wordt geblokkeerd. Wacht een minuut en controleer het opnieuw voordat u firewallregels aanpast.

Houd API-keys uit locaties waar u ze kopieert

Een gelekte exchange-key is schadelijker dan een gelekte SSH-key, omdat opnamerechten deze direct in geld veranderen. Twee gewoontes dekken het grootste deel van het risico af.

Verleen ten eerste nooit opnamerechten aan een bot-key en bind de key, waar de exchange dit ondersteunt, aan het IP-adres van uw server. Dit is de enige controle die een gestolen key nagenoeg nutteloos maakt.

Houd ten tweede het geheim buiten de codedirectory. Alles binnen /opt/tradingbot belandt vroeg of laat in een git-repository of een back-uparchief. Plaats het in een bestand dat eigendom is van root en dat alleen door systemd wordt gelezen:

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 platte KEY=value-regels zonder aanhalingstekens en zonder export. Modus 640 met groep bot betekent dat de servicegebruiker het kan lezen en niemand anders. Controleer dit met sudo -u bot cat /etc/tradingbot/api.env en vervolgens met een andere gebruiker, waarbij het moet falen met Permission denied.

De bot zelf mag niet draaien als root of als uw eigen inloggebruiker. Maak een systeemaccount aan zonder shell en zonder homedirectory om op in te loggen:

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

De onderbouwing van elk van deze flags, en hoe ver ProtectSystem=strict daadwerkelijk gaat, staat in services draaien als een ongeprivilegieerde gebruiker. De rest van de serverbasislijn, SSH-keys en een firewall, hoort thuis in de eerste tien minuten op een nieuwe VPS.

Ontdek dat het systeem offline is voordat uw broker dat doet

systemctl status geeft aan dat het proces draait. Dit betekent niet dat de bot daadwerkelijk functioneert. Een proces dat vastzit in een retry-loop tegen een niet-reagerende websocket, doorstaat elke controle die systemd kan uitvoeren.

Gebruik in plaats daarvan een heartbeat. Uptime Kuma beschikt over push-monitors: deze verwacht dat uw bot volgens een schema een URL aanroept en verstuurt een waarschuwing wanneer de aanroep uitblijft. Plaats de aanroep aan het einde van uw hoofdloop, na het gedeelte dat bevestigt dat de bot actief is, zoals na het succesvol uitlezen van marktgegevens.

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

Stel het monitorinterval in op ongeveer twee keer de tijd van uw loop, zodat normale variaties in de uitvoeringstijd niet leiden tot onnodige meldingen. Draai de monitor op een andere server dan de bot, aangezien een monitor die tegelijk met het te bewaken systeem uitvalt, geen meldingen kan versturen. De installatie wordt beschreven in zelfgehoste statusmonitoring met Uptime Kuma.

Voeg ook een schijfwaarschuwing toe. Een bot die uitgebreide logs schrijft, zal het root-bestandssysteem binnen enkele weken vullen. Een volle schijf stopt het schrijven naar de database, maar niet de netwerkaanroep, wat leidt tot ongebruikelijke symptomen. journalctl --vacuum-time=14d en een SystemMaxUse=-regel in /etc/systemd/journald.conf houden de omvang van de journal beperkt.

De eerlijke waarheid: latency ligt meestal niet aan uw host

Dit is het punt waarop de markt voor trading-VPS-producten ophoudt technisch te zijn. Marketingpagina's vermelden cijfers onder de milliseconde en suggereren dat de host het enige is dat tussen u en een orderuitvoering staat. Voor bijna elke retail-bot is dat niet het geval.

Uw order reist vanaf de bot naar het endpoint van de exchange of broker via het publieke internet. Dat pad wordt gedomineerd door de fysieke afstand en de peering tussen uw provider en die van hen. Een server in Frankfurt die communiceert met een endpoint in Tokyo heeft een round-trip van ongeveer 250 milliseconden, ongeacht hoe snel de CPU is. Vervolgens voegen de systemen van de broker hun eigen wachtrij, risicocontroles en rate limits toe, die voor een retail-account meestal worden gemeten in tientallen of honderden milliseconden.

Meet het in plaats van te gokken. curl rapporteert de verbindingstijd en de tijd tot de eerste byte 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 kandidaat-server voordat u zich vastlegt. Als connect 0.180 seconden is, bevindt u zich op het verkeerde continent en dat is de moeite waard om te corrigeren. Als connect 0.004 seconden is en ttfb 0.140 seconden, dan is de resterende vertraging de verwerkingstijd van de broker en zal een andere host daar niets aan veranderen.

Wanneer is de host dan wel van belang? Wanneer u colocated bent of een cross-connect heeft met de handelslocatie en concurreert op positie in de wachtrij; dit is een andere tak van sport met een ander budget. En wanneer uw eigen code de bottleneck is: een bot die bij elke tick indicatoren over een volledige historie herberekent, kan 200 milliseconden CPU per lus verbruiken. Dat is echte latency waar u zelf gratis controle over heeft. Profileer de lus voordat u op zoek gaat naar een snellere server.

Wat wel uitmaakt bij de host die u kiest, is de geografie, stabiele netwerkverbindingen en voldoende geheugen zodat de OOM killer nooit hoeft in te grijpen. Sinds juli 2026 draait een Python-bot met één strategie en een paar honderd symbolen in het geheugen comfortabel op 2 GB RAM en 2 vCPU. Voeg geheugen toe als u tick-historie in een lokale database bijhoudt.

Een korte checklist voor de livegang

1. systemctl is-enabled tradingbot print enabled en de service overleeft sudo reboot.
2. chronyc tracking rapporteert een systeem-tijdverschil van minder dan enkele milliseconden.
3. De API-sleutel heeft handelsrechten, geen opnamerechten, en een IP-allowlist indien de exchange dit aanbiedt.
4. Het beëindigen van het proces met sudo systemctl kill -s SIGKILL tradingbot zorgt voor een herstart binnen RestartSec.
5. De heartbeat-monitor stuurt u binnen één interval een melding wanneer u de bot bewust stopt.
6. Logs zijn begrensd en het root-bestandssysteem heeft voldoende vrije ruimte in df -h.

Draai het geheel gedurende een week in de sandbox van de exchange of in de paper-modus voordat u met echt kapitaal werkt. Elk van de bovenstaande punten zal in die week minstens één keer falen; dat is precies het doel van deze week.

FAQ

Heeft een trading bot een server met lage latentie of bare metal nodig?

Alleen als u op het gebied van uitvoeringssnelheid concurreert met andere geautomatiseerde deelnemers op hetzelfde platform; dit vereist doorgaans colocatie in plaats van een algemene VPS. Voor een retail-bot wordt de round-trip-tijd bepaald door de geografische afstand en de verwerkingstijd van de broker zelf. Kies daarom een server die zich dicht bij het API-eindpunt bevindt en meet de prestaties met curl en mtr voordat u investeert in snellere hardware.

Hoeveel RAM en CPU heeft een trading bot nodig?

De meeste bots die één strategie uitvoeren, zijn netwerkgebonden en inactief tussen gebeurtenissen. Per juli 2026 zijn 2 vCPU en 2 GB RAM voldoende voor een Python-bot die enkele honderden instrumenten volgt. Geheugen wordt de beperkende factor wanneer u tick-geschiedenis in het procesgeheugen houdt of een lokale database draait. Monitor daarom free -h en de logs op OOM-kill-meldingen in plaats van te gissen.

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

De klok van de server is afgeweken buiten het acceptatievenster van de exchange, wat meestal enkele seconden bedraagt. Installeer chrony, controleer of chronyc tracking een kleine System time offset en een gesynchroniseerde leap-status toont, en stel de machine in op UTC zodat zomertijd- of wintertijdwisselingen de klok niet beïnvloeden. Het roteren van de API-sleutel lost een klokprobleem niet op.

Hoe voorkom ik dat mijn bot 's nachts stopt zonder dat ik het merk?

Draai de bot onder systemd met Restart=always en StartLimitIntervalSec=0, zodat een crash-loop het proces opnieuw probeert te starten in plaats van het permanent te stoppen. Voeg daarnaast een heartbeat toe die de bot aan het einde van elke succesvolle lus verstuurt. De herstartfunctie vangt het proces op, terwijl de heartbeat situaties detecteert waarin het proces wel draait, maar is vastgelopen.

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

Dat kan, maar de monitoring zal u in de steek laten op het moment dat het er echt toe doet, omdat een storing die de bot platlegt ook de monitor uitschakelt. Houd de alarmering op een aparte machine, bij voorkeur bij een andere provider of in een andere regio, en gebruik de server van de bot uitsluitend voor de bot en de bijbehorende logs.