2026 OpenClaw Gateway in Produktion auf Linux: openclaw onboard, openclaw doctor und --fix, HTTPS mit Nginx oder Caddy, Upgrade und Rollback

OpenClaw als öffentlich erreichbares Gateway auf einem kleinen Linux-VPS zu betreiben, hat weniger mit dem Kopieren einer einzelnen Konfigurationsdatei zu tun als mit langweiliger Zuverlässigkeit: vorhersehbare Ports, eine klare Quelle für Auth-Tokens, TLS-Terminierung, die Sie rotieren können, und ein Rollback-Pfad, wenn die CLI schneller weiterentwickelt wird als Ihr Runbook. Ergänzend helfen 2026 OpenClaw Linux-Cloud-VPS in der Praxis: curl-Installation vs. Docker, Umgebungschecks und FAQ zu typischen Fehlern beim Installationslayout; den Kontrast zu macOS-Hintergrunddiensten fassen wir in OpenClaw 2026 auf dem Cloud-Mac: Umgebungschecks statt Linux-Reflexe, launchd im Hintergrund, FAQ zur reproduzierbaren Fehlersuche zusammen.

Worauf es bei openclaw onboard wirklich ankommt

Der Onboarding-Assistent ist der schnellste Weg zu einer konsistenten openclaw.json, einem nachvollziehbaren Workspace-Pfad und einer nachvollziehbaren Gateway-Auth — besonders unter Linux, wo PATH, Node-Version und Systemd-Units je nach Image variieren. Behandeln Sie den Wizard als Vertrag mit Ihrem zukünftigen Ich: Bind-Adressen bewusst wählen (Loopback, LAN oder Tailnet), den Token-Flow dokumentieren (Datei versus Umgebungs-SecretRef) und vorab entscheiden, ob der Service-Installer Neustarts übernehmen soll. Für Cloud-init gibt es nicht-interaktive Flags, aber der erste Produktionslauf sollte interaktiv sein, damit ein Mensch Ports, Auth-Modus und Kanalumfang bestätigt.

Die offizielle CLI benennt openclaw onboard für die geführte Einrichtung und openclaw setup, wenn Sie Initialisierung plus optionale Onboarding-Parameter wollen — protokollieren Sie die Ausgabe von openclaw config file und den UNIX-Benutzer, damit Wiederherstellungsskripte nie ins falsche Home-Verzeichnis schreiben.

openclaw doctor und der Alias --fix (Reparaturen leben hier)

Upstream bündelt Reparaturen unter openclaw doctor: --repair oder den Alias --fix wendet automatische Korrekturen an, --non-interactive eignet sich für Automation mit nur sicheren Migrationen, --deep, wenn Sie doppelte Gateway-Installationen aus älteren Experimenten vermuten. Wenn Clients plötzlich „unauthorized“ melden, obwohl sich in Git nichts geändert hat, vergleichen Sie On-Disk-Konfiguration mit Umgebungs-Overrides — veraltete Shell-Exports sind ein klassischer Irrweg. Wenn Kanäle krank wirken, der Gateway-Prozess aber läuft, starten Sie mit openclaw channels status --probe und folgen Sie den Hinweisen zurück zum Doctor, statt halb den Baum von Hand zu editieren.

Reproduzierbare Schritte auf einem Linux-Cloud-Host (kurz und pragmatisch)

Provisionieren Sie Ubuntu 22.04/24.04 LTS oder Debian 12, legen Sie einen dedizierten UNIX-Benutzer an, installieren Sie die OpenClaw-Distribution, die Ihr Team standardisiert hat, und führen Sie das Onboarding einmal von einer echten TTY- oder SSH-Sitzung mit bekannter Locale und UTF-8 aus. Öffnen Sie in der Security Group nur das Nötige: 22/tcp von Admin-IP-Adressen, 80 und 443/tcp von überall, wenn Sie TLS auf diesem Host terminieren, und nichts direkt auf den Gateway-Port von 0.0.0.0/0. Unbeaufsichtigte Kernel-Sicherheitsupdates aktivieren, OpenClaw-Upgrades aber an Wartungsfenster koppeln, weil Feature-Flags zwischen Minor-Releases schnell wechseln.

# Installationspfad an Paket oder Tarball anpassen
openclaw --version
openclaw config validate
openclaw gateway status
openclaw health

Nginx oder Caddy als HTTPS-Reverse-Proxy (TLS am Edge, Weiterleitung zum Loopback)

Lassen Sie das Gateway auf 127.0.0.1 nur HTTP sprechen und verschieben Sie Zertifikate, HTTP/2, Rate-Limits und Zugriffsprotokolle an den Edge-Proxy — so bleibt ACME-Erneuerung übersichtlich und Node muss nicht direkt exponiert werden. Zertifikate mit Ihrem bevorzugten ACME-Client ausstellen, dann auf den Loopback-Listener proxien, den Ihr Onboarding-Lauf gesetzt hat (den Live-Port mit openclaw gateway status prüfen statt eines veralteten Snippets zu vertrauen). WebSocket-Upgrade-Header beibehalten, wenn Control-UI oder Streaming-Clients sie brauchen, eine konservative Upload-Obergrenze setzen, damit große Anhänge den Worker nicht blockieren, und in Caddy dieselbe Loopback-Zieladresse mit einem kurzen reverse_proxy-Site-Block spiegeln, falls Caddy Ihr Edge ist.

server {
  listen 443 ssl http2;
  server_name claw.example.com;
  # ssl_certificate ...; ssl_certificate_key ...;

  location / {
    proxy_pass http://127.0.0.1:<gateway-port>;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Upgrade und Rollback ohne Theater

Vor openclaw update oder Paket-Sprüngen openclaw backup create --verify ausführen (oder ~/.openclaw plus Workspace per Orchestrierung snapshotten) und die aktive openclaw.json in ein privates Ops-Repo exportieren. Upgrades in einem Fenster einplanen, in dem kurze Disconnects tolerierbar sind, danach einmal openclaw doctor --repair laufen lassen, um migrierte Felder zu normalisieren. Rollback heißt: Tarball oder Snapshot zurückspielen, vorherige CLI-Build-Version reinstallieren, Unit neu starten — wenn Rollback länger als zehn Minuten dauert, ist Ihr Backup-Umfang zu eng.

FAQ unter „Gateway am Edge“

Brauche ich einen separaten openclaw fix-Befehl? Reparaturen laufen über openclaw doctor --repair (Alias --fix); in dem Upstream-Stand, den wir verfolgen, gibt es kein eigenständiges openclaw fix.

Warum funktionieren Browser, Automation aber nicht? Token-SecretRefs, Uhrzeit-Drift und ob der Proxy Authorization-Header entfernt — curl gegen Loopback und durch TLS vergleichen.

Kann ich HTTPS weglassen? Nur in vertrauenswürdigen Tailnets oder Lab-VLANs; alles, was aus dem öffentlichen Internet erreichbar ist, sollte TLS terminieren und am Proxy protokolliert werden.