OpenClaw auf dem VPS hosten: Installation, Docker und Gateway-Absicherung

OpenClaw ist ein Open-Source-KI-Assistent, der nicht nur chattet, sondern 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 die OpenClaw-Doku nennt, wie du Telegram, WhatsApp und Discord anbindest und wie du das Gateway absicherst.

1. Was ist OpenClaw?

OpenClaw ist ein Open-Source-KI-Assistent unter MIT-Lizenz, entwickelt von Peter Steinberger und der Community und betreut von der OpenClaw Foundation (laut OpenClaw-Repository, Stand: 08.11.2026).

Der Kernunterschied zu klassischen Chat-Frontends:

• OpenClaw verbindet Sprachmodelle mit Kanälen wie Discord, iMessage, Slack, Teams, Telegram und WhatsApp, dazu mehr als 20 weitere (laut OpenClaw-README, Stand: 08.11.2026). iMessage braucht einen Mac mit Messages; auf einem Linux-VPS geht es nur über einen Mac per SSH (laut OpenClaw-Doku, Stand: 08.11.2026).
• Mit dem eingebauten Scheduler weckt OpenClaw den Agenten zu geplanten Zeiten und kann das Ergebnis in einen Kanal schicken (laut OpenClaw-Doku, Stand: 08.11.2026). Erinnerungen speichert er als Markdown-Dateien im Workspace, ~/.openclaw/workspace (laut OpenClaw-Doku, Stand: 08.11.2026).
• Skills und Plugins findest du in ClawHub, der öffentlichen Registry für OpenClaw. Hochladen kann jeder, prüfe vor der Installation das Scan-Ergebnis auf der Detailseite (laut OpenClaw-Doku, Stand: 08.11.2026).

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?

Ein lokaler Rechner passt, wenn du ihn aktiv nutzt und lokalen Dateizugriff oder einen sichtbaren Browser brauchst. Hattest du Verbindungsabbrüche des Gateways, nennt die OpenClaw-Doku einen VPS als Standard (laut OpenClaw-Doku, Stand: 08.11.2026).

Gerade bei Channel-Agenten ist „immer online“ nicht nur Komfort, sondern funktional wichtig. Ist der Prozess bei Neustarts oder im Schlafmodus weg, laufen geplante Jobs nicht und Kanäle verbinden sich neu.

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 Modelle
4. Nebenprozesse (Queue, Logs, Tools, Browser-Automation)

Orientierung für den Start

Den Bedarf für dein Setup schätzt der KI-Assistent-Rechner (Orientierung von RackDiff).

Image-Build und RAM

Ein Docker-Image aus dem Quellcode zu bauen braucht laut OpenClaw-Doku mindestens 6 GB RAM. Auf kleineren Servern nutzt du das vorgebaute Image ghcr.io/openclaw/openclaw (laut OpenClaw-Doku, Stand: 08.11.2026).

4. Installation

Die OpenClaw-Doku nennt den Installer als Standardweg, dazu npm und Docker. Docker ist optional und isoliert das Gateway in einem Container (laut OpenClaw-Doku, Stand: 08.11.2026).

Option A: Installer oder npm

Der Installer richtet bei Bedarf Node.js ein, installiert OpenClaw und startet das Onboarding (laut OpenClaw-Doku, Stand: 08.11.2026):

# Installer laut OpenClaw-Doku: installiert Node.js bei Bedarf, dann OpenClaw, und startet das Onboarding
curl -fsSL https://openclaw.ai/install.sh | bash

Manuell mit npm brauchst du Node.js 24.16.0+ oder 26.1.0+; Node 22, 23 und 25 werden nicht unterstützt (laut OpenClaw-Doku, Stand: 08.11.2026):

# Node.js 24.x über NodeSource (Befehl laut OpenClaw-Doku)
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node -v   # nötig: 24.16.0+ oder 26.1.0+; aus Sicherheitsgründen nennt die Doku 24.22.1+ bzw. 26.12.1+

# globales npm-Verzeichnis im Home, damit npm ohne sudo installiert
mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"
export PATH="$HOME/.npm-global/bin:$PATH"   # Zeile auch in ~/.bashrc eintragen

