OpenClaw auf VPS hosten: Der komplette Guide 2026

OpenClaw ist einer der spannendsten Trends im Self-Hosting-Bereich: Ein autonomer KI-Assistent, der nicht nur chattet, sondern aktiv mit deinen Tools und Kanälen arbeitet. Statt nur Fragen zu beantworten, kann er Aufgaben planen, Erinnerungen schicken, Nachrichten einordnen und Aktionen auslösen.

Genau deshalb brauchst du beim Hosting eine klare Strategie. Sobald ein Agent Zugriff auf Messaging-Kanäle, Automationen oder Shell-Kommandos bekommt, reichen "läuft lokal auf meinem Laptop" und "mache ich später sicher" nicht mehr aus. Du brauchst Stabilität, Isolation und Sicherheitsgrenzen von Anfang an.

In diesem Guide zeige ich dir Schritt für Schritt, wie du OpenClaw auf einem VPS betreibst, welche Hardware wirklich nötig ist, wie du Telegram/WhatsApp/Discord sauber anbindest und welche Security-Maßnahmen nicht optional sind.

1. Was ist OpenClaw?

OpenClaw ist ein Open-Source-KI-Assistent aus dem Umfeld von Peter Steinberger (@steipete) und dem Agentic-Tooling-Ökosystem. Die zugehörigen Repositories sind extrem schnell gewachsen und erreichen zusammen inzwischen sechsstellige Star-Zahlen (186k+ als häufig zitierte Größenordnung in der Community).

Der Kernunterschied zu klassischen Chat-Frontends:

• OpenClaw verbindet LLMs mit echten Kanälen wie WhatsApp, Telegram, Discord, iMessage und Slack.
• OpenClaw arbeitet proaktiv: mit Memory, geplanten Jobs (Cron) und automatischen Folgeaktionen.
• OpenClaw lässt sich durch Skills/Integrationen erweitern (z. B. via ClawdHub-ähnliche Marktplatz-Konzepte).

Das ist mächtig, weil dein Agent nicht nur reagiert, sondern für dich arbeitet. Es ist aber auch riskant, weil du einer KI de-facto operative Rechte geben kannst.

Faustregel: Ein Chatbot ohne Tool-Zugriff ist ein Textsystem. Ein Agent mit Shell/Tooling ist ein kleines Betriebssystem-Projekt. Behandle es auch so.

2. Warum VPS statt lokal?

Lokales Hosting (Mac Mini, NUC, Raspberry Pi, alter Homeserver) kann für Tests reichen. Für einen produktiven AI-Agenten mit Messaging-Kanälen ist ein VPS fast immer robuster.

Gerade bei Channel-Agenten ist "immer online" nicht nur Komfort, sondern funktional wichtig. Wenn dein Prozess bei lokalen Neustarts oder Schlafmodus regelmäßig weg ist, verlierst du Events, Sessions und Vertrauen in den Agenten.

3. Hardware-Anforderungen

Für OpenClaw hängt der Ressourcenbedarf vor allem von vier Faktoren ab:

1. Anzahl paralleler Channels
2. Teamgröße und gleichzeitige Nutzung
3. Cloud-API vs. lokale LLM-Inferenz
4. Nebenprozesse (Queue, Logs, Tools, Browser-Automation)

Profile für den Start

Wichtiger Praxispunkt: Updates brauchen RAM-Spikes

Viele OpenClaw-Setups ziehen bei Build-/Preflight-Schritten kurzfristig deutlich mehr RAM als im laufenden Betrieb. 4-GB-Instanzen kippen dabei gerne in OOM.

Empfehlung: Auch bei kleinem Setup Swap einrichten (mind. 2-4 GB), besonders wenn du Docker-Updates oder neue Plugin-Builds fährst.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

4. Installation

OpenClaw lässt sich auf drei Arten betreiben. Für Produktion empfehle ich Docker mit klaren Netzgrenzen.

