Een trading-bot op je laptop is een slecht idee om één saaie reden: je laptop is niet 24/7 online, en markten wel. Sluit de deksel midden in een trade en de bot stopt met het beheren van een open positie. Freqtrade — de populaire open-source Python trading-bot — is gebouwd om onbeheerd te draaien, wat precies is waar een kleine VPS voor is. Hier is wat het echt nodig heeft, hoe je het opzet met Docker, en de eerlijke grenzen die niemand noemt tot je ze raakt.
Waarom een server, niet je machine
Twee redenen, beide praktisch:
- Uptime. De bot moet de markt bewaken en posities rond de klok beheren. Elke keer dat je laptop slaapt of herstart, is de bot blind — een gemiste entry, of erger, een open positie die niemand bekijkt.
- Latency en stabiliteit. Een VPS zit op een datacenterverbinding met een stabiele route naar de exchange. Home-wifi-jitter en NAT-resets helpen een bot die op prijs reageert niet.
Dit is dezelfde logica achter het draaien van elke trading-bot op een VPS — Freqtrade maakt de vereisten alleen concreet.
Wat het echt nodig heeft
Freqtrade zelf is lichtgewicht, maar wees realistisch over de workload:
- Live- / dry-run-bot: 2 GB RAM is een comfortabele ondergrens. De Docker-image, een handvol paren, indicatoren en de SQLite-trade-DB willen allemaal een beetje ruimte. Een $5 Micro (2 vCPU / 2 GB / 25 GB) is het juiste startpunt. 1 GB kan een enkele simpele strategie op een paar paren draaien, maar je zit dichter bij de rand.
- Veel paren / meerdere strategieën: stap op naar een $8 Small (4 vCPU / 4 GB / 35 GB) — meer paren betekent meer gelijktijdige indicatorberekening en een grotere dataframe in het geheugen.
- Schijf: bescheiden. De image, je
user_data, en de trade-DB passen comfortabel in 25 GB. Gedownloade historische data voor backtesting is het enige dat groeit — en dat leeft grotendeels op je lokale machine (zie hieronder).
Zet het op met Docker Compose
Docker is de onderhouden, minst pijnlijke manier om Freqtrade te draaien. Op een verse box:
sudo apt update && sudo apt install -y docker.io docker-compose-v2
mkdir ~/ft && cd ~/ft
docker run --rm -v "$(pwd)/user_data:/freqtrade/user_data" \
freqtradeorg/freqtrade:stable create-userdir --userdir user_data
Pak het officiële compose-bestand en maak interactief een config aan (het vraagt naar je exchange, stake en dry-run):
curl -s https://raw.githubusercontent.com/freqtrade/freqtrade/stable/docker-compose.yml -o docker-compose.yml
docker compose run --rm freqtrade new-config --config user_data/config.json
Eerst dry-run — altijd
Richt nooit een verse strategie op echt geld. Freqtrade staat standaard op dry-run (paper trading) en je zou het daar moeten laten tot de strategie zich een tijdje op live marktdata heeft bewezen. In config.json:
{
"dry_run": true,
"dry_run_wallet": 1000
}
Start het en kijk:
docker compose up -d
docker compose logs -f
Het restart: unless-stopped-beleid in het compose-bestand is hier je systemd-equivalent — Docker brengt de bot terug na een crash of een serverherstart, geen handmatige stap. (Als je het liever buiten Docker draait, doet een systemd-unit met Restart=always dezelfde klus — zelfde principe als elke bot in leven houden.)
Exchange-API-keys — het deel dat mensen bijt
Dit is waar een trading-setup duur misgaat. Twee regels, niet onderhandelbaar:
- Alleen trade-permissie. Schakel nooit withdrawal in. Als de key lekt, is het worst case ongewenste trades — niet je fondsen die de deur uitlopen. Freqtrade heeft nooit withdrawal-toegang nodig.
- IP-whitelist de key. De meeste exchanges laten je een API-key aan specifieke IP's binden. Dat is een concrete reden om op een dedicated-IP-plan te draaien: de key werkt alleen vanaf het vaste adres van je server. Op een NAT-plan deelt de bot het uitgaande IP van de node, wat niet alleen van jou is — prima voor de bot om te functioneren, maar je kunt het niet netjes whitelisten.
Houd de keys in config.json, maak het niet-world-readable (chmod 600), en draai de container als een non-root gebruiker. En vergrendel de box eerst — de nieuwe-VPS-security-checklist kost tien minuten en sluit de deuren die ertoe doen.
Back-up user_data
Je strategieën, config en trade-geschiedenis leven allemaal in user_data. Dat is het ding dat je niet wilt verliezen:
tar czf ft-backup-$(date +%F).tar.gz user_data
Trek dat periodiek van de server af (of naar object storage). De trade-DB verliezen betekent je performance-geschiedenis verliezen; een getunede strategie verliezen betekent de optimalisatie opnieuw doen.
De eerlijke grenzen
- Backtesting en hyperopt zijn zwaar — doe ze lokaal. Ze pinnen CPU voor langere periodes vast, en een gedeelde, burst-georiënteerde VPS is gebouwd voor spiky workloads, niet uren van aanhoudende 100%-belasting (wat ook tegen het beleid voor acceptabel gebruik ingaat). Optimaliseer op je eigen machine, deploy het resultaat om live te draaien. De VPS is voor de live bot, niet het onderzoek.
- CPU is gedeeld/burst. Geweldig voor een live bot die grotendeels op candles wacht en reageert; verkeerd voor het malen van een jaar aan 1-minuutdata door hyperopt.
- Eén regio, alleen CPU. De server staat in Duitsland zonder GPU. Prima voor Freqtrade (het is CPU/logica, geen ML-training) — de moeite waard om te weten als je strategie op een zwaar ML-model leunt, wat opnieuw beter lokaal wordt getraind.
Conclusie
Freqtrade op een VPS is de juiste setup voor de live bot: een $5 Micro voor een gefocuste strategie, een $8 Small als je veel paren draait, Docker Compose met restart: unless-stopped voor uptime, en een trade-only, IP-gewhiteliste API-key zodat een lek je niet kan leegtrekken. Houd het zware backtesten en hyperopten op je laptop, maak een back-up van user_data, en laat de server het ene ding doen waar hij goed in is — online blijven terwijl de markt beweegt. Aanmelden is alleen-e-mail en je betaalt in USDC of USDT; een dedicated IP is de ene upgrade die het hier waard is, puur voor de API-key-whitelist.
Klaar om te implementeren? Freqtrade is comfortabel op een Micro-plan; voor zwaardere backtests of veel paren, schaal op naar Small.
Reacties
Nog geen reacties. Wees de eerste.