npm install -g openclaw@latest --allow-scripts=openclaw   # npm 11.15 und älter: ohne --allow-scripts
openclaw onboard --install-daemon

Prüfen:

openclaw --version
openclaw doctor
openclaw gateway status

Unter Linux richtet das Onboarding einen systemd-User-Service ein, openclaw-gateway.service (laut OpenClaw-Doku, Stand: 08.11.2026).

Option B: Docker

Voraussetzung ist Docker Engine mit Compose v2 über das apt-Repository; das Convenience-Skript ist laut Docker nicht für Produktivsysteme gedacht (laut Docker-Doku, Stand: 08.11.2026). Nutze Docker 28.0.0 oder neuer: In älteren Versionen sind an 127.0.0.1 gebundene Ports aus demselben L2-Segment erreichbar (laut Docker-Doku, Stand: 08.11.2026).

Die Compose-Vorlage veröffentlicht die Ports ohne Host-IP, Docker gibt sie damit auf allen Adressen frei und umgeht ufw (laut OpenClaw-Repository, laut Docker-Doku, laut Docker-Doku, Stand: 08.11.2026). Deshalb bindest du sie vor dem ersten Start an 127.0.0.1.

git clone https://github.com/openclaw/openclaw.git
cd openclaw

Vor dem ersten Start in docker-compose.yml beim Service openclaw-gateway die Ports an Loopback binden (die Vorlage veröffentlicht sie sonst auf allen Adressen):

    ports:
      - "127.0.0.1:${OPENCLAW_GATEWAY_PORT:-18789}:18789"
      - "127.0.0.1:${OPENCLAW_BRIDGE_PORT:-18790}:18790"
      - "127.0.0.1:${OPENCLAW_MSTEAMS_PORT:-3978}:3978"

Danach starten und prüfen (laut OpenClaw-Doku, Stand: 08.11.2026):

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:<version>"   # vorgebautes Image, Version-Tag statt latest
./scripts/docker/setup.sh                                     # erzeugt den Gateway-Token in .env und startet das Gateway
docker compose logs -f --tail=100 openclaw-gateway
curl -fsS http://127.0.0.1:18789/healthz

• CLI-Befehle laufen im Docker-Setup über den Service openclaw-cli (docker compose run --rm openclaw-cli …).
• Die Port-Änderung nach jedem git pull prüfen.
• Den State unter ~/.openclaw legt die Vorlage auf dem Host ab (laut OpenClaw-Doku, Stand: 08.11.2026).

Option C: One-Click Templates

Bietet dein Hoster eine vorkonfigurierte OpenClaw-Vorlage an, prüfe vorher:

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

Kläre diese Fragen mit dem Hoster, bevor du die Vorlage nutzt.

5. Channels verbinden

Telegram

Ablauf laut OpenClaw-Doku (laut OpenClaw-Doku, Stand: 08.11.2026):

1. In Telegram @BotFather öffnen, /newbot senden, den Token speichern.
2. Den Token nicht im Befehl übergeben, sondern in ~/.openclaw/.env (Docker: .env im Repo-Verzeichnis) als TELEGRAM_BOT_TOKEN=… eintragen; das gilt für das Standardkonto, alternativ tokenFile.
3. Gateway neu starten (openclaw gateway restart), Status mit openclaw channels status --probe.
4. Dem Bot schreiben, dann openclaw pairing list telegram und openclaw pairing approve telegram <CODE> (Code gilt eine Stunde).
5. Gruppen: Gruppen-ID unter channels.telegram.groups freigeben; Privacy Mode mit /setprivacy abschalten oder den Bot zum Admin machen, danach den Bot neu hinzufügen.

WhatsApp (Session über QR)

Ablauf laut OpenClaw-Doku (laut OpenClaw-Doku, Stand: 08.11.2026):

