OpenClaw deployen - Schritt für Schritt auf einen KVM-VPS

Wer einen OpenClaw-Agenten produktiv betreiben will, kommt um einen eigenen Server kaum herum. Lokale Laptops schalten sich ab, Heim-Internet-Verbindungen verlieren die IP, und Managed-PaaS-Lösungen kosten ab dem ersten echten Workload mehr, als ein KVM-VPS für ein ganzes Jahr ausmacht. In dieser Lektion zeige ich dir Schritt für Schritt, wie du OpenClaw auf einen eigenen VPS bringst: von der Provider-Wahl über das Server-Initial-Setup, Docker-Installation, Reverse-Proxy mit Auth bis zu Backups, Monitoring und Logs. Am Ende hast du einen Stack, der Reboots übersteht, Updates wegsteckt und sich jederzeit umziehen lässt.

Anforderungen klären

Bevor du irgendwas bestellst oder installierst, musst du wissen, was dein Agent eigentlich braucht. Die meisten Fehlentscheidungen passieren genau hier: zu kleiner Server, falsches Betriebssystem, oder ein Provider, der nicht in der EU sitzt und damit DSGVO-Probleme verursacht. Schreib dir vor dem Bestellen drei Sachen auf: erwartete Last in Requests pro Minute, Speicherbedarf für State und Logs, und ob du lokale Modelle brauchst oder mit einer externen LLM-API arbeitest.

Für einen klassischen OpenClaw-Setup ohne lokale Modelle reichen 2 GB RAM und 1 vCPU vollkommen aus, solange du parallel nicht mehr als ein paar Dutzend Requests fährst. Sobald du lokale Modelle dazu nimmst, springst du in eine andere Liga: ein 7B-Modell unter Ollama braucht knapp 5 GB RAM, ein 13B-Modell schon 9 bis 11 GB. RAG-Setups mit Qdrant oder Weaviate schlagen mit weiteren 1 bis 2 GB zu Buche, je nach Vektor-Anzahl.

Beim Storage gilt: rechne mit mindestens 20 GB für das Betriebssystem plus Docker-Images, weitere 10 bis 20 GB für Logs und State (Conversation-History, Tool-Results, Embeddings-Cache). Wer RAG fährt und Embeddings persistieren will, sollte die Vektor-Datenbank großzügig kalkulieren: 100.000 Vektoren à 1536 Dimensionen brauchen rund 600 MB plain plus Index-Overhead, also realistisch ein bis zwei GB.

Beim Netzwerk ist entscheidend: hast du eine fixe IPv4? Brauchst du IPv6? Wirst du eine eigene Domain einrichten? Wenn dein Agent nach außen telefoniert (LLM-API, externe Tools, Webhooks), brauchst du keine besondere Inbound-Konfiguration. Sobald aber andere Systeme den Agent aufrufen sollen (etwa Slack-Webhooks, n8n, Make oder eigene Frontends), brauchst du eine erreichbare URL mit gültigem TLS-Zertifikat.

Letzter Punkt sind die regulatorischen Anforderungen. Wenn personenbezogene Daten durch den Agent fließen (und das ist bei den meisten echten Anwendungen der Fall), muss der Server in der EU stehen, idealerweise sogar in Deutschland. Außerdem brauchst du einen Auftragsverarbeitungsvertrag mit dem Provider. Die großen US-Cloud-Anbieter (AWS, GCP, Azure) bieten das zwar, sind aber für kleine Setups deutlich teurer und komplexer als ein DACH-VPS. Für die meisten Solopreneure und kleinen Teams ist ein KVM-VPS in Frankfurt oder Falkenstein die optimale Wahl.

Provider-Wahl - Warum Hostinger KVM

Die VPS-Landschaft ist unübersichtlich, und die Marketing-Versprechen aller Anbieter klingen ähnlich. Schauen wir auf die harten Fakten: was zählt für einen produktiven OpenClaw-Stack, sind verlässliche Performance, ein DACH-Standort, faire Preise und eine vernünftige Admin-Oberfläche. Genau hier punktet Hostinger KVM in der aktuellen Generation deutlich gegenüber den günstigen Mitbewerbern.

