Running a trading bot on a Linux VPS 24/7: systemd, chrony, and a kill switch you've actually testedEinen Trading-Bot 24/7 auf einem Linux-VPS betreiben: systemd, chrony und ein Kill-Switch, den du wirklich getestet hast

What this covers, and what it doesn'tWas diese Anleitung abdeckt, und was nicht

This is an operations guide: running a Python trading bot as a long-lived Linux process that restarts sanely, keeps credentials off disk in the wrong place, agrees with the exchange about what time it is, and tells you when it dies. It does not cover strategy, order types, backtesting, or position sizing — that is your call to make, and nothing here is financial advice. Assume you already have a working bot that talks to an exchange's API and just need it to run unattended without becoming a liability.Das ist eine Betriebsanleitung: Sie zeigt, wie du einen Python-Trading-Bot als langlebigen Linux-Prozess betreibst, der sinnvoll neu startet, Credentials nicht am falschen Ort auf der Festplatte liegen lässt, sich mit der Börse über die Uhrzeit einig ist und dir Bescheid gibt, wenn er stirbt. Sie behandelt nicht Strategie, Ordertypen, Backtesting oder Positionsgrößen — das ist deine Entscheidung, und nichts hier ist eine Finanzberatung. Geh davon aus, dass du bereits einen funktionierenden Bot hast, der mit der API einer Börse spricht, und dass er nur noch unbeaufsichtigt laufen soll, ohne zum Risiko zu werden.

Sizing the machineDie Maschine richtig dimensionieren

A single bot process is a light workload. A Python process holding a websocket connection, a small in-memory order book, and a logging pipeline typically sits well under 300 MB resident. The 1 GiB Starter tier covers one bot with headroom for the OS and chrony. What actually pushes you up a tier is running several bots on one box, keeping a local database of fills and candles that grows for months, or backtesting on the same machine you trade from — batch work and a live process fight over the same cores. Keep those separate if you can.Ein einzelner Bot-Prozess ist eine leichte Last. Ein Python-Prozess mit einer Websocket-Verbindung, einem kleinen Orderbuch im Speicher und einer Logging-Pipeline liegt typischerweise deutlich unter 300 MB resident. Die 1-GiB-Starter-Stufe deckt einen Bot mit Puffer für das Betriebssystem und chrony ab. Was dich tatsächlich eine Stufe hochtreibt, ist, mehrere Bots auf einer Maschine zu betreiben, eine lokale Datenbank mit Fills und Candles zu führen, die über Monate wächst, oder auf derselben Maschine zu backtesten, von der aus du handelst — Batch-Arbeit und ein Live-Prozess konkurrieren dann um dieselben Kerne. Trenn das, wenn du kannst.

Disk is rarely the constraint: a bot's code, a virtualenv, and months of rotated JSON logs fit inside a few gigabytes. The 25 GB on Starter is plenty unless you're recording full market data ticks, a different sizing conversation entirely.Speicherplatz ist selten der Engpass: Der Code eines Bots, ein virtualenv und Monate an rotierten JSON-Logs passen in wenige Gigabyte. Die 25 GB im Starter reichen locker, es sei denn, du zeichnest vollständige Markt-Ticks auf — das ist ein völlig anderes Dimensionierungsthema.

Step 1: a clean, outbound-only machineSchritt 1: eine saubere Maschine, nur ausgehend

Deploy an Ubuntu LTS image, then do the basics before anything touches the network: a non-root user, an SSH key, password login off, and a firewall that defaults to deny. Walkthroughs for both are at connect to your VPS over SSH and secure your VPS.Setze ein Ubuntu-LTS-Image auf und erledige dann die Grundlagen, bevor irgendetwas das Netzwerk berührt: einen Non-Root-User, einen SSH-Key, Passwort-Login aus, und eine Firewall, die standardmäßig blockiert. Anleitungen zu beidem findest du unter über SSH mit deinem VPS verbinden und deinen VPS absichern.

This workload only calls out — REST calls and a websocket to the exchange, nothing listening for inbound connections — so the shared, NAT-style IPv4 most budget VPS plans hand out by default is irrelevant here. No dedicated address or forwarded port needed for anything in this guide.Diese Last ruft nur nach außen — REST-Aufrufe und ein Websocket zur Börse, nichts hört auf eingehende Verbindungen —, deshalb ist die geteilte, NAT-artige IPv4, die die meisten günstigen VPS-Tarife standardmäßig vergeben, hier irrelevant. Für nichts in dieser Anleitung brauchst du eine dedizierte Adresse oder einen weitergeleiteten Port.