1. Die Doku rät zu einer separaten Nummer.
2. openclaw channels login --channel whatsapp aufrufen; Login nur per QR. Auf Remote-Hosts den QR live aufs Handy bringen, Screenshots können ablaufen.
3. Erste DM freigeben: openclaw pairing approve whatsapp <CODE>.
4. Die Zugangsdaten liegen unter ~/.openclaw/credentials/whatsapp/<accountId>/: ins Backup aufnehmen und privat halten.

Discord

Ablauf laut OpenClaw-Doku (laut OpenClaw-Doku, Stand: 08.11.2026):

1. Im Developer Portal „New Application“ anlegen; auf der Seite „Bot“ erzeugt „Reset Token“ den ersten Token.
2. Message Content Intent aktivieren; Server Members Intent rät die Doku an, Presence Intent nur bei Bedarf.
3. OAuth2 URL Generator: Scopes bot und applications.commands; Rechte View Channels, Send Messages, Read Message History, Embed Links, Attach Files.
4. Token als DISCORD_BOT_TOKEN auf dem Host setzen, dem Bot eine DM schicken, openclaw pairing approve discord <CODE>.

Praxis-Tipp: Verbinde die Kanäle einzeln und prüfe jeden mit openclaw channels status --probe (laut OpenClaw-Doku, Stand: 08.11.2026).

6. Sicherheit

Ein Agent mit Kanal- und Tool-Zugriff ist ein potenzieller Angriffsvektor. Die folgenden Punkte stützen sich auf die Sicherheitsseiten der OpenClaw-Doku.

6.1 Gateway nicht öffentlich erreichbar machen

Auf einem normalen Host bindet das Gateway an Loopback (Port 18789); ohne Authentifizierung darf es nie auf 0.0.0.0 laufen (laut OpenClaw-Doku, Stand: 08.11.2026).

Für den Fernzugriff nennt die Doku Tailscale Serve, das Gateway bleibt dabei auf Loopback, und als Rückfallweg einen SSH-Tunnel. Hinter einem Reverse Proxy setzt du gateway.trustedProxies und lässt X-Forwarded-For überschreiben statt anhängen; öffentliche Hosts nur über wss:// (laut OpenClaw-Doku, Stand: 08.11.2026).

SSH-Tunnel Beispiel, danach im Browser http://127.0.0.1:18789/ öffnen:

ssh -N -L 18789:127.0.0.1:18789 user@dein-vps

6.2 Gateway-Authentifizierung

Auth ist standardmäßig aktiv, das Onboarding erzeugt einen Token (gateway.auth.mode: "token"). Ohne Auth (none) nur bei vertrauenswürdigem Loopback (laut OpenClaw-Doku, Stand: 08.11.2026). Die Variable für den Token heißt OPENCLAW_GATEWAY_TOKEN (laut OpenClaw-Doku, Stand: 08.11.2026):

# ~/.openclaw/.env (im Docker-Setup: .env im Repo-Verzeichnis)
OPENCLAW_GATEWAY_TOKEN=<langer-zufälliger-token>

6.3 Firewall

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Für Port 18789 legst du keine öffentliche Regel an (laut OpenClaw-Doku, Stand: 08.11.2026). Ports, die Docker veröffentlicht, umgehen ufw; deshalb bindet Option B sie an 127.0.0.1 (laut Docker-Doku, Stand: 08.11.2026). Mit Tailscale Serve bleibt das Gateway auf Loopback, eine Port-Regel ist dann nicht nötig (laut OpenClaw-Doku, Stand: 08.11.2026).

Optional erlaubt die Cloud-Firewall des Hosters nur TCP 22 aus deinem eigenen Admin-Netz (laut OpenClaw-Doku, Stand: 08.11.2026).

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

Die OpenClaw-Doku behandelt Links, Anhänge und eingefügte Anweisungen standardmäßig als feindlich (laut OpenClaw-Doku, Stand: 08.11.2026).

Gegenmaßnahmen laut OpenClaw-Doku (laut OpenClaw-Doku, Stand: 08.11.2026):

• Riskante Tools (exec, browser, web_fetch, web_search) nur für vertrauenswürdige Agenten oder per Allowlist
• Sensible Tool-Ausführung in einer Sandbox, Secrets außerhalb des erreichbaren Dateisystems
• Nicht vertrauenswürdige Inhalte von einem Reader-Agent ohne Tools zusammenfassen lassen
• Kritische Befehle nur mit Freigabe