Hostinger betreibt mehrere Datacenter in Europa, darunter Frankfurt und Vilnius. Beide sind DSGVO-konform und liefern für DACH-Kunden niedrige Latenzen (typisch unter 20 ms aus deutschen Großstädten). Die KVM-Plattform basiert auf NVMe-SSDs, was für RAG-Workloads und Vektor-Datenbanken einen spürbaren Unterschied macht: Lese-Latenzen unter 100 Mikrosekunden statt mehrerer Millisekunden auf älteren SATA-SSDs.

Preislich liegt Hostinger im Einstiegssegment ganz vorne. Der KVM2 mit 2 vCPU, 8 GB RAM, 100 GB NVMe-SSD und 8 TB Traffic kostet aktuell 4,99 €/Monat (bei mehrjähriger Buchung). Das ist für einen produktiven Setup in der Größenordnung mindestens 30 Prozent günstiger als vergleichbare Hetzner-Cloud-Instanzen und etwa 20 Prozent günstiger als Netcup. Wer nur einen Agenten ohne lokale Modelle braucht, kommt sogar mit dem KVM1 (1 vCPU, 4 GB RAM) hin, der nochmal eine Klasse darunter liegt.

Was Hostinger besonders einsteigerfreundlich macht, ist die hpanel-Oberfläche. Reboot, Snapshot, Reinstall, Konsole-Zugang: alles drei Klicks. Die alternative Provider-Erfahrung (Hetzner, Netcup) ist mächtiger, aber für jemanden, der nicht jeden Tag in einer Cloud-Konsole sitzt, deutlich abschreckender. Außerdem bietet Hostinger eine 30-Tage-Geld-zurück-Garantie, was beim ersten Setup wertvoll ist: wenn die Maschine nicht passt, kannst du innerhalb des ersten Monats wieder raus.

Hetzner ist der harte Konkurrent für Performance-Liebhaber: Falkenstein und Nürnberg, sehr stabile Netze, Cloud-API für Automatisierung. Aber: Hetzner hat keine Affiliate-Verfügbarkeit (wichtig für uns, wenn wir die Akademie hier monetarisieren wollen), und der Einstieg ist UI-mäßig sperriger. Netcup punktet mit deutschen Standorten und langen Vertragslaufzeiten zu sehr niedrigen Preisen, aber die Buchungsstrecke ist umständlich, und der Support antwortet langsamer als bei Hostinger.

Strato schließlich ist der Klassiker für deutsche User, die Vertrauen in eine etablierte Marke suchen, aber preislich klar abgeschlagen: vergleichbare Specs kosten dort fast doppelt so viel wie bei Hostinger. Wer kein KMU-Mandat hat, das einen Anbieter mit deutschem Stammsitz vorschreibt, fährt günstiger anders.

Provider	DACH-Standort	Preis (4 GB RAM)	Setup-Zeit	Affiliate verfügbar
Hostinger	Frankfurt, Vilnius	4,99 €	unter 5 min	Ja
Hetzner	Falkenstein, Nürnberg	6,90 €	5-10 min	Nein
Netcup	Karlsruhe, Nürnberg	5,76 €	10-15 min	Nur teilweise
Strato	Berlin	8,00 €	5-10 min	Nein

Server-Initial-Setup

Du hast bestellt, die Mail mit der IP und dem Root-Passwort liegt in deinem Postfach. Jetzt geht es darum, in den ersten zehn Minuten alle elementaren Sicherheits- und Komfort-Themen zu erledigen, bevor du irgendeine produktive Software installierst. Diese Reihenfolge ist wichtig, weil ein frisch provisionierter VPS bereits nach Sekunden Brute-Force-Versuche auf SSH bekommt: die Bot-Netze scannen IPv4-Ranges in Echtzeit.

Logge dich zuerst per SSH als Root ein. Wenn du eine bessere Variante willst, lade vorher deinen Public-Key in die hpanel-Oberfläche, sodass du gleich passwortlos drin bist. Direkt nach dem Login: Passwort ändern (selbst wenn du dich gleich auf Key-Auth umstellst), neuen Sudo-User anlegen, Firewall aktivieren und das System komplett aktualisieren.

