VPS fuer Trading-Bots: Was wirklich wichtig ist

Was ein Trading-Bot von einem VPS benötigt

Ein VPS für Trading-Bots wird an vier Kriterien gemessen: Startet der Prozess nach einem Absturz wieder, stimmt die Systemzeit, sind die API-Schlüssel (application programming interface) ausreichend vor Diebstahl geschützt, und erfahren Sie, wenn der Prozess beendet wurde? Die reine Geschwindigkeit steht bei einem Bot für Privatanwender weit unten auf dieser Liste. Der langsamste Teil Ihres Orderpfads ist in der Regel Ihr Broker und die Entfernung zu ihm, nicht der Host, auf dem Ihr Python-Prozess läuft.

Dies ist eine Anleitung zur technischen Umsetzung. Die Inhalte stellen keine Finanzberatung dar, und es wird keine Strategie behandelt.

Uptime ist eine Frage der Neustartdisziplin, nicht eine Zahl auf einer Verkaufsseite

Jeder Host auf der Welt wirbt mit 99.9 Prozent Uptime. Diese Zahl beschreibt den Hypervisor, nicht Ihren Bot. Ein Bot beendet sich wegen einer unbehandelten Exception, einer WebSocket-Verbindung, die nie wiederhergestellt wird, oder durch den OOM-Killer (Out of Memory), während der Server die ganze Zeit verfügbar bleibt. Die entscheidende Frage ist daher, was in den zehn Sekunden nach dem Beenden Ihres Prozesses geschieht.

Führen Sie den Bot als systemd-Dienst aus und überlassen Sie dem Init-System den Neustart. Eine Unit-Datei erledigt das in sechs Zeilen.