6.6 Modellwahl

Für Agenten mit Tool-, Datei- oder Netzwerkzugriff rät die OpenClaw-Doku zu einem Modell der aktuellen Generation aus der oberen Leistungsstufe; kleinere oder ältere Modelle sollen keine Agenten mit Tools betreiben. Die Modellwahl ist nur die erste Schutzschicht (laut OpenClaw-Doku, Stand: 08.11.2026).

6.7 Baseline-Checkliste

Die gehärtete Grundkonfiguration der OpenClaw-Doku umfasst diese Punkte:

• Netzgrenze: Gateway auf Loopback, Zugriff über Tailscale Serve oder SSH-Tunnel (laut OpenClaw-Doku, Stand: 08.11.2026).
• Authentifizierung: Token-Auth mit langem Zufallstoken (laut OpenClaw-Doku, Stand: 08.11.2026).
• Secrets: Provider- und Kanal-Tokens in ~/.openclaw/.env bzw. im Docker-Setup in der von setup.sh erzeugten .env, nicht in versionierten Dateien. Eine .env im Arbeitsverzeichnis ignoriert OpenClaw für Provider-Zugangsdaten (laut OpenClaw-Doku, Stand: 08.11.2026).
• Kanäle: DMs mit dmPolicy: "pairing", Gruppen nur mit Erwähnung (requireMention: true) (laut OpenClaw-Doku, Stand: 08.11.2026).
• Tools: Profil messaging, exec mit security: "deny" und ask: "always", fs.workspaceOnly: true (laut OpenClaw-Doku, Stand: 08.11.2026).
• Prüfung: regelmäßig openclaw security audit (laut OpenClaw-Doku, Stand: 08.11.2026).
• Trennung: ein Gateway je Vertrauensgrenze, möglichst eigene OS-Benutzer (laut OpenClaw-Doku, Stand: 08.11.2026).
• Backups: siehe Abschnitt 8, Backup- und Rollback-Strategie (laut OpenClaw-Doku, Stand: 08.11.2026).

Die Docker-Vorlage startet zwei Services, openclaw-gateway und openclaw-cli; je State-Volume läuft genau ein Gateway (laut OpenClaw-Doku, Stand: 08.11.2026). Reverse Proxy, Log-Versand und Backup-Job ergänzt du bei Bedarf.

Gerade bei Agenten gilt: Betriebssicherheit entsteht nicht durch ein einzelnes Tool, sondern durch mehrere kleine Sicherheitsgrenzen.

7. Kostenfaktoren

Die laufenden Kosten bestehen aus dem VPS-Tarif und der Nutzung deines Modellanbieters. OpenClaw selbst steht unter MIT-Lizenz (laut OpenClaw-Repository, Stand: 08.11.2026). VPS-Preise inkl. USt stehen im VPS-Vergleich, Modellkosten nennt dein Modellanbieter.

Lokale Modelle sparen Aufrufe beim Modellanbieter, brauchen aber mehr RAM und CPU. Laut OpenClaw-Doku braucht OpenClaw großen Kontext; kleinere oder quantisierte Modelle kürzen den Kontext und erhöhen das Prompt-Injection-Risiko (laut OpenClaw-Doku, Stand: 08.11.2026). Mehr dazu in Ollama auf dem VPS.

Laufender Aufwand

• 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.

Preise im Vergleich

Aktuelle Preise inkl. USt findest du im VPS-Vergleich.

8. Troubleshooting

Gateway startet nicht: Lock oder Port belegt

Lock-Dateien nicht von Hand löschen (laut OpenClaw-Doku, Stand: 08.11.2026):

openclaw gateway status --deep
openclaw gateway recover-lock

recover-lock zeigt, welcher Prozess den Lock hält. Nach dem Stoppen dieses Prozesses bestätigst du mit dem ausgegebenen openclaw gateway recover-lock --confirm <fingerprint>.