Mit dem neuen Sudo-User sperrst du anschließend Root-Login per SSH und schaltest die Passwort-Authentifizierung ab. Das ist nicht optional: ein Server mit aktivierter Root-Passwort-Anmeldung ist bei Public-IP innerhalb weniger Tage übernommen, wenn das Passwort nicht extrem stark ist. Lieber gleich richtig: Key-Auth, kein Root-SSH.

Die UFW-Firewall ist auf Ubuntu und Debian der einfachste Weg zu kontrolliertem Inbound-Traffic. Sie ist im Default mit Iptables verkabelt und läuft als Systemd-Service. Wir öffnen explizit nur SSH (Port 22), HTTP (80) und HTTPS (443). Alles andere bleibt zu, auch dann, wenn du später Container startest, die per Default an 0.0.0.0 binden würden: UFW filtert vor.

Direkt nach Firewall-Aktivierung: Fail2Ban installieren, mit den Default-Jails für SSH starten lassen. Fail2Ban liest die Auth-Logs und sperrt IPs, die mehr als ein paar fehlgeschlagene Logins produzieren. In Kombination mit Key-Auth-only ist das fast schon Overkill, aber es schadet nicht und filtert das Hintergrundrauschen weg. Außerdem reduziert es die Größe der auth.log, was bei Logfile-Analyse später hilft.

ssh root@<ip>
adduser deploy
usermod -aG sudo deploy
ufw allow OpenSSH && ufw enable
apt update && apt full-upgrade -y

Im Anschluss editierst du /etc/ssh/sshd_config, setzt PermitRootLogin no und PasswordAuthentication no, lädst per ssh-copy-id deinen Public-Key auf den Deploy-User, und startest SSH neu. Vor dem Reload unbedingt eine zweite Session offen halten, falls du dich aussperrst. Wenn die zweite Session funktioniert, kannst du die erste schließen und alle weiteren Schritte als Deploy-User mit sudo machen.

Docker installieren

Docker ist für die meisten Multi-Komponenten-Setups die richtige Wahl: dein Agent läuft in einem Container, die Vektor-Datenbank in einem anderen, der Reverse-Proxy in einem dritten. So bleiben die Komponenten sauber getrennt, lassen sich einzeln updaten, und du kannst Stacks per docker compose mit einem Befehl hochfahren oder zerlegen.

Die Installation per Distro-Paket (apt install docker.io) liefert auf Ubuntu und Debian oft eine veraltete Docker-Version. Besser ist es, das offizielle Docker-Repository einzubinden und von dort zu installieren. Das gibt dir eine aktuelle Engine, das compose-Plugin und automatische Updates über apt. Achte darauf, danach den Deploy-User zur Docker-Gruppe hinzuzufügen, damit du Container ohne sudo starten kannst (sudo usermod -aG docker deploy, danach einmal aus- und wieder einloggen).

Nach der Installation testest du mit docker run hello-world und docker compose version, dass alles läuft. Wenn das funktioniert, hast du ein produktives Docker-Setup, mit dem du sofort weitermachen kannst.

apt install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian $(lsb_release -cs) stable" \
  > /etc/apt/sources.list.d/docker.list
apt update && apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

OpenClaw als Docker-Container

Jetzt geht es ans Eigentliche: dein OpenClaw-Agent als Container. Wir bauen den Stack mit zwei Dateien, einem Dockerfile, das das Container-Image definiert, und einer docker-compose.yml, die den Container plus eventuelle Begleit-Services orchestriert. Dieser Ansatz hat sich bewährt, weil er reproduzierbar ist (alle Configs liegen im Git-Repo des Projekts) und sich zwischen Entwicklungsmaschine und Server praktisch nicht unterscheidet.

Das Dockerfile setzt auf einem schlanken Python-3.12-Slim-Image auf, kopiert die requirements.txt rein, installiert die Abhängigkeiten und kopiert dann den Code. Das ist die klassische Layer-Struktur: solange die requirements.txt sich nicht ändert, wird der teure pip-Install-Layer aus dem Cache genommen, und nur der Code-Layer wird neu gebaut. Bei jedem Code-Push baut das Image dann in wenigen Sekunden statt Minuten.

# Dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "-u", "agent.py"]

In der docker-compose.yml verkabeln wir den Container mit der Außenwelt. Wichtig sind drei Dinge: restart: always (damit der Container beim Reboot oder Crash automatisch wieder startet), env_file: .env (damit Secrets wie API-Keys nicht im Image landen, sondern aus einer separaten Datei kommen), und das Port-Mapping mit Bind auf 127.0.0.1 (damit der Container nicht direkt aus dem Internet erreichbar ist, sondern nur über den Reverse-Proxy).

# docker-compose.yml
services:
  agent:
    build: .
    restart: always
    env_file: .env
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./data:/app/data

Das Volume-Mount auf ./data ist wichtig: alle persistenten Daten (Conversation-History, Cache, eventuelle SQLite-Datenbanken) liegen damit außerhalb des Containers im Filesystem des Hosts. Du kannst den Container jederzeit zerstören und neu bauen, ohne State zu verlieren. Außerdem lassen sich die Daten so trivial sichern: ein tar oder restic backup über das data-Verzeichnis genügt.

Den Stack startest du mit docker compose up -d (das -d heißt detached, also im Hintergrund). Du kannst die Logs mit docker compose logs -f agent mitlaufen lassen und mit docker compose ps den Status checken. Updates laufen so: git pull && docker compose build agent && docker compose up -d agent. Der laufende Container wird durch den neuen ersetzt, der State im Volume bleibt erhalten.

Reverse-Proxy mit Caddy

Der Container lauscht jetzt auf 127.0.0.1:8080, also nicht von außen erreichbar. Damit der Agent über eine Domain mit gültigem TLS-Zertifikat ansprechbar wird, brauchst du einen Reverse-Proxy. Caddy ist hier in den letzten Jahren zur Standard-Wahl geworden, weil er TLS-Zertifikate automatisch via Let’s Encrypt holt und erneuert: kein Bash-Skript, kein Cronjob, keine Acme-Challenge zu Fuß.

Installation auf Debian und Ubuntu: das offizielle Caddy-APT-Repository einbinden und apt install caddy. Caddy wird als Systemd-Service mit dem User caddy installiert. Die Konfiguration liegt unter /etc/caddy/Caddyfile, und ein systemctl reload caddy lädt Änderungen ohne Verbindungsabbruch nach.

Dein Caddyfile ist erstaunlich kurz. Du definierst die Domain, fügst eine Basic-Auth-Direktive für minimale Zugriffsabsicherung dazu (die der Agent zusätzlich zu seiner internen Auth bekommt), und reichst alle Requests an den lokalen Container weiter. Caddy übernimmt automatisch HTTPS-Redirect, HSTS, OCSP-Stapling und Zertifikatserneuerung.

agent.deinedomain.de {
  basicauth {
    deploy <htpasswd-hash>
  }
  reverse_proxy 127.0.0.1:8080
}

Den htpasswd-hash für die Basic-Auth erzeugst du mit caddy hash-password. Wichtig: Basic-Auth ist kein Ersatz für richtige Authentifizierung im Agent selbst, sondern eine zusätzliche Schicht. Wer den Endpoint überhaupt erreicht, hat die Basic-Auth schon passiert; danach muss der Agent eigene Auth-Header (etwa Bearer-Tokens) prüfen. Diese Defense-in-Depth-Logik schützt dich vor Bugs in der eigenen Auth-Implementierung.

DNS-Setup: ein A-Record (und optional ein AAAA-Record für IPv6) auf die VPS-IP, TTL 300 für die ersten Tests, danach hochsetzen auf 3600. Sobald DNS propagiert ist (meistens innerhalb weniger Minuten), läuft Caddy beim ersten Aufruf über die Domain die Acme-HTTP-Challenge durch, holt das Zertifikat und parkt es lokal ab. Das ist das einzige Mal, dass Port 80 wirklich gebraucht wird; danach läuft alles über 443.

