OpenClaw 2026: Upgrade und Laufzeit-Migration
Konfig-Backups, Gateway-Umschaltung und Rollback-Schritt für Schritt (Docker / lokal)

Ca. 18 Min. Lesezeit · MACCOME

Teams mit laufendem OpenClaw in Produktion fürchten 2026 vor allem drei Dinge: schwebendes latest, Upgrade ohne vollständiges State-Backup, falsche Stop-Reihenfolge des Gateways mit divergierenden Tokens und Volumes. Dies ist keine Greenfield-Installationsanleitung. Sie ergänzt Windows/macOS/Linux-Installation, Docker-Produktion, Post-Install-Triage und Linux systemd + Tunnel mit Schmerzpunkten, einer lokal-vs.-Container-Matrix, Symptom-Rollback-Tabelle, Backup-Snippets, einem Sechs-Schritte-Upgrade-Runbook und drei Bereitschaftszeilen. Für Secrets und Exposition folgen Sie dem fortgeschrittenen Gateway-Runbook.

Umfang: Einordnung in die OpenClaw-Serie

Installationsguide: „Wie installiere ich?“ Docker-Produktion: „Wie bleibe ich online und behebe typische Containerfehler?“ Post-Install: „Startet nicht—Symptom für Symptom.“ Linux+Tunnel: „systemd ohne öffentliche Bindung des Gateways.“ Dieser Text behandelt nur Upgrades, Host-Wechsel, Wechsel der Deploy-Form und Rollback unter der Annahme „läuft bereits“—so dass Change-Tickets unterschrieben werden können. Sechs häufige Schmerzpunkte aus echter Bereitschaft—direkt in die Change-Beschreibung kopieren.

  1. Image- oder Paket-Drift: Produktion folgt latest oder schwebenden Tags; der vorherige Digest ist nicht reproduzierbar.
  2. Nur Repo, kein State: ~/.openclaw (oder dokumentierter Pfad) mit Schlüsseln, Workspace und Gateway-Konfig wird nicht mit den Volumes gesichert.
  3. Falsche Stop-Reihenfolge: Container vor Volume-Export killen oder DNS vor altem Gateway ändern—Doppel-Schreiben und Pairing-State brechen.
  4. Gemischte lokale und Container-Pfade: npm und Compose auf einem Host kämpfen um Ports oder dasselbe Verzeichnis; nach „Migration“ liest der Prozess noch den alten Pfad.
  5. Kaltes Upgrade ohne Validierung: nur Prozess lebt, kein minimaler Modellaufruf und kein Control-UI-Login.
  6. Rollback nur Downgrade: neue Version ändert Schema oder Workspace-Dateien; altes Binary ohne Volume-Restore-Plan.

Tabelle 1: Lokal (npm/Skripte) vs. Docker Compose—Upgrade-Dimensionen

Für Reviews, welcher Pfad pro Release gilt; Feldnamen an Fork/Release Notes anpassen.

DimensionLokaler PfadDocker-Compose-Pfad
Versionsankernpm/pnpm und Lockfile fixieren; Node-Minor notierenImage-Tag oder Digest fixieren; silent latest verbieten
State-Ort~/.openclaw und lokale Workspace-PfadeBind-Mount oder benanntes Volume auf Host-Pfad
Schlüssel und TokensUmgebung, Schlüsselbund oder .env (nicht committen).env, Docker-Secrets oder Orchestrierungsvariablen; vor Upgrade exportieren
HealthCLI / lokale Port-Sondencompose ps, Health im Container, Host-Ports
Rollback-HebelInstallierte Paketversion + Verzeichnis-Tar wiederherstellenImage-Digest zurück + Volume-Snapshot wiederherstellen

Tabelle 2: Symptom → erste Aktion (Rollback- und Bind-Hinweise)

Ergänzt Post-Install-Triage; hier steht die Entscheidungsreihenfolge im Upgrade-Fenster im Vordergrund. Control UI und öffentliche Exposition an das fortgeschrittene Runbook koppeln.

SymptomZuerst vermutenZuerst tunWenn es weiter fehlschlägt
Gateway-Restart-SchleifeBind-Adresse und UI-Allowlist nicht alignedLoopback-Bindung oder allowedOrigins-ähnliche Settings korrigieren, erneut versuchenVorherigen Image-Digest zurücksetzen und Volume-Snapshot wiederherstellen
Pairing / Geräte-Auth merkwürdigZwei Instanzen parallel oder rotierte Tokens ohne Client-UpdateAlte Instanz vollständig stoppen; Geräte per CLI listen und offiziellen Flow folgenToken-Dateien aus Backup zurückspielen und kurz die Version zurücksetzen
Modell-TimeoutEgress, Proxy oder Schlüsselwechselcurl im Container und auf dem Host; minimale Schlüsselrotation testenVendor-Status und Firewall-Policy prüfen
Disk voll, dann Upgrade scheitertWorkspace und Logs ohne RotationVor aggressiver Bereinigung snapshotten; freien Speicher laut Vendor-Empfehlung vor UpgradeDisk erweitern oder Workspace auf separates Volume legen
bash
# Beispiel: State vor Upgrade archivieren (Pfad anpassen; Archive nicht nach git)
tar czf openclaw-state-$(date +%Y%m%d).tgz -C "$HOME" .openclaw