Create a dedicated system user for the bot rather than running it as your own login or as root:Leg einen eigenen System-User für den Bot an, statt ihn unter deinem eigenen Login oder als root laufen zu lassen:

sudo useradd --system --create-home --shell /usr/sbin/nologin botuser
sudo mkdir -p /opt/trading-bot/data
sudo chown -R botuser:botuser /opt/trading-bot

Deploy your code under /opt/trading-bot and build the virtualenv as botuser, not as yourself:Bring deinen Code nach /opt/trading-bot und bau das virtualenv als botuser, nicht als du selbst:

sudo -u botuser python3 -m venv /opt/trading-bot/venv
sudo -u botuser /opt/trading-bot/venv/bin/pip install -r /opt/trading-bot/requirements.txt

Step 2: the bot as a systemd serviceSchritt 2: der Bot als systemd-Service

A bot running in a tmux session survives an SSH disconnect but not a reboot, a crash, or you forgetting which pane it's in. A systemd unit survives all three and gives you a restart policy for free:Ein Bot, der in einer tmux-Session läuft, übersteht einen SSH-Abbruch, aber keinen Reboot, keinen Crash und nicht, dass du vergisst, in welchem Pane er läuft. Eine systemd-Unit übersteht alle drei und gibt dir eine Restart-Policy gratis dazu:

[Unit]
Description=trading-bot
After=network-online.target chrony.service
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=botuser
Group=botuser
WorkingDirectory=/opt/trading-bot
EnvironmentFile=/etc/trading-bot/env
ExecStart=/opt/trading-bot/venv/bin/python /opt/trading-bot/bot.py
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/trading-bot/data
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Two choices here are deliberate. StartLimitIntervalSec=300 with StartLimitBurst=5 stops a crash loop from hammering the exchange's API forever — after five restarts in five minutes, systemd gives up and leaves the unit stopped instead of retrying into a rate-limit ban. And Restart=on-failure, not Restart=always, only restarts the process on a non-zero exit status. That distinction is the whole point of the kill switch in Step 7, so hold onto it.Zwei Entscheidungen darin sind Absicht. StartLimitIntervalSec=300 mit StartLimitBurst=5 verhindert, dass eine Crash-Loop endlos auf die API der Börse einhämmert — nach fünf Neustarts in fünf Minuten gibt systemd auf und lässt die Unit gestoppt, statt sich in ein Rate-Limit-Verbot hineinzulaufen. Und Restart=on-failure, nicht Restart=always, startet den Prozess nur bei einem Exit-Status ungleich null neu. Genau diese Unterscheidung ist der ganze Sinn des Kill-Switches in Schritt 7, also merk sie dir.

Enable it now. Don't start it yet — the unit's EnvironmentFile doesn't exist until Step 3, and systemd refuses to start a service whose EnvironmentFile is missing:Aktiviere sie jetzt schon. Starte sie aber noch nicht — die EnvironmentFile der Unit existiert erst ab Schritt 3, und systemd weigert sich, einen Service zu starten, dessen EnvironmentFile fehlt:

sudo systemctl daemon-reload
sudo systemctl enable trading-bot.service

The systemd.service manual documents every directive above if you want the exact semantics rather than my summary of them.Das systemd.service-Manual dokumentiert jede Direktive von oben, falls du die exakte Semantik willst statt meiner Zusammenfassung.

Step 3: API keys in a root-only file, never in the repoSchritt 3: API-Keys in einer Datei nur für root, nie im Repo

The exchange API key and secret don't belong in your code, in a .env committed by accident, or in a config file readable by every user on the box. They belong in an EnvironmentFile only root can read:Der API-Key und das Secret der Börse gehören nicht in deinen Code, in eine versehentlich committete .env oder in eine Config-Datei, die jeder User auf der Maschine lesen kann. Sie gehören in eine EnvironmentFile, die nur root lesen kann:

sudo mkdir -p /etc/trading-bot
sudo touch /etc/trading-bot/env
sudo chown root:root /etc/trading-bot/env
sudo chmod 600 /etc/trading-bot/env

EXCHANGE_API_KEY=your-key-here
EXCHANGE_API_SECRET=your-secret-here

