OpenClaw 2026 selbst hosten: Gateway, Channels und Sicherheit

Betrachte OpenClaw als kleines System und nicht als Docker-Image. Das nutzerseitige Ziel für OpenClaw ist klar: ein Gateway für einen KI-Assistenten mit mehr als 22 Channel-Integrationen. Die Bereitstellung ist erst dann akzeptabel, wenn du einen Messaging-Channel koppeln, eine eingehende Nachricht senden, den Absender genehmigen, ein harmloses Tool aufrufen und die Control UI nach einem Neustart des Gateways erneut verbinden kannst.

Diese Unterscheidung macht den Fehler sichtbar, auf den Betreiber nach lokalen Tests stoßen: Das Gateway ist nur an Loopback gebunden oder der Proxy verwirft WebSocket-Upgrades. Außerdem wird der Backup- und Upgrade-Plan konkret genug, um ihn zu testen.

Die kleinstmögliche funktionsfähige OpenClaw-Topologie auswählen

Die kleinste verantwortbare OpenClaw-Topologie besteht aus einem privaten Listener auf Port 18789, einer Ingress-Route und einer dokumentierten State-Grenze. Für OpenClaw werden ein Key des Model-Providers und mindestens ein gekoppelter Channel benötigt. Teste ausgehendes DNS, TLS und das Verhalten des Providers, ohne einen weiteren eingehenden Service zu veröffentlichen.

Validiere die Topologie, indem du einen bereinigten Client bittest, einen Messaging-Channel zu koppeln, eine eingehende Nachricht zu senden, den Absender zu genehmigen, ein harmloses Tool aufzurufen und die Control UI nach einem Neustart des Gateways erneut zu verbinden. Beobachte währenddessen parallele Agent-Interaktionen, die Latenz des Models, Browser-Tool-Prozesse und die Größe der angesammelten Session-Historie. Das Ergebnis zeigt dir, ob die nächste Verbesserung in Memory, Storage, Networking oder in einem separaten Worker erfolgen sollte, anstatt eine beliebige Container-Größe festzulegen.

Ein gesund wirkendes OpenClaw diagnostizieren

Ein im Leerlauf ausgeführter Health Check sagt über OpenClaw nur wenig aus. Beobachte parallele Agent-Interaktionen, die Latenz des Models, Browser-Tool-Prozesse und die Größe der angesammelten Session-Historie. Erstelle dann Alerts für das Symptom, das Nutzer tatsächlich erleben: das Scheitern der Aktion „einen Messaging-Channel koppeln, eine eingehende Nachricht senden, den Absender genehmigen, ein harmloses Tool aufrufen und die Control UI nach einem Neustart des Gateways erneut verbinden“. Halte Liveness lokal und kostengünstig; Readiness sollte Migrationen oder Initialisierung melden, ohne eine Restart-Schleife auszulösen.

Der kritische Bereich bei Upgrades ist, dass ein Release das Konfigurationsschema des Gateways, gebündelte Skills, Browser-Abhängigkeiten oder Channel-Adapter ändern kann. Lies die Release Notes, erstelle einen Snapshot des States, deploye die Zielversion mit einer wiederhergestellten Kopie und wiederhole die Abnahmeaktion. Wenn das Gateway nur an Loopback gebunden ist oder der Proxy WebSocket-Upgrades verwirft, korreliere die Client-Anfrage mit dem ersten relevanten Application Log, anstatt den State blind zu löschen oder Redirects hinzuzufügen.

Fünf Prüfungen, die stärker sind als der Container-Health-Check

Der Release-Eintrag für OpenClaw braucht Fakten und kein „sieht gut aus“. Speichere den ausgewählten Image-Digest, die Konfigurations-Checksumme, den öffentlichen Hostnamen und ein Ergebnis mit Zeitstempel für folgende Aktionen: einen Messaging-Channel koppeln, eine eingehende Nachricht senden, den Absender genehmigen, ein harmloses Tool aufrufen und die Control UI nach einem Neustart des Gateways erneut verbinden. Verwende nicht produktive Beispieldaten, damit die Prüfung nach jedem Deployment ausgeführt werden kann.