WhatsApp trennt die Verbindung

Diagnose mit openclaw channels status --probe, openclaw doctor und openclaw logs --follow. Hilft das nicht: Auth-Verzeichnis des Kontos sichern, abmelden, neu anmelden (laut OpenClaw-Doku, Stand: 08.11.2026).

Image-Build bricht ab (Killed, Exit-Code 137)

Ein Build aus dem Quellcode braucht mindestens 6 GB RAM. Nutze einen größeren Server oder das vorgebaute Image (laut OpenClaw-Doku, Stand: 08.11.2026).

Config fehlt nach abgebrochenem Onboarding

openclaw doctor prüft die Konfiguration; danach das Onboarding erneut starten (openclaw onboard). Das State-Verzeichnis ~/.openclaw nicht löschen: Es enthält Zugangsdaten, Kanal-Sitzungen und Memory (laut OpenClaw-Doku, laut OpenClaw-Doku, Stand: 08.11.2026).

Discord: Bot reagiert nicht

Ist der Message Content Intent aktiv? Nach Änderungen an Intents das Gateway neu starten. Diagnose mit openclaw doctor, openclaw channels status --probe und openclaw logs --follow (laut OpenClaw-Doku, Stand: 08.11.2026).

Bonus: Backup- und Rollback-Strategie

Wenn OpenClaw in echte Workflows integriert ist, brauchst du einen klaren Rollback-Pfad (laut OpenClaw-Doku, Stand: 08.11.2026):

1. Vor jedem Update ein Backup anlegen (Befehle unten).
2. Update in Wartungsfenster mit aktivem Log-Tailing.
3. Funktionsprüfung: /healthz, dann je Kanal eine Nachricht.
4. Rollback: openclaw update --tag <version> --dry-run, dann ohne --dry-run. Ein Downgrade macht Konfigurations- und Datenbankmigrationen nicht rückgängig.

Backup bei Installation per Installer oder npm:

mkdir -p ~/Backups/openclaw
openclaw backup create --output ~/Backups/openclaw --verify

Im Docker-Setup trägst du OPENCLAW_IMAGE mit festem Version-Tag dauerhaft in die .env im Repo-Verzeichnis ein; Docker Compose liest diese Datei für ${…}-Platzhalter, eine in der Shell gesetzte Variable hat Vorrang (laut Docker-Doku, Stand: 08.11.2026). Für ein Update änderst du dort den Tag. Vorher sicherst du den State: Gateway stoppen, Snapshot des Verzeichnisses ~/.openclaw bzw. des Volumes anlegen. Das Update laut Doku (laut OpenClaw-Doku, Stand: 08.11.2026):

docker compose pull openclaw-gateway openclaw-cli
docker compose stop openclaw-gateway
docker compose up -d openclaw-gateway

• Nie nur die .sqlite-Datei einer laufenden Datenbank kopieren.
• Backups enthalten Zugangsdaten, deshalb Rechte nur für den Besitzer.

Damit stellst du notfalls 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: Prüfe mit absichtlich manipulierten Eingaben, ob Freigaben und Tool-Grenzen greifen, und führe openclaw security audit aus (laut OpenClaw-Doku, Stand: 08.11.2026).
• 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

Auf einem VPS läuft OpenClaw rund um die Uhr, ohne dass dein Laptop an sein muss; State, Memory und Zugangsdaten liegen auf deinem Server (laut OpenClaw-Repository, Stand: 08.11.2026). Nutzt du einen Cloud-Modellanbieter, verarbeitet dieser die Inhalte, die der Agent an das Modell schickt.

Entscheidend ist neben dem Setup die Sicherheitsarchitektur: kein offenes Gateway, saubere Auth, klare Rechte und Observability von Tag 1.

Für den Start reicht ein kleiner, abgesicherter Server; die OpenClaw-Doku nennt 2 GB RAM und mehr für mehrere Kanäle (laut OpenClaw-Doku, Stand: 08.11.2026). Erst Absicherung, dann Skalierung.

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

Den Ressourcenbedarf schätzt der KI-Assistent-Rechner.