openclaw update · fixierte Backups · doctor · Rollback
Teams, die OpenClaw bereits produktiv betreiben, kämpfen selten mit der Frage, ob openclaw update lauffähig ist; die Schmerzen kommen nach der Rückkehr des Kommandos, wenn das Gateway nicht startet, ein alter Prozess den Listener hält, PATH auf ein veraltetes Binary zeigt oder eine Konfigurationsmigration Tool-Einstellungen still überschreibt. Dieser Artikel entfaltet fünf wiederkehrende Upgrade-Risiken, liefert eine Matrix aus offiziellem Update, globalem npm und Quellbuild, ein sechsstufiges Runbook mit Backup- und Kanalrichtlinie, Reihenfolge von doctor und Health nach dem Upgrade sowie eine Beweistabelle zu Portkonflikten und Doppelinstallationen. Querverweise führen zu Multi-Plattform-Installation und Daemons, Installation und Doctor-Triage und Laufzeitfehleranalyse, damit Upgrade, Observability und Rollback auf einer Seite bleiben.
Offizielle Hinweise empfehlen openclaw update gefolgt von openclaw doctor, doch Produktionsstacks bringen Daemons, die nicht dem Paketmanager folgen, alte Gateway-Prozesse, die Listener nicht freigeben, und mehrere CLI-Installationen auf einem Host mit. Wer die Produktionshärtungs-Checkliste kennt, weiß: Kanal-Allowlists und Reduktion der Listenflächen hängen eng mit der Upgrade-Reihenfolge zusammen; ohne sauberes Gateway-Stop vor dem Paketwechsel bleibt 18789 oft an einer veralteten PID gebunden.
Wer Upgrades als isolierte CLI-Ereignisse behandelt, verliert den roten Faden zwischen Versionsnummern, Listenflächen und Identitätsmaterial. Nachhaltige Programme dokumentieren deshalb zuerst die Fehlerbilder: Prozessdrift, stille Konfigurationsmigration, Kollisionen im Kanal-Takt, schwache Rollback-Belege und lückenhafte Health-Telemetrie. Jedes Element unten lässt sich als Artefakt an ein Change-Ticket hängen und hebt Sie von „wir haben update ausgeführt“ zu „wir können jedes Versagen mit Versionsstring und Backup-Pfad erklären“.
Prozess- und Paketversionsdrift: Globales npm zeigt bereits einen neuen Build, aber launchd oder systemd startet noch ein Binary aus einem alten Arbeitsverzeichnis, daher widersprechen sich openclaw --version und gateway status.
Konfigurationsmigration und stille Überschreibungen: Major-Releases können Semantik in openclaw.json ändern; doctor migriert, doch weichen Merge-Regeln vom GitOps-Review ab, entsteht „Datei auf der Platte geändert ohne passenden Pull Request“.
Automatischer Kanal-Takt versus Änderungsfenster: Verzögerung und Jitter im Stable-Kanal verhindern gleichzeitige Massenausfälle, doch ohne Abgleich mit Business-Releases drohen freitägliche Neustarts; mit Kanalprobes zuerst prüfen, ob das Gateway wirklich neu gestartet ist, bevor Callbacks vertraut werden.
Unzureichende Rollback-Belege: Ohne Backups oder fixierte Versionen bleibt nur „erneut latest installieren“ statt Rückkehr zu einem bekannt guten Zustand; zusammen mit dauerhaften Cloud-Deployments laufen auf Knoten oft Cron-Jobs und externe Webhooks, daher verstärkt falsche Rollback-Reihenfolge Ausfallzeiten.
Fehlende Observability-Felder: Ein Screenshot „Upgrade erfolgreich“ ohne Archiv von gateway status --deep und Bind-Adressen erlaubt später keinen Nachweis, dass die Expositionsfläche der Sicherheitsbaseline entsprach.
Machen Sie aus den fünf Punkten eine Preflight-Checkliste, bevor Sie im nächsten Abschnitt Installationspfade vergleichen; so wird aus „wir können updaten“ ein „wir können ein Update prüfen und zurückrollen“. Schlaf- und OS-Wartungsfenster auf Privat-Laptops verschieben Daemon-Zustände kurzzeitig, während Cloud-Mac-Knoten mit vertraglichen SLAs Upgrade-Fenster und Verfügbarkeit in Abnahmekriterien schreibbar machen.
Betriebsverantwortliche sollten zudem festhalten, welche Rolle jeder Host hat: Entwickler-Laptop, geteilter Build-Agent oder dediziertes Gateway. Dieselbe CLI-Version verhält sich anders, wenn launchd ein plist mit altem WorkingDirectory lädt, gegenüber systemd in einem gepinnten Container-Image. Rollen im Ticket zu benennen, verhindert, dass „läuft bei mir“ zu „rätselhafter Produktionsdrift nach Patch-Dienstag“ wird.
Keiner der drei Wege ist pauschal optimal; Passung hängt von Teamgröße, ob Commits für Audits gepinnt werden und ob automatische Gateway-Neustarts akzeptabel sind. Der offizielle update-Unterbefehl passt den meisten Teams; globale Paketmanager passen zu CI-Images; Quellbuilds passen zu Gruppen mit Patches oder fixiertem Dev-Kanal.
Dokumentieren Sie die Matrix unten im Betriebshandbuch, verschwindet auch unklare Verantwortung: Build-Engineering weiß, wann Images neu gebaut werden, Plattform-Engineering, wann systemd-Units anzufassen sind, Anwendungsteams, wann doctor-Ausgaben für Compliance archiviert werden müssen. Diese Klarheit zahlt sich beim ersten Release aus, das ein breaking Feld in openclaw.json einführt und Sie nachweisen müssen, welche Umgebung welche Migration angewendet hat.
| Dimension | openclaw update | Global npm / brew | Git-Quellbuild |
|---|---|---|---|
| Einarbeitung | Niedrig; ein Kommando verketten Fetch, doctor und Neustarthinweise | Mittel; doctor und Gateway-Neustarts selbst verdrahten | Hoch; pnpm-Builds und PATH-Hygiene |
| Nachvollziehbare Versionen | Mittel; setzt Release-Metadaten voraus | Stark; Paket-Semver pinnen | Stark; Commit-SHA pinnen |
| Rollback-Pfad | Mittel; fixierte Releases plus Backups nötig | Stark; npm i -g openclaw@x | Stark; git checkout dann neu bauen |
| Automatisierung | Stark; passt zu Runbooks | Stark; passt zu Image-Layern | Schwach; lange Builds und Cache-Komplexität |
| Wechselwirkung mit Daemons | Explizite Stop-dann-Start-Reihenfolge nötig | Gleich | Höchstes Risiko für Doppelpfad-Installationen |
Nachhaltige Updates hängen davon ab, ob ein Fehler mit Versionsnummer und Backup-Pfad erklärbar ist, nicht ob das Gateway gelegentlich startet.
Wer bereits Installations-Daemon-Anleitung befolgt, sollte die Schlussfolgerungen hier ins Handbuch übernehmen, um das Dreieck „Doku sagt brew, Host nutzt npm, cron zeigt auf einen dritten Pfad“ zu vermeiden.
Die folgenden sechs Schritte sind so formuliert, dass ein On-Call-Playbook Zeile für Zeile abgehakt werden kann: unabhängig vom Installationsstil ermöglicht einheitliche Reihenfolge einem neuen Kollegen die Übung in unter einer Stunde. Zusammen mit der dreiteiligen Laufzeittrennung sollten Sie nach dem Upgrade ein Fragment von gateway status aufbewahren, damit Kanalprobleme von Modellproblemen getrennt bleiben.
Bevor Sie das Fenster einfrieren, informieren Sie nachgelagerte Verantwortliche, die von ausgehenden Webhooks oder gemeinsamen API-Schlüsseln abhängen; Schlüsselrotation in derselben Nacht wie ein Gateway-Upgrade vervielfacht die Schadensbreite. Nutzen Sie externe Secret-Stores, prüfen Sie deren Erreichbarkeit vor Gateway-Stopp, sonst starten Sie halb konfiguriert: doctor grün, Laufzeitaufrufe dennoch fehlgeschlagen.
Änderungsfenster einfrieren: Ziel-Semver und akzeptable Ausfallminuten im Ticket festhalten; nicht zusammen mit großer Modellschlüsselrotation am selben Abend.
Konfigurations- und Identitätspfade sichern: Offizielles Backup-Kommando nutzen oder mindestens Verzeichnisse unter ~/.openclaw mit Konfiguration und Identität archivieren; Prüfsummen des Archivs verifizieren.
Gateway sauber stoppen: openclaw gateway stop ausführen, Listener frei prüfen, dann Updater; halb upgegradete Zustände vermeiden, die Ports blockieren.
Update anwenden und Kanal protokollieren: Bei openclaw update gemeldete Version und Kanal-Metadaten in die Indexfelder des Tickets einfügen.
doctor und health der Reihe nach: Migrationshinweise und Warnungen erfassen; bei unerwarteten Feldänderungen automatische Neustarts anhalten und manuellen Diff prüfen.
Kanäle mit Minimalnachricht prüfen: In erlaubter Umgebung eine Probe senden oder channels status ausführen, damit Callbacks weiterhin Ihren Stack erreichen.
openclaw gateway stop openclaw update openclaw doctor openclaw gateway start openclaw health openclaw gateway status --deep
Hinweis: Wenn der eingebaute Neustart in update gegen Ihre Skripte rennt, können kurz doppelte Listener sichtbar sein; sequenzieren Sie Stop-Install-Start statt Parallelität.
Community-Fäden nennen oft „Port nach Upgrade noch belegt“ oder „CLI zeigt neue Version, Prozess ist alter Build“. Triage sollte sich auf eine einzige Wahrheitsquelle für Bind-Adressen, Binärpfade und Paketorte konzentrieren, bevor die Konfiguration beschuldigt wird. Neben Installations- und Doctor-Checkliste die folgende Liste als Ticket-Anhang einfügen.
Ausgabe von lsof oder Plattform-Äquivalenten zusammen mit which openclaw dokumentieren gibt Reviewern genug Signal für Zombie-Prozess versus falsch verknüpfte Service-Unit. Auf geteilten Hosts auch die effektive Benutzer-ID des Gateway-Prozesses erfassen, denn Profilskripte eines Kontos gelten nicht für ein anderes.
Port belegt: Beleg durch lsof -i :18789 oder Äquivalent mit alter PID; zuerst gateway stop, nur bei Fehlschlag kontrolliert beenden und erneut auf Rest prüfen.
Doppelpfad-Installationen: Beleg wenn which openclaw und npm root -g Präfixe widersprechen; PATH normalisieren, redundante Globals entfernen oder Aliase fixieren.
Daemon-Unit nicht erneuert: Beleg wenn plist oder Unit noch altes WorkingDirectory referenziert; Daemon neu installieren oder dokumentierte Force-Install-Schritte vor kickstart.
Konfigurationsvalidierung scheitert: Beleg wenn doctor Migrationskonflikte meldet; aus Backup wiederherstellen, gestuft upgraden oder JSON manuell mergen und doctor erneut.
Health trügt grün: Beleg wenn health grün, Kanäle aber nicht zurückrufen; Laufzeit-Triage-Artikel befolgen, Vorfall nicht vorzeitig schließen.
Nach Rollback weiter defekt: Beleg dass Umgebungsvariablen oder Shell-Startskripte noch altes NODE_PATH injizieren; Login-Sessions und CI-Image-Layer bereinigen.
Achtung: Auf geteilten Knoten werden temporäre export-Pfade im Profil eines Kollegen schnell flottenweit; für Pools separate Unix-Benutzer oder Containergrenzen nutzen.
Die drei folgenden Punkte fassen ein, was viele kleine Teams beim OpenClaw-Rollout beobachten; nutzen Sie sie zur Projektvorbereitung, nicht als Hersteller garantiert, und ersetzen Sie sie durch Messwerte aus eigenen Tickets.
Schwellen funktionieren am besten mit klaren Verantwortlichen: jemand beobachtet die Probe-Dashboards im Fenster, jemand genehmigt Ausweitung der Ausfallzeit über P95 hinaus, jemand hält Backup-Retention mit Compliance abgestimmt. Ohne Namen bleiben die Zahlen Dekoration.
| Teamgröße | Änderungstakt | Risikobereitschaft | Stabilere Standardwahl |
|---|---|---|---|
| Solo | Ad hoc | Hoch | Offizielles Update plus manuelles Stop/Start; Zip-Backup behalten |
| Kleines Team | Wöchentlich | Mittel | Gepinntes npm-Semver, Change-Tickets, archivierte doctor-Ausgabe |
| Plattform | Täglich | Niedrig | Image-Builds, Canary-Knoten, automatisierte Probes |
| Outsourcing | Unregelmäßig | Mittel | Nur-Lese-Runbooks und dedizierte Knoten; kein gemeinsames HOME |
Schlafmodus, Speicherplatz und OS-Patches auf Privathardware unterbrechen Daemons ständig; selbst perfekte CLI-Disziplin erzeugt auf einem Laptop kein prüfbares Upgrade-SLA. Vertraglich buchbare Cloud-Mac-Mini-Knoten erlauben dagegen, Prozess-Uptime, Ingress und Wartungsfenster in den Vertrag zu schreiben.
Häufiger Fehler: Ein bestandenes health als Beweis für gesunde Kanäle und Modelle—Health deckt nur eine Teilmenge; volle Abnahme folgt weiter der Laufzeit-Triage-Reihenfolge.
Wer rollback-freundliche OpenClaw-Upgrades mit beobachtbarer Gateway-Lebensdauer braucht und Knoten online halten will, ohne dass Laptop-Schlaf Agenten bricht—besonders bei Produktionsautomatisierung und iOS-bezogenen Build-Umgebungen—findet in VpsMesh Mac-Mini-Cloudmiete oft die bessere Lösung: planbare Abrechnung, wählbare Regionen, dedizierte Hardware prüfbar, damit Upgrade-Diskussionen auf echten Verfügbarkeitsdaten basieren.
Sehr empfehlenswert; sichern Sie mindestens Konfigurations- und identitätsrelevante Pfade vor update. Lesen Sie parallel Installation und Doctor-Triage. Zum Bestellen eines Knotens die Bestellseite.
Rollback-Übungen, On-Call-Aufwand und Pflege der Probe-Skripte in die Kosten jedes Releases einrechnen, dann mit der Preisgestaltung und dem Drei-Jahres-TCO-Artikel abgleichen.
Zuerst das Hilfecenter; wenn nach dem Upgrade nur Kanäle stören, zuerst Laufzeitfehleranalyse, dann hier Ports und PATH erneut prüfen.