Weise zwei Lifecycle-Ereignisse getrennt nach. Ein Austausch des Containers muss den normalen Betrieb aufrechterhalten. Eine saubere Wiederherstellung muss zeigen, dass das wiederhergestellte Gateway seinen Workspace erneut öffnen, den gekoppelten Channel erkennen und die Provider-Authentifizierung ohne erneutes Onboarding verwenden kann. Miss während der Prüfungen parallele Agent-Interaktionen, die Latenz des Models, Browser-Tool-Prozesse und die Größe der angesammelten Session-Historie. Bewahre das Ergebnis als erwarteten Rahmen für diese Version auf.

Teste außerdem eine abgewiesene oder ungültige Bedingung: Verweigere vorübergehend den für einen Key des Model-Providers und mindestens einen gekoppelten Channel verwendeten Testpfad. OpenClaw sollte auf nachvollziehbare Weise fehlschlagen und keinen intakten State überschreiben. Stelle die gültige Bedingung wieder her, führe das Beispiel erneut aus und füge die relevanten redigierten Logs hinzu. Diese Artefakte liefern für eine spätere Rollback-Entscheidung konkrete Belege.

Die erste produktionsnahe Instanz ausführen

Halte den ersten OpenClaw-Aufruf so reproduzierbar, dass du ihn in einem Pull Request prüfen kannst.

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/home/node/.openclaw \
  -e OPENCLAW_GATEWAY_TOKEN=replace-with-a-long-random-value \
  -e OPENCLAW_GATEWAY_BIND=lan \
  ghcr.io/openclaw/openclaw:latest node dist/index.js gateway --bind lan --port 18789

Verlasse dich nicht auf latest, sobald echte Daten vorhanden sind. Halte den funktionierenden Digest, den Container-User und die Ownership des Mounts fest. Verfolge das Application Log durch einen vollständigen Test — einen Messaging-Channel koppeln, eine eingehende Nachricht senden, den Absender genehmigen, ein harmloses Tool aufrufen und die Control UI nach einem Neustart des Gateways erneut verbinden — und notiere alle Migrationen, bevor du die Route hinter produktiven Traffic stellst.

Die Wiederherstellung von OpenClaw messbar machen

Ein Container-Image kann erneut heruntergeladen werden; der OpenClaw-Workspace, der Channel-State und die Konfiguration können das nicht. Binde /home/node/.openclaw vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um nachzuweisen, dass dieser Pfad tatsächlich persistent ist. Prüfe den effektiven Mount, statt einer Compose-Datei zu vertrauen, und kontrolliere, dass der Runtime-User dort schreiben kann, wo OpenClaw es erwartet.

Lege eine Aufbewahrungsdauer und ein Off-Host-Ziel fest und übe die Wiederherstellung, ohne die Produktion anzufassen. Die Übung ist nur dann erfolgreich, wenn das wiederhergestellte Gateway seinen Workspace erneut öffnen, den gekoppelten Channel erkennen und die Provider-Authentifizierung ohne erneutes Onboarding verwenden kann. Bei datenbankgestütztem State kombinierst du Storage-Snapshots mit anwendungskonsistenten Exporten, wie in Point-in-Time-Recovery im Vergleich zu Snapshots beschrieben.

OpenClaw von außerhalb des Servers testen

Behandle die externe OpenClaw-URL als Konfiguration, die Redeployments übersteht. Konfiguriere zuerst die öffentliche Gateway-Adresse und einen Proxy mit WebSocket-Unterstützung. Leite anschließend den Hostnamen auf Port 18789 weiter, wobei der ursprüngliche Host und das ursprüngliche Schema erhalten bleiben.

Mit der Checkliste zur Deployment-Erreichbarkeit kannst du nachweisen, dass Anfragen den Container erreichen. Danach sollte der bekannte Fehler — das Gateway ist nur an Loopback gebunden oder der Proxy verwirft WebSocket-Upgrades — in OpenClaw, seinem State oder seiner Workload untersucht werden und nicht in der Zertifikatsautomatisierung.