Option A: Manuell (maximale Kontrolle)

Voraussetzung: Node.js 22+

# Node 22 installieren (Beispiel für Ubuntu)
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs build-essential

# OpenClaw global installieren
sudo npm install -g openclaw

# Onboarding + Daemon-Setup
openclaw onboard --install-daemon

Prüfen:

systemctl status openclaw
openclaw --version

Vorteil: maximale Transparenz. Nachteil: mehr manueller Pflegeaufwand.

Option B: Docker (empfohlen)

Wichtig: Gateway-Port nicht direkt öffentlich binden. Erst lokal (127.0.0.1), dann gezielt über Tunnel/VPN freigeben.

services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - OPENCLAW_HOME=/data
      - GATEWAY_AUTH_TOKEN=${GATEWAY_AUTH_TOKEN}
    ports:
      - "127.0.0.1:3434:3434"
    volumes:
      - ./data:/data
      - /var/log/openclaw:/var/log/openclaw
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3434/health"]
      interval: 30s
      timeout: 5s
      retries: 5

Start:

docker compose up -d
docker compose logs -f --tail=100

Option C: One-Click Templates

Einige Provider bieten vorgefertigte Templates (z. B. Hostinger/Contabo-Ökosystem). Das ist schnell für Tests, aber prüfe immer:

• Wird der Gateway-Port öffentlich exponiert?
• Ist Auth standardmäßig aktiv?
• Sind Update-Strategie und Backup-Pfade dokumentiert?

Wenn du diese Fragen nicht sofort beantworten kannst, ist ein eigenes Compose-Setup meist sicherer.

5. Channels verbinden

Telegram (schnellster Einstieg)

1. In Telegram @BotFather öffnen
2. /newbot ausführen und Token erzeugen
3. Token als Secret in OpenClaw hinterlegen
4. Bot in gewünschte Chats/Channels einladen

WhatsApp (Session über QR)

1. WhatsApp-Connector aktivieren
2. QR-Code im OpenClaw-Gateway scannen
3. Session-State persistent speichern (Volume!)
4. Reconnect-Handling prüfen (nach Reboot)

Discord

1. Discord Developer Portal öffnen
2. Bot-App erstellen und Token erzeugen
3. Benötigte Intents aktivieren
4. Bot in Server einladen und Berechtigungen minimal halten

Praxis-Tipp: Erst Telegram stabil machen, dann WhatsApp/Discord ergänzen. So isolierst du Fehlerquellen.

6. Sicherheit (wichtigster Abschnitt)

Ein Agent mit Kanal- und Tool-Zugriff ist ein potenzieller Angriffsvektor. Nimm diese Punkte als Pflichtprogramm.

6.1 Gateway niemals öffentlich exponieren

Direktes 0.0.0.0:PORT ohne Schutz ist ein No-Go.

Besser:

• SSH-Tunnel für Admin-Zugriff
• Tailscale/WireGuard für internes Overlay-Netz
• Reverse Proxy mit IP-Allowlist + Auth + Rate Limit

SSH-Tunnel Beispiel:

ssh -N -L 3434:localhost:3434 user@dein-vps

6.2 gateway.auth.token immer setzen

Auch intern darf es keinen "offenen" Agent geben.

GATEWAY_AUTH_TOKEN=ein-langer-zufaelliger-token-mit-viel-entropie

6.3 UFW Firewall hart konfigurieren

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow from 100.64.0.0/10 to any port 3434  # Beispiel: Tailscale Range
sudo ufw enable
sudo ufw status verbose

6.4 Dedizierte Service-Accounts

• Kein Root-Login für Agent-Prozesse
• Keine persönlichen OAuth-Tokens direkt im Agent
• Für produktive Integrationen eigene technische Accounts nutzen

6.5 Prompt-Injection ist real

Es gab bereits Community-Berichte, in denen Agenten durch manipulierte Eingaben unerwünschte Aktionen ausgeführt haben (z. B. Löschaktionen in angebundenen Mail-Kontexten). Das ist kein theoretisches Risiko.