This works even though the service runs as the unprivileged botuser: systemd, running as root, reads EnvironmentFile before dropping privileges to start your process, and hands the resulting variables to the already-running process. The file itself never needs to be readable by botuser, so chmod 600 owned by root is the correct, final permission — not a temporary one you loosen later because something "couldn't read it."Das funktioniert, obwohl der Service als der unprivilegierte botuser läuft: systemd liest, während es als root läuft, die EnvironmentFile, bevor es die Rechte fallen lässt, um deinen Prozess zu starten, und übergibt die resultierenden Variablen an den bereits laufenden Prozess. Die Datei selbst muss für botuser nie lesbar sein, daher ist chmod 600 im Besitz von root die korrekte, endgültige Berechtigung — keine vorläufige, die du später lockerst, weil irgendetwas sie „nicht lesen konnte“.

Add the file's path to .gitignore before you write anything into it, and check with git status that it never shows up as untracked or staged. A key that reaches a private repo is still a key that reached a repo; rotate it if you're ever unsure.Trag den Pfad der Datei in die .gitignore ein, bevor du irgendetwas hineinschreibst, und prüfe mit git status, dass sie nie als untracked oder staged auftaucht. Ein Key, der in einem privaten Repo landet, ist trotzdem ein Key, der in einem Repo gelandet ist; rotiere ihn, wenn du dir jemals unsicher bist.

Now that /etc/trading-bot/env exists, start the service you enabled in Step 2:Jetzt, wo /etc/trading-bot/env existiert, starte den Service, den du in Schritt 2 aktiviert hast:

sudo systemctl start trading-bot.service
sudo systemctl status trading-bot.service

Step 4: clock sync with chronySchritt 4: Zeitsynchronisation mit chrony

Most exchange APIs sign requests with a timestamp and reject anything outside a tolerance window, often a few seconds. A drifted VPS clock gets -1021-style "timestamp outside recvWindow" errors on every signed call — it looks exactly like a broken bot and is actually a broken clock.Die meisten Börsen-APIs signieren Requests mit einem Timestamp und lehnen alles außerhalb eines Toleranzfensters ab, oft nur ein paar Sekunden. Eine VPS-Uhr, die driftet, bekommt bei jedem signierten Aufruf Fehler im Stil von -1021, „timestamp outside recvWindow“ — das sieht exakt wie ein kaputter Bot aus, ist aber tatsächlich eine kaputte Uhr.

Ubuntu 24.04 ships systemd-timesyncd by default, which is fine for most things but coarser than you want here. Chrony is the better fit for a machine that needs a tight, actively-monitored offset:Ubuntu 24.04 liefert standardmäßig systemd-timesyncd mit, was für die meisten Zwecke in Ordnung, aber gröber ist, als du hier willst. Chrony passt besser zu einer Maschine, die einen engen, aktiv überwachten Offset braucht:

sudo apt update
sudo apt install -y chrony
sudo systemctl disable --now systemd-timesyncd
sudo systemctl enable --now chrony

Confirm it's actually tracking, not just running:Bestätige, dass es tatsächlich trackt, nicht nur läuft:

chronyc tracking
chronyc sources -v

chronyc tracking should show a System time offset in the low milliseconds within a minute or two of starting. If it stays wide, check outbound UDP 123 isn't blocked by your firewall rules. The chrony documentation covers tuning makestep and source selection if the defaults don't converge fast enough.chronyc tracking sollte innerhalb von ein, zwei Minuten nach dem Start einen System time-Offset im niedrigen Millisekundenbereich zeigen. Bleibt er weit daneben, prüfe, ob ausgehendes UDP 123 nicht von deinen Firewall-Regeln blockiert wird. Die chrony-Dokumentation beschreibt, wie du makestep und die Source-Auswahl tunst, falls die Standardwerte nicht schnell genug konvergieren.

Step 5: structured logging you can actually grep at 3amSchritt 5: strukturiertes Logging, das du um 3 Uhr nachts wirklich grep-en kannst

Plain print() statements are fine for development and useless at 3am when you need the one line that explains why an order didn't go through. Log as JSON, one object per line, and let journald capture stdout — no separate log file needed:Simple print()-Anweisungen sind für die Entwicklung in Ordnung und um 3 Uhr nachts nutzlos, wenn du genau die eine Zeile brauchst, die erklärt, warum eine Order nicht durchging. Logge als JSON, ein Objekt pro Zeile, und lass journald stdout mitschneiden — keine separate Log-Datei nötig:

import json
import logging
import sys
import time


