VPS für Trading-Bots: Was wirklich zählt

Anforderungen eines Trading-Bots an einen VPS

Ein VPS für Trading-Bots wird nach vier Kriterien bewertet: Startet der Prozess nach einem Absturz erneut, stimmt die Systemzeit, sind die API-Schlüssel (Application Programming Interface) vor Diebstahl geschützt, und erfahren Sie, wenn der Bot stoppt? Die reine Geschwindigkeit steht bei einem Retail-Bot weit unten auf dieser Liste. Der langsame 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 ein Leitfaden für die technische Umsetzung. Die Inhalte stellen keine Finanzberatung dar. Es wird keine Strategie behandelt.

Uptime ist Neustartdisziplin, nicht eine Zahl auf einer Verkaufsseite

Jeder Host weltweit wirbt mit 99.9 Prozent Uptime. Diese Zahl beschreibt den Hypervisor, nicht Ihren Bot. Ein Bot beendet sich wegen einer nicht behandelten Ausnahme, einer WebSocket-Verbindung, die nie wiederhergestellt wird, oder des OOM-Killers (Out of Memory). Der Server bleibt währenddessen vollständig aktiv. Die entscheidende Frage lautet daher: Was geschieht in den zehn Sekunden, nachdem Ihr Prozess beendet wurde?

Führen Sie den Bot als systemd-Service 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 häufig übersehen wird. Standardmäßig gibt systemd nach 5 Neustarts innerhalb von 10 Sekunden auf und lässt die Unit dauerhaft im Zustand failed. Genau dieses Verhalten wollen Sie um 03:00 nicht. Der Wert 0 deaktiviert die Ratenbegrenzung. Ein Bot, der in einer Absturzschleife läuft, versucht den Start dann weiter, statt still zu bleiben. 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 Service 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 der Konfiguration, die einen Neustart übersteht. Kernel-Updates führen zu Neustarts. Um festzustellen, 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 stabilen Bot hin. NRestarts=812 bedeutet, dass Sie mit einem Prozess gehandelt haben, der die ganze Nacht über Verbindungen wiederherstellt. Die vollständige Anatomie einer Unit-Datei, einschließlich Timern für geplante Aufgaben wie einen täglichen Bericht, wird unter ein Programm als systemd-Service ausführen beschrieben.

Stellen Sie die Uhr auf UTC ein und weisen Sie die Synchronisierung nach

Exchange-APIs signieren Anfragen mit einem Zeitstempel und lehnen alles außerhalb eines Zeitfensters ab, das oft 5 Sekunden oder weniger beträgt. Eine abweichende Uhr erzeugt Fehler, die wie Authentifizierungsfehler aussehen. Deshalb wechseln manche Benutzer stundenlang die Schlüssel, bevor sie die Uhrzeit prüfen. Bei Binance-ähnlichen APIs ist die Meldung wörtlich: Timestamp for this request was 1000ms ahead of the server's time.

Stellen Sie den Server auf UTC ein. Lokale Zeitzonen führen zu einer Umstellung auf Sommerzeit, die mitten in einer Handelssitzung erfolgen 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 Protokolle ist er geeignet. Für alles, was innerhalb weniger Millisekunden bleiben muss, ist er jedoch unzureichend, weil er einen Server abfragt und die Uhr nicht kontinuierlich regelt. Verwenden Sie stattdessen chrony:

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

In chronyc tracking müssen Sie System time lesen, 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. Die Ursache ist meist, dass ausgehendes UDP 123 blockiert ist. Warten Sie eine Minute und prüfen Sie dann erneut, bevor Sie Firewall-Regeln ändern.

Halten Sie API-Schlüssel von kopierten Verzeichnissen fern

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

Erteilen Sie einem Bot-Schlüssel niemals eine Berechtigung zum Abheben. 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 ab, die root gehört und nur von systemd gelesen wird:

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 Servicebenutzer die Datei lesen kann und sonst niemand. 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 wird unter Dienste als unprivilegierter Benutzer ausführen erläutert. Die übrige Grundkonfiguration des Servers, SSH-Schlüssel und eine Firewall, gehört in die ersten zehn Minuten auf einem neuen VPS.

Erkennen Sie den Ausfall, bevor Ihr Broker ihn erkennt

systemctl status zeigt an, dass der Prozess läuft. Das bedeutet nicht, dass der Bot arbeitet. Ein Prozess, der in einer Wiederholungsschleife 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-Monitoring: Das System erwartet, dass Ihr Bot in einem festgelegten Zeitplan eine URL aufruft, und löst einen Alarm aus, wenn diese Aufrufe ausbleiben. Fügen Sie den Aufruf am Ende Ihrer Hauptschleife ein, und zwar nach dem Teil, der beweist, dass der Bot aktiv ist, beispielsweise nach einem erfolgreichen Abruf von Marktdaten.

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

Setzen Sie das Überwachungsintervall ungefähr auf das Doppelte Ihrer Schleifenlaufzeit, damit normale Schwankungen keinen Alarm auslösen. 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 selbst gehostete Statusüberwachung mit Uptime Kuma beschrieben.