Die Berechtigungen von OpenClaw reduzieren

Bootstrap-Credentials sind temporär; das Trust-Modell ist dauerhaft. Achte bei OpenClaw darauf, dass der Gateway-Token nicht fehlt und keine unbekannten Channel-Kopplungen genehmigt werden. Verwende pro Gateway eine Trust Boundary, prüfe jede DM-Kopplung und sandboxe Tools, die auf den Host zugreifen.

Behandle OPENCLAW_GATEWAY_TOKEN entsprechend seiner Rolle in OpenClaw: Halte sensible Werte aus Git heraus, dokumentiere die Auswirkungen einer Rotation und ersetze niemals ein öffentliches Beispiel in der Produktion. Führe das Image ohne unnötige Linux-Capabilities aus und exponiere nur die öffentliche Application-Route. Halte Administratoraktivitäten sichtbar, ohne Secret-Werte aufzuzeichnen.

OpenClaw an den Lifecycle von Dockup anbinden

Die Plattformebene für OpenClaw besteht aus Port 18789, Ingress, TLS, Runtime-Konfiguration, Storage und der Erreichbarkeit von Abhängigkeiten. Dockup kann diese Komponenten für die eigene Infrastruktur oder für einen vom Kunden angebundenen Server reproduzieren.

Anschließend vervollständigt der Betreiber die Produktebene: Konfiguriere die öffentliche Gateway-Adresse und einen Proxy mit WebSocket-Unterstützung; erzwinge diese Zugriffsregel — verwende pro Gateway eine Trust Boundary, prüfe jede DM-Kopplung und sandboxe Tools, die auf den Host zugreifen — und führe „einen Messaging-Channel koppeln, eine eingehende Nachricht senden, den Absender genehmigen, ein harmloses Tool aufrufen und die Control UI nach einem Neustart des Gateways erneut verbinden“ aus. Wenn du diesen Test zusammen mit dem Deployment dokumentierst, verhinderst du, dass automatisiertes Provisioning mit der Application Readiness verwechselt wird.

Häufig gestellte Fragen

Was benötigt OpenClaw für ein produktives Deployment?

Leite den OpenClaw-Container über eine HTTPS-Origin auf Port 18789 weiter. Für die externe Bereitstellung werden ein Key des Model-Providers und mindestens ein gekoppelter Channel benötigt. Erkläre OpenClaw erst dann für bereit, wenn du einen Messaging-Channel koppeln, eine eingehende Nachricht senden, den Absender genehmigen, ein harmloses Tool aufrufen und die Control UI nach einem Neustart des Gateways erneut verbinden kannst.

Welche OpenClaw-Daten gehören in ein Backup?

Persistiere /home/node/.openclaw und nimm den OpenClaw-Workspace, den Channel-State und die Konfiguration in dasselbe Recovery-Manifest auf. Eine saubere OpenClaw-Wiederherstellung ist nur dann erfolgreich, wenn das wiederhergestellte Gateway seinen Workspace erneut öffnen, den gekoppelten Channel erkennen und die Provider-Authentifizierung ohne erneutes Onboarding verwenden kann.

Benötigt OpenClaw hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für die öffentliche OpenClaw-Origin und halte Port 18789 auf der internen Route. Wende die OpenClaw-Einstellung korrekt an: Konfiguriere die öffentliche Gateway-Adresse und einen Proxy mit WebSocket-Unterstützung. Bei OpenClaw schützt HTTPS Credentials oder Nutzerinhalte während der Übertragung und sorgt für ein konsistentes, Origin-sensitives Client-Verhalten.

Wie sollte ein OpenClaw-Upgrade getestet werden?

Stelle den aktuellen OpenClaw-State in einem isolierten Deployment wieder her, wende die Kandidatenversion an und wiederhole die Abnahmetransaktion. Gehe dabei besonders sorgfältig vor, da ein Release das Konfigurationsschema des Gateways, gebündelte Skills, Browser-Abhängigkeiten oder Channel-Adapter ändern kann. Bewahre das bisherige OpenClaw-Image auf, bis die Grenzen der Datenmigration und des Rollbacks geklärt sind.