Wenn du mehrere Agents oder Apps auf dem gleichen Server hostest, ergänzt du einfach weitere Domain-Blöcke im Caddyfile. Caddy demuxt anhand des Host-Headers und routet entsprechend. Das ist ein gewaltiger Vorteil gegenüber Nginx, wo du mit Server-Blocks und einer komplexeren Direktive-Logik arbeiten musst.

Systemd-Alternative ohne Docker

Nicht jeder will Docker. Für einen einzelnen Agenten ohne Begleit-Services ist ein nackter Systemd-Service oft eleganter: kein Container-Layer, kein Image-Build, einfach ein Python-Prozess unter einem dedizierten User mit klar definiertem Working-Directory. Du sparst dir die Docker-Ressourcen (etwa 200 MB Overhead pro Container für Filesystem-Layering und Netzwerk-Namespaces) und behältst direkten Zugriff auf den Prozess.

Voraussetzung: du hast Python 3.12 installiert (auf Ubuntu 24.04 ist das Default, auf Debian 12 nimm apt install python3.12 python3.12-venv oder das deadsnakes-PPA), legst ein Virtualenv unter ~/agent/.venv an und installierst dort die Dependencies. Den Agent-Code spielst du via Git oder direkt mit scp auf den Server.

Der Systemd-Service wird unter /etc/systemd/system/openclaw-agent.service abgelegt. Wichtig sind die Zeilen User=deploy (kein Root!), WorkingDirectory=/home/deploy/agent, EnvironmentFile=/home/deploy/agent/.env für die Secrets, und Restart=always mit RestartSec=5. Letzteres sorgt dafür, dass der Agent nach einem Crash innerhalb von fünf Sekunden wieder hochfährt.

# /etc/systemd/system/openclaw-agent.service
[Unit]
Description=OpenClaw Agent
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/home/deploy/agent
EnvironmentFile=/home/deploy/agent/.env
ExecStart=/home/deploy/agent/.venv/bin/python agent.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Aktivieren mit systemctl daemon-reload && systemctl enable --now openclaw-agent. Status checken mit systemctl status openclaw-agent, Logs mit journalctl -u openclaw-agent -f. Das Update-Pattern ist trivial: git pull im Working-Directory, dann systemctl restart openclaw-agent. Der Service zieht den neuen Code, startet den Python-Prozess neu, und du bist fertig.

Für die meisten Solo-Setups ist diese Variante in der Praxis schneller deployed und einfacher zu debuggen als Docker. Die Grenze liegt da, wo du mehrere Komponenten brauchst (Agent + Vektor-DB + Cache + Worker): dann lohnt sich Docker, weil die Service-Definitionen und Netzwerk-Verkabelung in compose-Dateien sauber kapselbar sind.

Backups

Backup-Strategie ist der Punkt, an dem die meisten Hobby-Setups scheitern. Es genügt nicht, irgendwo eine Sicherung anzulegen: du brauchst tägliche, automatisierte, off-site gelagerte und regelmäßig getestete Backups. Sonst hast du im Ernstfall ein Backup, das nicht restore-fähig ist, und das ist schlechter als gar keins, weil es ein falsches Sicherheitsgefühl produziert.

Erste Verteidigungslinie: Volume-Snapshots beim VPS-Provider. Hostinger, Hetzner und Netcup bieten alle automatische tägliche Snapshots an, meist gegen einen Aufpreis von 1 bis 3 € pro Monat. Diese Snapshots sind block-level-Kopien des gesamten Filesystems und lassen sich mit zwei Klicks zurückspielen. Nachteil: sie liegen beim selben Provider, im Worst-Case-Fall (Account-Übernahme, Provider-Pleite, juristische Beschlagnahme) sind sie genauso betroffen wie die Live-Maschine.

Zweite Verteidigungslinie: Off-Site-Backups mit restic oder borgbackup zu einem unabhängigen Storage-Provider. Backblaze B2 ist hier der Preis-Leistungs-Sieger (rund 5 €/TB/Monat plus minimaler Egress-Kosten), Hetzner Storage Box ist die DACH-Alternative (1 TB für 4 €/Monat, fast kein Egress). restic macht inkrementelle, deduplizierte und verschlüsselte Backups, du brauchst nur ein Cronjob, der einmal pro Tag läuft.