Fügen Sie außerdem einen Plattenplatzalarm hinzu. Ein Bot, der ausführliche Protokolle schreibt, füllt das Root-Dateisystem innerhalb weniger Wochen. Ein volles Dateisystem verhindert das Schreiben in die Datenbank, nicht den Netzwerkaufruf. Dadurch entstehen ungewöhnliche Symptome. 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 im Submillisekundenbereich und erwecken den Eindruck, der Host entscheide über Ihre Ausführung. Bei fast jedem Bot im Privatkundengeschäft ist das nicht der Fall.

Ihre Order läuft vom Bot über das öffentliche Internet zum Endpunkt der Börse oder des Brokers. Diese Strecke wird durch die physische Entfernung und das 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 Hin- und Rückweg. Danach fügen die Systeme des Brokers ihre Warteschlange, ihre Risikoprüfungen und ihre Rate-Limits hinzu. Bei einem Privatkundenkonto liegen diese Verzögerungen normalerweise im Bereich von mehreren Dutzend oder mehreren hundert Millisekunden.

Messen Sie die Werte, statt zu raten. 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, befinden Sie sich 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 Hostwechsel kann daran nichts ändern.

Wann ist der Host also wichtig? Wenn Sie beim Handelsplatz colocation oder eine Cross-Connection nutzen und um die Position in der Warteschlange konkurrieren. Das ist ein anderes Geschäft mit einem anderen Budget. Der Host ist auch wichtig, wenn Ihr eigener Code den Engpass bildet. Ein Bot, der bei jedem Tick die 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.

Wichtig sind bei der Auswahl des Hosts die geografische Lage, eine stabile Netzwerkanbindung und ausreichend Arbeitsspeicher, damit der OOM-Killer niemals eingreifen muss. Im Juli 2026 läuft ein Python-Bot mit einer einzelnen Strategie und einigen hundert Symbolen im Arbeitsspeicher problemlos mit 2 GB RAM und 2 vCPU. Fügen Sie Arbeitsspeicher hinzu, wenn Sie Tick-Historien in einer lokalen Datenbank speichern.

Eine kurze Checkliste vor dem Livebetrieb

1. systemctl is-enabled tradingbot gibt enabled aus, und der Dienst übersteht sudo reboot.
2. chronyc tracking meldet eine Systemzeitabweichung von weniger als einigen Millisekunden.
3. Der API-Schlüssel hat Handelsberechtigung, aber keine Auszahlungsberechtigung. Wenn die Börse eine IP-Allowlist anbietet, ist sie aktiviert.
4. Wenn Sie den Prozess mit sudo systemctl kill -s SIGKILL tradingbot beenden, wird er innerhalb von RestartSec wieder gestartet.
5. Der Heartbeat-Monitor benachrichtigt Sie innerhalb eines Intervalls, wenn Sie den Bot absichtlich anhalten.
6. Die Logs sind begrenzt, und das Root-Dateisystem verfügt in df -h über ausreichend freien Speicherplatz.

Führen Sie den gesamten Ablauf eine Woche lang in der Sandbox der Börse oder im Paper-Modus aus, bevor Sie echtes Guthaben einsetzen. Jeder Punkt oben schlägt in dieser Woche mindestens einmal fehl. Genau das ist der Zweck dieser Woche.

FAQ

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

Nur wenn Sie bei der Ausführungsgeschwindigkeit am selben Handelsplatz mit anderen automatisierten Teilnehmern konkurrieren. In diesem Fall ist normalerweise Colocation statt eines allgemeinen VPS erforderlich. 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 höhere Geschwindigkeit bezahlen.

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

Die meisten Bots mit einer einzelnen Strategie sind netzwerkgebunden und zwischen Ereignissen untätig. Im Juli 2026 reichen 2 vCPU und 2 GB RAM für einen Python-Bot aus, der einige hundert Instrumente überwacht. Der Speicher wird zum begrenzenden Faktor, wenn Sie Tick-Daten im Prozess vorhalten oder eine lokale Datenbank ausführen. Überwachen Sie daher free -h und das Journal auf OOM-Kill-Meldungen, statt die Anforderungen zu schätzen.

Warum lehnt meine Exchange-API Anfragen mit einem Zeitstempelfehler ab?

Die Serveruhr ist außerhalb des Signaturzeitfensters 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 stellen Sie den Rechner auf UTC ein. Dadurch verschiebt eine Umstellung der Sommerzeit die Uhr niemals. Das Ersetzen des API-Schlüssels behebt kein Uhrzeitproblem.

Wie verhindere ich, dass mein Bot über Nacht ausfällt, ohne dass ich es bemerke?

Führen Sie ihn unter systemd mit Restart=always und StartLimitIntervalSec=0 aus. Dadurch werden Absturzschleifen weiter versucht, statt dauerhaft beendet zu werden. Fügen Sie anschließend einen Heartbeat hinzu, den der Bot am Ende jedes erfolgreichen Schleifendurchlaufs sendet. Der Neustart behandelt den Prozess. Der Heartbeat erkennt den Fall, dass der Prozess noch läuft, aber feststeckt.

Kann ich den Bot und meine Überwachung auf demselben VPS ausführen?

Das ist möglich, aber am Tag, an dem es darauf ankommt, wird die Überwachung Sie täuschen. Ein Ausfall, der den Bot beendet, beendet auch die Überwachung. Betreiben Sie die Alarmierung auf einem separaten Rechner, idealerweise bei einem anderen Anbieter oder in einer anderen Region. Verwenden Sie den Server des Bots ausschließlich für den Bot und seine Logs.