class JsonFormatter(logging.Formatter):
    def format(self, record):
        payload = {
            "ts": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime(record.created)),
            "level": record.levelname,
            "logger": record.name,
            "msg": record.getMessage(),
        }
        if record.exc_info:
            payload["exc"] = self.formatException(record.exc_info)
        return json.dumps(payload)


handler = logging.StreamHandler(sys.stdout)
handler.setFormatter(JsonFormatter())
logging.basicConfig(level=logging.INFO, handlers=[handler])

Because systemd already timestamps everything it captures, ask journalctl for the raw JSON without its own prefix when you want to pipe it somewhere:Weil systemd ohnehin schon alles mit einem Zeitstempel versieht, was es mitschneidet, frag journalctl nach dem rohen JSON ohne eigenes Präfix, wenn du es irgendwohin pipen willst:

journalctl -u trading-bot.service -o cat -f

journalctl rotates and caps its own storage by default, so you're not manually managing log files. If you add a second destination — a file, a shipper off-box — cap its size explicitly; an unbounded log file is a slow, quiet way to run out of disk.journalctl rotiert und deckelt seinen eigenen Speicher standardmäßig, sodass du keine Log-Dateien von Hand verwaltest. Fügst du ein zweites Ziel hinzu — eine Datei, einen Shipper außerhalb der Maschine —, deckle dessen Größe explizit; eine unbegrenzte Log-Datei ist eine langsame, leise Art, die Festplatte volllaufen zu lassen.

Step 6: a heartbeat so a dead bot doesn't stay deadSchritt 6: ein Heartbeat, damit ein toter Bot nicht tot bleibt

systemctl status tells you the process is running, not that it's doing anything useful — a bot can be alive, connected, and stuck in a loop that stopped placing orders hours ago, and Restart=on-failure never fires because nothing crashed.systemctl status sagt dir, dass der Prozess läuft, nicht, dass er etwas Sinnvolles tut — ein Bot kann am Leben, verbunden und in einer Schleife gefangen sein, die schon vor Stunden aufgehört hat, Orders zu platzieren, und Restart=on-failure greift nie, weil nichts gecrasht ist.

A dead man's switch fixes this, and it's a natural fit for an outbound-only bot: at the end of every successful loop, ping a monitoring URL.Ein Totmannschalter behebt das, und er passt natürlich zu einem Bot, der nur ausgehend kommuniziert: Am Ende jeder erfolgreichen Schleife pingst du eine Monitoring-URL an.

import urllib.request

def send_heartbeat(url: str) -> None:
    try:
        urllib.request.urlopen(url, timeout=5)
    except Exception:
        pass  # a missed heartbeat should never crash the bot

Call send_heartbeat() once per loop, after the real work succeeds, not before it. Pair it with a service that expects a ping on a schedule and pages you when one doesn't arrive — healthchecks.io is the standard example, and it's open source if you'd rather run it yourself. The mechanism matters more than the service: silence is the alert, which is exactly what catches a bot that's technically running but has quietly stopped doing anything.Ruf send_heartbeat() einmal pro Schleife auf, nachdem die eigentliche Arbeit erfolgreich war, nicht davor. Kombiniere es mit einem Dienst, der einen Ping nach Zeitplan erwartet und dich alarmiert, wenn keiner ankommt — healthchecks.io ist das Standardbeispiel, und es ist Open Source, falls du es lieber selbst betreiben willst. Der Mechanismus zählt mehr als der Dienst: Stille ist der Alarm, und genau das erwischt einen Bot, der technisch läuft, aber still aufgehört hat, irgendetwas zu tun.

Step 7: test the kill switch before you need itSchritt 7: teste den Kill-Switch, bevor du ihn brauchst

Every bot needs a way to stop trading immediately, without SSH access being the only lever. The simplest version is a file the bot checks each loop:Jeder Bot braucht eine Möglichkeit, sofort mit dem Handeln aufzuhören, ohne dass SSH-Zugriff der einzige Hebel ist. Die einfachste Version ist eine Datei, die der Bot bei jeder Schleife prüft:

from pathlib import Path

HALT_FILE = Path("/etc/trading-bot/HALT")

def should_halt() -> bool:
    return HALT_FILE.exists()