Gegenmaßnahmen:

• Tool-Berechtigungen minimal halten
• Kritische Aktionen mit menschlicher Freigabe
• Harte Allow-/Deny-Listen für Kommandos
• Logging und Alerting für riskante Aktionen

6.6 Modellwahl für robuste Guardrails

Für sicherheitskritische Agent-Flows bevorzugen viele Teams aktuell Modelle mit hoher Resistenz gegen Prompt-Injection. In der Praxis wird häufig Claude Opus 4.5 als stabile Option genannt. Das ersetzt keine Architektur-Sicherheit, verbessert aber oft die Zuverlässigkeit der Policy-Einhaltung.

6.7 Minimales Produktions-Baseline (Checkliste)

Wenn du OpenClaw produktiv nutzt, sollte dein Setup mindestens diese Punkte erfüllen:

• Network Boundary: Gateway nur intern erreichbar (localhost + Tunnel/VPN).
• Authentication: Starker Gateway-Token, regelmäßig rotiert.
• Secrets Hygiene: Keine Secrets im Klartext-Repo, nur .env + Secret Store.
• Least Privilege: Jede Integration mit eigenem technischen Account.
• Action Guardrails: Kritische Aktionen (Löschen, Schreiben, Senden) nur mit expliziter Freigabe.
• Audit Logging: Jede Tool-Ausführung mit Timestamp, Prompt-Kontext und Exit-Code protokollieren.
• Alerting: Benachrichtigung bei ungewöhnlichen Mustern (z. B. 50+ Tool-Calls in kurzer Zeit).
• Backups: Tägliches Backup von Konfiguration, Session-State und Agent-Memory.

Eine einfache Struktur ist oft ausreichend:

1. openclaw Container (Agent Runtime)
2. reverse-proxy Container (nur intern oder VPN)
3. log-shipper (optional) für zentrale Logs
4. backup-cron für tägliche Dumps/Snapshots

Wenn eines dieser Elemente fehlt, ist das kein Showstopper - aber das Risiko steigt spürbar. Gerade bei Agenten gilt: Betriebssicherheit entsteht nicht durch ein einzelnes Tool, sondern durch mehrere kleine Sicherheitsgrenzen.

7. Kostenvergleich

OpenClaw kann sehr günstig sein - aber nur, wenn du Infrastruktur- und API-Kosten zusammen betrachtest.

Wenn du technisch fit bist und mehrere Kanäle willst, ist Self-Hosting meistens das beste Preis-Leistungs-Verhältnis.

Realistische Monats-Szenarien

Viele unterschätzen nicht den VPS-Preis, sondern die variable Modellnutzung. Für Planung helfen drei einfache Szenarien:

Wichtig: Lokale LLMs senken API-Kosten, erhöhen aber Infrastrukturkosten (RAM/CPU, ggf. längere Antwortzeiten auf CPU). Für viele Teams ist ein Hybrid-Modell optimal: Standardaufgaben lokal, komplexe Aufgaben via API.

Versteckte Kosten, die du einplanen solltest

• Betriebszeit: Updates, Incident-Fixes, Monitoring
• Backups: Storage-Snapshots oder externe Backup-Ziele
• Sicherheitsaufwand: regelmäßige Token-Rotation und Access-Reviews
• Ausfallkosten: wenn Agent-Flows in produktive Prozesse eingebunden sind

Diese Punkte sprechen nicht gegen Self-Hosting. Sie helfen dir nur, realistisch zu planen statt zu knapp zu kalkulieren.

Live-Angebote für passende VPS

Anbieter	Produkt	vCPU	RAM	Storage	Preis/Mo
	VPS 500 G12	2	4 GB	128 GBSSD	5.91	Angebot
	CPX42	8	16 GB	240 GBNVMe SSD	30.33	Angebot
	AMD Ryzen 12 Cores	12	64 GB	1000 GBNVMe SSD	102.82	Angebot