# Compose: Digest oder Minor in .env oder compose fixieren, dann pull & up
# docker compose pull && docker compose up -d
warning

Hinweis: Backups mit Geheimnissen nur für Ops-Rollen zugänglich machen; nach Restore potenziell exponierte Tokens rotieren; Secrets-Audit wie im fortgeschrittenen Runbook beibehalten.

Sechs-Schritte-Upgrade-Runbook (für Change-Systeme)

  1. Release Notes: Breaking Changes, DB/Workspace-Migrationsskripte, Mindest-Node/Kernel.
  2. Anker einfrieren: Image-Digest oder Paketversion notieren; im Fenster kein latest-Herumspielen.
  3. Kaltes Backup: State-Tar, Compose-Volumes oder Bind-Pfade, sichere Kopie von .env (für Audit redigiert).
  4. Cutover im Fenster: Ingress (Reverse Proxy / Tunnel) vor altem Gateway stoppen; neue Instanz health-checken, dann Ingress zurück.
  5. Validieren: CLI-Status, saubere Gateway-Logs, Control-UI-Login, ein minimales Modellgespräch.
  6. Dokumentieren oder zurück: bei Erfolg Runbooks mit Version/Digest aktualisieren; bei Fehler Zweig aus Tabelle 2 und Incident öffnen.

Drei harte Bereitschaftszeilen

  1. Reproduzierbarer Anker: Produktion muss „welcher Digest/Paketstand läuft?“ beantworten—sonst ist das Upgrade nicht abgeschlossen.
  2. Backup-Nachweis: Restore-Drills für Tar oder Volume-Snapshots mindestens vierteljährlich; ohne getesteten Restore kein Backup.
  3. Zeitbudget: Wartungsfenster muss „Validierung fehlgeschlagen + vollständiger Restore“ abdecken, nicht nur den Happy Path.

Laufen Gateway auf Laptop und Server parallel, Instanzen in Monitoring klar labeln—sonst sagt der Alarm nur „down“ und DNS-Cutover wird geraten. Das verlängert Token- und Expositionsvertrag aus dem Docker-Produktionsartikel.

Grenzen von nur Laptop oder kurzfristigem VPS als Dauer-Gateway

Sleep, OS-Updates und unerwarteter Speicher machen Upgrade-Fenster zufällig. Kurz-VPS ohne passende Snapshots und Laufzeit fehlt oft die Platte zum Zurückrollen. Gateway als Produktionskomponente braucht vorhersehbare Online-Zeit, wiederherstellbare Disks und Regionswahl plus an Monitoring gebundenes Runbook.

Fragmentierte Hosts erschweren Secrets-Governance und Audit: wer hat zuletzt welches Token geändert, welcher Host läuft mit Digest X. MACCOME bietet Mac Mini M4 / M4 Pro Bare-Metal in mehreren Regionen mit flexiblen Mietbedingungen—als stabile Ausführungsebene oder dedizierter Gateway-Host für OpenClaw. Gemeinsam mit dem Multi-Region- und Mietlaufzeit-Leitfaden und SSH-vs.-VNC-Leitfaden prüfen; Pakete über Mietpreise abstimmen und Hilfe-Center zu Abrechnung und Zugang konsultieren.

In Pilotphasen kurz in der Zielregion mieten, Backup–Upgrade–Rollback üben, bevor längere Verträge gebunden werden.

FAQ

Welche drei Dinge darf man vor einem Upgrade nicht auslassen?

Image- oder Paket-Anker fixieren, State-Verzeichnis und Volumes vollständig sichern, Rollback-Verantwortliche und Validierungsfälle im Fenster festhalten. Backups mit personenbezogenen Protokollen sollten zweckgebunden und nachvollziehbar aufbewahrt werden; im EU-Raum dokumentieren Sie Verarbeitungszwecke und Löschfristen auch mit Blick auf die DSGVO. Geschäftliche Konditionen: Mietpreise und Hilfe-Center.

Nach einem Gateway-Upgrade spinnt die Control UI—was zuerst prüfen?

Bind-Adresse und Health; unter Docker Loopback und UI-Allowlist-Settings; lokal Ports und Tokens. Symptomweise Vorgehen im Post-Install-Triage-Artikel.

Wie ergänzt sich das zum Docker-Produktionsartikel?

Produktion: Dauerbetrieb und typische Containerfehler; dieser Text: Backup-Reihenfolge, Anker und Rollback rund um Upgrades. Beide neben dem Docker-Produktionsartikel im selben Handbuchverzeichnis.