Wie oft sollten wir updaten?

CVE-Fixes: sofort. Sonstige Updates: wöchentlich nach Staging-Test. Keine Updates über 2 Wochen liegen lassen — sonst staut sich Update-Schuld auf.

Können wir Updates skippen?

Ja, aber bei größeren Sprüngen (>4 Versions-Dropouts) gibt es manchmal Schema-Migrations, die schmerzhaft werden. Lieber regelmäßig.

Wer pflegt das langfristig?

Wenn euer IT-Team das selbst macht: gut. Sonst empfehlen wir unsere Wartung — wir reviewen jeden Release.

Ratgeber

OpenClaw Update-Management

OpenClaw releast wöchentlich (calver). Manche Updates bringen Features, andere fixen CVEs, manche brechen alte Configs. Hier die Strategie.

Manuel Streit

/ 11. Mai 2026 / 3 min Lesezeit

Über diesen Artikel

OpenClaw Update-Management: Wie man calver-Releases reviewed, in Staging testet, ohne Produktion zu brechen.

calver verstehen

calver = Calendar Versioning. Format: 2026.5.9-beta.1 = Jahr.Monat.Tag.beta-iteration. Multiple Releases pro Woche. Keine Major/Minor-Differenzierung wie bei semver — du musst jeden Release einordnen.

Release-Notes lesen

GitHub Releases auf github.com/openclaw/openclaw/releases. Pro Release: was geändert? Bugfix, Feature, Breaking-Change, CVE-Fix? Markiere CVE-Fixes als sofort installieren.

Staging-Setup

Eine zweite OpenClaw-Instanz für Tests, am besten auf einer separaten Maschine oder Tailscale-isoliert. Updates werden zuerst dort eingespielt, eine Woche lang beobachtet, dann auf Production.

Skill-Regression-Tests

Pro Skill ein Test-Set (siehe Skills erstellen). Bei jedem Update: openclaw skill test --all. Bei Failure: Skill anpassen oder Update zurückrollen.

Rollback-Strategie

Per npm install -g openclaw@<previous-version> kannst du downgraden. Config bleibt kompatibel meist. Skills und Logs sind unaffected. Plus: täglicher Backup von ~/.openclaw/.