8. Troubleshooting (Top 5)

1) gateway.lock blockiert Neustart

Symptom: Agent startet nach Crash/Update nicht neu.

rm -f /opt/openclaw/data/gateway.lock
systemctl restart openclaw

2) WhatsApp Error 515

Symptom: Session bricht regelmäßig ab oder QR wird ständig neu verlangt.

Fix:

• Connector updaten
• Persistentes Volume prüfen
• Session neu pairen, dann Reconnect-Interval erhöhen

3) OOM bei Updates/Builds

Symptom: Container wird beim Update gekillt.

Fix:

• Swap aktivieren (siehe Abschnitt Hardware)
• Build parallelism reduzieren
• Bei häufigen Updates auf 8 GB RAM skalieren

4) Config fehlt nach abgebrochenem Onboarding

Symptom: OpenClaw startet ohne gültige Konfiguration.

Fix:

• Konfigurationsverzeichnis löschen
• Onboarding erneut sauber durchlaufen
• Secrets direkt danach sichern (Backup/Passwortmanager)

5) Discord Rate-Limits

Symptom: verzögerte Antworten oder temporäre API-Fehler.

Fix:

• Queue mit Backoff einbauen
• Burst-Aktionen reduzieren
• Kanal-spezifische Cooldowns definieren

Bonus: Backup- und Rollback-Strategie

Wenn OpenClaw in echte Workflows integriert ist, brauchst du einen klaren Rollback-Pfad:

1. Vor jedem Update Snapshot von data/ + .env erzeugen
2. Update in Wartungsfenster mit aktivem Log-Tailing
3. Smoke-Test: Healthcheck, Telegram Ping, Discord Testnachricht
4. Rollback bei Fehlern innerhalb von 5 Minuten vorbereiten

Minimal-Backup per tar:

tar -czf openclaw-backup-$(date +%F).tar.gz ./data ./.env docker-compose.yml

Damit stellst du notfalls innerhalb weniger Minuten den letzten funktionierenden Stand wieder her.

Launch-Check für die ersten 7 Tage

Nach Go-Live lohnt sich ein kurzer, täglicher Kontrolllauf:

• Tag 1-2: Prüfe alle Channel-Verbindungen und Reconnect-Verhalten nach Neustarts.
• Tag 3-4: Überwache Latenzspitzen und API-Fehlerquoten in Stoßzeiten.
• Tag 5-6: Simuliere absichtlich fehlerhafte Eingaben, um Guardrails zu testen.
• Tag 7: Review der Logs und Anpassung von Cooldowns, Timeouts, Rate-Limits.

Ein solcher Mini-Betriebszyklus verhindert, dass sich kleine Konfigurationsfehler zu größeren Sicherheits- oder Stabilitätsproblemen entwickeln.

9. Fazit

OpenClaw auf VPS zu hosten ist heute einer der stärksten Wege, einen wirklich nützlichen KI-Assistenten produktiv zu betreiben: 24/7 erreichbar, kanalübergreifend einsetzbar und mit voller Kontrolle über Daten und Infrastruktur.

Der wichtigste Erfolgsfaktor ist nicht nur das Setup, sondern die Sicherheitsarchitektur: kein offenes Gateway, saubere Auth, klare Rechte und observability von Tag 1.

Wenn du klein startest, ist das kein Nachteil. Ein sauber abgesichertes 4-GB-Setup ist in der Praxis wertvoller als ein großes, aber unsicheres 16-GB-System. Erst Stabilität, dann Skalierung. So bleiben Kosten, Risiko und Komplexität im Gleichgewicht.

Wenn du noch unsicher bei der Servergröße bist, starte mit dem Rechner und skaliere dann nach realer Last.

Damit baust du einen Agenten, der nicht nur beeindruckt, sondern im Alltag zuverlässig funktioniert. Und genau das ist im Produktionsbetrieb entscheidend.