Restore-Tests sind nicht optional. Mindestens einmal pro Quartal solltest du einen leeren VPS provisionieren und dein letztes Backup darauf zurückspielen. Erst wenn der Agent dort startet und die letzten paar Conversations korrekt fortsetzbar sind, weißt du, dass dein Backup wirklich funktioniert. Ich habe in der Vergangenheit dreimal Backups gehabt, die formal vorhanden, aber faktisch unbrauchbar waren: einmal wegen vergessener Encryption-Keys, einmal wegen falscher Pfad-Definition, einmal wegen einer SQLite-Datei, die mitten im Write zur Sicherung kam und damit korrupt war.

Wichtige Pfade in der Backup-Liste: /home/deploy/agent/data (oder das Docker-Volume), /home/deploy/agent/.env, /etc/caddy/Caddyfile, /etc/systemd/system/openclaw-agent.service, und alles unter /etc/letsencrypt falls du Caddy nicht verwendest und stattdessen Certbot nutzt. Datenbanken sicherst du nicht über das Filesystem, sondern via pg_dump oder dem nativen SQLite-Backup-API: ein Live-Filesystem-Snapshot einer aktiven DB ist mit hoher Wahrscheinlichkeit korrupt.

Monitoring und Healthchecks

Ein produktiver Agent muss überwacht werden. Das fängt mit einem trivialen Healthcheck an: dein Agent exponiert einen /health-Endpoint, der einen 200er liefert, wenn alles okay ist, und einen 503er sonst. Im einfachsten Fall prüft der Endpoint, ob die LLM-API erreichbar ist und ob die Datenbank antwortet. Schon dieser eine Endpoint ist die Basis für 80 Prozent der weiteren Monitoring-Logik.

Zweite Stufe: ein externer Uptime-Checker, der den /health-Endpoint alle paar Minuten anpingt und bei Ausfällen alarmiert. Selbstgehostet ist Uptime-Kuma die populärste Wahl (Open Source, läuft als Docker-Container, schicke UI), als Managed-Variante sind UptimeRobot oder BetterStack etabliert. Wichtig: die Alerts müssen einen Kanal nutzen, den du auch außerhalb der Arbeitszeit liest. Email allein ist meistens zu lasch, Slack oder Telegram sind robuster.

Dritte Stufe: System-Metriken. Hier ist Prometheus plus Grafana der Industriestandard, aber für kleine Setups oft Overkill. Eine pragmatische Variante ist Netdata: ein einzelner Agent, der CPU, RAM, Disk-IO, Netzwerk und Prozess-Statistiken sammelt und über eine eigene Web-UI visualisiert. Die kostenlose Cloud-Version aggregiert mehrere Server in einer einzigen Oberfläche.

Vierte Stufe (für Profis): Application-Metriken aus dem Agent selbst. Mit prometheus_client in Python exponierst du einen /metrics-Endpoint mit Counter (wie viele Requests verarbeitet?), Histogram (wie lange dauert ein Tool-Call?) und Gauge (wie viele Conversations laufen gerade?). Prometheus scrapt diese Metriken alle 15 Sekunden und speichert sie zeitlich indiziert ab; Grafana visualisiert sie. Damit erkennst du Drift in der LLM-Latency, ungewöhnliche Tool-Call-Muster oder ausgelastete Worker, lange bevor User sich beschweren.

Was du in jedem Fall brauchst, ist Notify-on-Failure für Systemd-Services. Wenn dein Agent als Systemd-Service läuft und crasht, stopp und kein Alarm, ist das ein lautloser Ausfall. Mit OnFailure=alert@%n.service in der Service-Definition triggerst du einen separaten Alert-Service (etwa ein Skript, das via curl einen Slack- oder Telegram-Webhook ruft). So weißt du innerhalb von Sekunden, wenn etwas Fatales passiert.

Logs

Logs sind der erste Anlaufpunkt im Debugging-Fall. Sobald irgendwas schiefgeht (LLM-Timeout, Tool-Call-Fehler, OOM-Kill), ist das Log das Erste, was du brauchst. Deshalb: logge strukturiert, logge ausreichend, und sorge für Rotation, damit dir die Disk nicht volläuft.