[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 ist die Zeile, die viele übersehen. Standardmäßig gibt systemd nach 5 Neustarts innerhalb von 10 Sekunden auf und belässt die Unit dauerhaft im Status failed. Genau dieses Verhalten wollen Sie um 03:00 nicht. Der Wert 0 deaktiviert die Ratenbegrenzung. Ein Bot, der in einer Crash-Schleife läuft, versucht dadurch weiterhin den Neustart, statt still auszufallen. RestartSec=10 verhindert, dass diese Schleife die Börse mit Wiederverbindungsversuchen überlastet.

Prüfen Sie die Datei, bevor Sie ihr vertrauen, und starten Sie den Dienst anschließend:

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

enable ist die Hälfte, die einen Reboot übersteht, und Kernel-Updates erfordern Reboots. Um zu prüfen, ob der Bot unbemerkt beendet wurde, fragen Sie den Neustartzähler bei systemd ab:

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

NRestarts=0 nach einer Woche weist auf einen gesunden Bot hin. NRestarts=812 bedeutet, dass Sie mit einem Prozess gehandelt haben, der die ganze Nacht über Verbindungen wiederherstellt. Der vollständige Aufbau einer Unit-Datei, einschließlich Timern für geplante Aufgaben wie einen täglichen Bericht, wird unter ein Programm als systemd-Dienst ausführen behandelt.

Die Uhr auf UTC setzen und die Synchronisierung nachweisen

Exchange-APIs signieren Anfragen mit einem Zeitstempel und lehnen alle Anfragen außerhalb eines Zeitfensters ab, häufig 5 Sekunden oder weniger. Eine abweichende Systemzeit erzeugt Fehler, die wie Authentifizierungsfehler aussehen. Daher werden oft stundenlang Schlüssel neu erstellt, bevor die Uhrzeit geprüft wird. Bei APIs im Binance-Stil ist die Fehlermeldung eindeutig: Timestamp for this request was 1000ms ahead of the server's time.

Setzen Sie den Server auf UTC. Lokale Zeitzonen führen zu einer Zeitumstellung, die mitten in einer Handelssitzung auftreten kann.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu enthält systemd-timesyncd. Dabei handelt es sich um einen SNTP-Client (Simple Network Time Protocol). Für Logs ist er ausreichend, für alles, was innerhalb weniger Millisekunden bleiben muss, jedoch ungeeignet. Er fragt nur einen Server ab und korrigiert die Uhr nicht kontinuierlich. Verwenden Sie stattdessen chrony:

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

Die aus chronyc tracking auszulesende Zeile lautet System time, zum Beispiel System time : 0.000031415 seconds fast of NTP time. Ein Wert von weniger als wenigen Millisekunden ist unkritisch. Wenn Leap status : Not synchronised angezeigt wird, hat chrony noch keinen Server erreicht. Ursache ist meist, dass ausgehendes UDP auf Port 123 blockiert wird. Warten Sie eine Minute und prüfen Sie den Status erneut, bevor Sie die Firewall-Regeln ändern.

Halten Sie API-Schlüssel von den Verzeichnissen fern, in die Sie Dateien kopieren

Ein offengelegter Börsen-Schlüssel ist gefährlicher als ein offengelegter SSH-Schlüssel, weil eine aktivierte Auszahlungsberechtigung ihn sofort in Geld verwandelt. Zwei Gewohnheiten decken den größten Teil des Risikos ab.

Erteilen Sie einem Bot-Schlüssel niemals eine Auszahlungsberechtigung. Wenn die Börse dies unterstützt, beschränken Sie den Schlüssel außerdem auf die IP-Adresse Ihres Servers. Diese einzelne Maßnahme macht einen gestohlenen Schlüssel nahezu nutzlos.

Halten Sie das Geheimnis außerdem aus dem Codeverzeichnis heraus. Alles innerhalb von /opt/tradingbot landet früher oder später in einem git-Repository oder einem Backup-Archiv. Legen Sie es in einer Datei im Besitz von root ab, die nur systemd liest:

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

Die Datei enthält einfache KEY=value-Zeilen ohne Anführungszeichen und ohne export. Der Modus 640 mit der Gruppe bot bedeutet, dass der Dienstbenutzer die Datei lesen kann und kein anderer Benutzer. Prüfen Sie dies mit sudo -u bot cat /etc/tradingbot/api.env und anschließend mit einem anderen Benutzer. Dort muss der Zugriff mit Permission denied fehlschlagen.

Der Bot selbst sollte weder als root noch als Ihr Anmeldebenutzer ausgeführt werden. Erstellen Sie ein Systemkonto ohne Shell und ohne Home-Verzeichnis, bei dem keine Anmeldung möglich ist:

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

Die Begründung für jedes dieser Flags und die tatsächliche Wirkung von ProtectSystem=strict finden Sie unter Dienste als unprivilegierter Benutzer ausführen. Die übrige Server-Grundkonfiguration mit SSH-Schlüsseln und einer Firewall gehört in die ersten zehn Minuten auf einem neuen VPS.

Erkennen Sie den Ausfall, bevor Ihr Broker es tut

systemctl status zeigt, dass der Prozess läuft. Das bedeutet nicht, dass der Bot arbeitet. Ein Prozess, der in einer Retry-Schleife gegen einen nicht erreichbaren WebSocket festhängt, besteht jede Prüfung, die systemd durchführen kann.

Verwenden Sie stattdessen einen Heartbeat. Uptime Kuma bietet Push-Monitore: Der Bot muss eine URL regelmäßig aufrufen. Wenn die Aufrufe ausbleiben, wird ein Alarm ausgelöst. Platzieren Sie den Aufruf am Ende Ihrer Hauptschleife, nach dem Teil, der bestätigt, dass der Bot aktiv ist, beispielsweise nach einem erfolgreichen Lesen der Marktdaten.

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

Setzen Sie das Monitorintervall auf etwa das Doppelte der Schleifenlaufzeit. Dadurch lösen normale Schwankungen keinen Alarm aus. Betreiben Sie den Monitor auf einem anderen Server als den Bot. Wenn der Monitor zusammen mit dem überwachten Dienst ausfällt, meldet er nichts. Die Einrichtung wird unter Self-hosted-Statusüberwachung mit Uptime Kuma beschrieben.

Richten Sie zusätzlich einen Festplattenalarm ein. Ein Bot mit ausführlichen Logs füllt das Root-Dateisystem innerhalb weniger Wochen. Bei einer vollen Festplatte schlägt der Datenbankeintrag fehl, nicht der Netzwerkaufruf. Dadurch sind die Symptome schwer einzuordnen. journalctl --vacuum-time=14d und eine SystemMaxUse=-Zeile in /etc/systemd/journald.conf begrenzen die Größe des Journals.

Der ehrliche Teil: Die Latenz hängt größtenteils nicht von Ihrem Host ab

Hier endet der technische Teil des Marktes für Trading-VPS-Produkte. Marketingseiten nennen Werte unter einer Millisekunde und erwecken den Eindruck, der Host stehe zwischen Ihnen und einer Ausführung. Für fast jeden Bot im Retail-Bereich trifft das nicht zu.

Ihre Order läuft vom Bot über das öffentliche Internet zum Endpunkt der Börse oder des Brokers. Diese Verbindung wird von der physischen Entfernung und vom Peering zwischen Ihrem Provider und dem Provider des Endpunkts bestimmt. Ein Server in Frankfurt, der mit einem Endpunkt in Tokio kommuniziert, benötigt unabhängig von der CPU-Geschwindigkeit ungefähr 250 Millisekunden für den Roundtrip. Danach fügen die Systeme des Brokers ihre Warteschlange, ihre Risikoprüfungen und ihre Rate Limits hinzu. Bei einem Retail-Konto liegen diese Verzögerungen normalerweise im Bereich von mehreren zehn oder mehreren hundert Millisekunden.

Messen Sie die Werte, statt sie zu schätzen. curl meldet die Verbindungs- und First-Byte-Zeiten für einen echten Endpunkt:

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

Führen Sie den Befehl auf einem möglichen Server aus, bevor Sie sich festlegen. Wenn connect 0.180 Sekunden beträgt, steht der Server auf dem falschen Kontinent. Das sollten Sie korrigieren. Wenn connect 0.004 Sekunden und ttfb 0.140 Sekunden beträgt, entsteht die verbleibende Verzögerung durch die Verarbeitung beim Broker. Ein Wechsel des Hosts ändert daran nichts.

Wann ist der Host also relevant? Wenn Sie per Colocation oder Cross-Connect direkt an die Handelsplattform angebunden sind und um die Position in der Warteschlange konkurrieren. Das ist ein anderes Geschäft mit einem anderen Budget. Relevant ist der Host auch, wenn Ihr eigener Code den Engpass bildet: Ein Bot, der bei jedem Tick Indikatoren über die vollständige Historie neu berechnet, kann pro Schleifendurchlauf 200 Millisekunden CPU-Zeit verbrauchen. Das ist echte Latenz, die Sie kostenlos beeinflussen können. Profilieren Sie die Schleife, bevor Sie nach einem schnelleren Server suchen.

Bei der Auswahl des Hosts sind Geografie, ein stabiles Netzwerk und ausreichend Arbeitsspeicher entscheidend, damit der OOM-Killer niemals eingreifen muss. Im Juli 2026 läuft ein einzelner Python-Bot für eine Strategie mit einigen hundert Symbolen im Arbeitsspeicher problemlos mit 2 GB RAM und 2 vCPU. Erhöhen Sie den Arbeitsspeicher, wenn Sie Tick-Historien in einer lokalen Datenbank speichern.

Eine kurze Checkliste vor dem Live-Betrieb

1. systemctl is-enabled tradingbot gibt enabled aus, und der Dienst übersteht sudo reboot.
2. chronyc tracking meldet eine Abweichung der Systemzeit von weniger als einigen Millisekunden.
3. Der API-Schlüssel verfügt über Handelsberechtigungen, nicht jedoch über Auszahlungsberechtigungen. Falls die Börse eine IP-Allowlist anbietet, ist sie konfiguriert.
4. Wenn der Prozess mit sudo systemctl kill -s SIGKILL tradingbot beendet wird, läuft er innerhalb von RestartSec wieder an.
5. Der Heartbeat-Monitor benachrichtigt Sie innerhalb eines Intervalls, wenn Sie den Bot absichtlich anhalten.
6. Die Logs sind in ihrer Größe begrenzt, und das Root-Dateisystem verfügt in df -h über ausreichend freien Speicherplatz.

Führen Sie das gesamte System eine Woche lang in der Sandbox der Börse oder im Paper-Modus aus, bevor Sie echtes Kapital einsetzen. Jeder Punkt der obigen Liste schlägt in dieser Woche mindestens einmal fehl. Genau das ist der Zweck dieser Woche.

FAQ

Benötigt ein Trading-Bot einen Server mit niedriger Latenz oder einen Bare-Metal-Server?

Nur wenn Sie am selben Handelsplatz mit anderen automatisierten Teilnehmern um Ausführungsgeschwindigkeit konkurrieren. Das bedeutet normalerweise Colocation und nicht einen herkömmlichen VPS. Bei einem Bot für Privatanwender wird die Round-Trip-Zeit hauptsächlich durch die geografische Entfernung und die Verarbeitung beim Broker bestimmt. Wählen Sie daher einen Server in der Nähe des API-Endpunkts und messen Sie mit curl und mtr, bevor Sie für eine schnellere Lösung bezahlen.

Wie viel RAM und CPU benötigt ein Trading-Bot?

Die meisten Bots mit einer einzelnen Strategie sind netzwerkgebunden und zwischen Ereignissen inaktiv. Im Juli 2026 reichen 2 vCPU und 2 GB RAM für einen Python-Bot aus, der einige hundert Instrumente überwacht. Der Arbeitsspeicher wird zum Engpass, wenn Sie Tick-Historien im Prozess halten oder eine lokale Datenbank betreiben. Überwachen Sie daher free -h und das Journal auf Meldungen zu OOM-Kills, statt den Bedarf zu schätzen.

Warum weist meine Exchange-API Anfragen mit einem Zeitstempelfehler zurück?

Die Systemzeit ist außerhalb des Signaturfensters der Exchange abgewichen, normalerweise um einige Sekunden. Installieren Sie chrony, prüfen Sie, ob chronyc tracking einen kleinen Offset von System time und einen synchronisierten Schaltsekundenstatus anzeigt, und setzen Sie die Maschine auf UTC, damit eine Zeitumstellung nie zu einer Verschiebung führt. Das Ersetzen des API-Schlüssels behebt kein Zeitproblem.

Wie verhindere ich, dass mein Bot über Nacht unbemerkt beendet wird?

Führen Sie ihn mit Restart=always und StartLimitIntervalSec=0 unter systemd aus, damit eine Absturzschleife wiederholte Startversuche ausführt, statt den Dienst dauerhaft zu beenden. Fügen Sie anschließend einen Heartbeat hinzu, den der Bot am Ende jedes erfolgreich abgeschlossenen Durchlaufs sendet. Der Neustart behandelt den Prozess. Der Heartbeat erkennt den Fall, dass der Prozess noch läuft, aber feststeckt.

Kann ich den Bot und mein Monitoring auf demselben VPS betreiben?

Das ist möglich. Am Tag, an dem es darauf ankommt, wird das Monitoring Sie jedoch täuschen, weil ein Ausfall, der den Bot außer Betrieb setzt, auch das Monitoring mitnimmt. Betreiben Sie das Alerting auf einer separaten Maschine, idealerweise bei einem anderen Anbieter oder in einer anderen Region. Verwenden Sie den Server des Bots ausschließlich für den Bot und dessen Logs.