When should_halt() is true, the bot should cancel open orders it's responsible for, stop placing new ones, log that it halted and why, and exit cleanly with status 0. That last detail is why Restart=on-failure from Step 2 matters: a clean exit is not a failure, so systemd leaves the service stopped instead of bringing it straight back up mid-halt. With Restart=always the kill switch would look like it worked for about five seconds.Ist should_halt() wahr, sollte der Bot die offenen Orders, für die er verantwortlich ist, stornieren, keine neuen mehr platzieren, protokollieren, dass und warum er angehalten hat, und sich sauber mit Status 0 beenden. Genau dieses Detail ist der Grund, warum Restart=on-failure aus Schritt 2 wichtig ist: Ein sauberer Exit ist kein Fehler, also lässt systemd den Service gestoppt, statt ihn mitten im Halt sofort wieder hochzufahren. Mit Restart=always würde der Kill-Switch etwa fünf Sekunden lang so aussehen, als hätte er funktioniert.

Test this on a schedule, not just once after you write it: sudo touch /etc/trading-bot/HALT, watch the bot log its halt and exit, confirm with systemctl status that it's inactive and staying that way, then remove the file and start it again. A kill switch you've never triggered is a theory, not a control. Do this after every deploy that touches the shutdown path — that code is the least exercised by normal operation.Teste das regelmäßig, nicht nur einmal, nachdem du es geschrieben hast: sudo touch /etc/trading-bot/HALT, beobachte, wie der Bot seinen Halt protokolliert und sich beendet, bestätige mit systemctl status, dass er inaktiv ist und bleibt, entferne dann die Datei und starte ihn wieder. Ein Kill-Switch, den du nie ausgelöst hast, ist eine Theorie, keine Kontrolle. Mach das nach jedem Deploy, das den Shutdown-Pfad berührt — dieser Code wird im Normalbetrieb am seltensten durchlaufen.

Back up /etc/trading-bot and the bot's own data directory the same way you'd back up anything else that would hurt to lose — back up your VPS covers what that involves on our machines. A kill switch and a key file are both small, and both are exactly what people forget when "backup" means only the code in git.Sichere /etc/trading-bot und das eigene Datenverzeichnis des Bots genauso, wie du alles andere sicherst, dessen Verlust wehtun würde — Backup deines VPS beschreibt, was das auf unseren Maschinen bedeutet. Ein Kill-Switch und eine Key-Datei sind beide klein, und genau die vergisst man, wenn „Backup“ nur den Code in Git meint.

On overnight.hostBei overnight.host

Full disclosure: this is what we sell. A 1 GiB Starter runs a single Python bot process comfortably around the clock; move up a tier once you're running several bots at once, logging heavily, or keeping a local database of fills.Zur vollen Transparenz: Das ist, was wir verkaufen. Ein 1-GiB-Starter betreibt einen einzelnen Python-Bot-Prozess bequem rund um die Uhr; steige eine Stufe höher, sobald du mehrere Bots gleichzeitig laufen lässt, stark loggst oder eine lokale Datenbank mit Fills führst.

Linux KVM VPS — EUR 4.99 to EUR 59.99 a month, on our own single-tenant bare metal in Dallas, TX and Charlotte, NC. Full hardware virtualisation (KVM), your own kernel, full root. Six tiers, vps-starter to vps-ultra. Starter is 1 vCPU, 1 GiB RAM, 25 GB disk.Linux-KVM-VPS — 4,99 bis 59,99 EUR im Monat, auf unserer eigenen Single-Tenant-Bare-Metal-Hardware in Dallas, TX und Charlotte, NC. Vollständige Hardware-Virtualisierung (KVM), eigener Kernel, volles Root. Sechs Tarife, vps-starter bis vps-ultra. Starter hat 1 vCPU, 1 GiB RAM, 25 GB Speicher.

You order in the shop, pay by card (Stripe) or SEPA bank transfer, and your login details are e-mailed to you once the service is set up. Support is e-mail, run by one person, with no guaranteed response time. All prices are final totals under the German small-business rule (§19 UStG); no VAT is added or shown.Du bestellst im Shop, zahlst per Karte (Stripe) oder SEPA-Überweisung, und deine Zugangsdaten werden dir per E-Mail zugeschickt, sobald der Dienst eingerichtet ist. Support läuft per E-Mail, von einer einzelnen Person betrieben, ohne garantierte Reaktionszeit. Alle Preise sind Endpreise. Gemäß § 19 UStG wird keine Umsatzsteuer ausgewiesen.

Order vps-starter → · Linux KVM VPS overviewvps-starter bestellen → · Übersicht Linux-KVM-VPS

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.Geschrieben von der Person, die overnight.host betreibt: ein kleines, ehrliches Hosting-Unternehmen auf dedizierter Bare-Metal-Hardware — Linux-VPS, Gameserver, Webhosting. Live-Status unter up.overnight.host.