Strukturiert heißt JSON-Lines, kein freier Text. Mit structlog oder python-json-logger in Python schreibst du jede Log-Zeile als JSON-Objekt mit festen Feldern: timestamp, level, message, request_id, user_id, tool, duration_ms. Das ist trivial maschinenlesbar und lässt sich später mit jq oder einer Aggregator-Pipeline analysieren. Plain-Text-Logs kannst du in einer Krise nicht performant durchsuchen.

Wenn dein Agent als Systemd-Service läuft, landen die Logs automatisch in journald. Du liest sie mit journalctl -u openclaw-agent -f (live), journalctl -u openclaw-agent --since "1 hour ago" (Range), oder journalctl -u openclaw-agent -p err (nur Errors). journald macht automatische Rotation und komprimiert ältere Einträge; mit journalctl --disk-usage siehst du den Speicher-Verbrauch und kannst mit journalctl --vacuum-time=30d alles über 30 Tage hinaus löschen.

Bei Docker-Containern verwendest du den json-file-Driver mit max-size und max-file Limits, damit ein einzelner Container nicht die ganze Disk füllen kann. Das gehört in die docker-compose.yml unter logging.options. Alternativ leitest du Container-Logs an Loki (Grafana-Stack) weiter, das ist die produktive Variante für Multi-Container-Setups: zentrale Aggregation, indizierte Suche, Retention konfigurierbar.

Kosten-Beispielrechnung

Wer den ganzen Stack realistisch durchrechnet, kommt für einen Solo- oder Kleinteam-Setup auf monatliche Kosten zwischen 15 und 55 €, abhängig vor allem davon, wie viel LLM-API-Verkehr fließt. Der VPS selbst ist die kleinste Position; das eigentliche Geld geht an den LLM-Provider.

Hostinger KVM2 mit 2 vCPU, 8 GB RAM und 100 GB NVMe kostet bei mehrjähriger Buchung 4,99 €/Monat. Ein Backup-Aufpreis (Off-Site via Backblaze B2 für 100 GB) liegt bei rund 0,50 €/Monat. Domain-Kosten für eine .de-Domain bei einem ordentlichen Registrar etwa 0,75 €/Monat. Die Caddy-Installation ist gratis, ebenso Uptime-Kuma als selbst gehostete Komponente.

Die LLM-API ist die größte und schwankendste Position. Bei OpenAI GPT-4o mini liegen die Kosten pro 1 Million Input-Token bei rund 0,15 USD, pro 1 Million Output-Token bei 0,60 USD. Ein klassischer Agent mit 50 Conversations am Tag und je 5.000 Token Input plus 1.500 Token Output verbraucht im Monat rund 7,5 Mio. Input-Token und 2,25 Mio. Output-Token, was umgerechnet etwa 2,50 € sind. Beim Wechsel auf GPT-4.1 oder Claude Sonnet steigt das auf 25 bis 50 €. Wer 500 Conversations pro Tag fährt, landet schnell bei 100 bis 200 €.

Position	Provider	Monatlich
KVM2 VPS	Hostinger	4,99 €
Off-Site-Backup (100 GB)	Backblaze B2	0,50 €
Domain (.de)	beliebig	0,75 €
LLM-API (50 Conv/Tag, GPT-4o mini)	OpenAI	2,50 €
LLM-API (50 Conv/Tag, Claude Sonnet)	Anthropic	25,00 €
Uptime-Monitoring	self-hosted	0,00 €
Summe (klein)		rund 9 €
Summe (mittel)		rund 32 €

Nächster Schritt

Du hast jetzt einen produktiven OpenClaw-Stack: VPS, Docker oder Systemd, Reverse-Proxy mit TLS, Backups, Monitoring und Logs. Was als Nächstes kommt, sind die typischen Stolpersteine, die niemand vorher dokumentiert: Endlosschleifen in Tool-Calls, Memory-Leaks bei langen Conversations, Race-Conditions zwischen parallelen Workern. Genau diese Themen behandelt das nächste Modul.

Modul 6 - Anti-Patterns