OpenClaw im Betrieb: Updates, Wartung und ehrliches Fazit – Teil 3 der Hybrid-Architektur-Serie

Recap: Bisher in dieser Serie

Teil 1 hat die Hybrid-Architektur beschrieben: Raspberry Pi 5 als lokale Basis mit Docker-Isolation, ein günstiger VPS als Ollama-Endpunkt für Cloud-Modelle, und die Trennung von lokalen Embeddings und externer Sprachmodell-Inferenz.

Teil 2 widmete sich dem OpenClaw Gateway als Steuerzentrale – der Trennung von Vault und Workspace, dem Skills-System und dem Gateway-eigenen Scheduling.

In diesem abschließenden Teil geht es um die praktische Betriebserfahrung: Wie laufen Updates, wie wird gewartet, was funktioniert gut – und was nicht.

1. Update-Strategie: Kontrolliert und reproduzierbar

1.1 Das Prinzip

OpenClaw wird über Docker-Container ausgeliefert. Ein Update bedeutet: neuen Container pullen, alten Container ersetzen. Da Code und State strikt getrennt sind, gibt es keine Datenmigration – der neue Container liest denselben Workspace, dieselben Secrets, denselben Vault.

Das Update-Skript läuft so ab:

1. Backup des aktuellen States (Workspace, Cron-Jobs, Config)
2. Pull des neuen Images
3. Container-Neustart mit dem neuen Image
4. Post-Check: Ist der Container healthy? Läuft der Heartbeat? Funktionieren die Skills?

In der Praxis gab es genau zwei Problemklassen:

Modell-Timeout nach Default-Modell-Wechsel: Ein Wechsel des Standard-Modells auf ein schwereres Reasoning-Modell führte zu Timeouts in Cron-Jobs, deren Laufzeit das Modell nicht bewältigen konnte. Lösung: Leichtere Modelle für Standard-Operationen, schwere Modelle nur bei Bedarf über explizite Konfiguration.

Pfad-Drift zwischen Dokumentation und Realität: Die Architektur-Dokumentation und die tatsächliche Docker-Mount-Konfiguration wichen voneinander ab – Memory-Pfade waren anders gemountet als beschrieben. Lösung: Regelmäßiger Abgleich von Dokumentation und docker inspect-Ausgabe.

Beide Probleme sind keine OpenClaw-spezifischen Fehler, sondern typische Betriebsrisiken einer wachsenden Eigenbau-Infrastruktur. Die gute Nachricht: Das Backup-Konzept hat in beiden Fällen funktioniert. Ein docker compose down && docker compose up -d mit der vorherigen Konfiguration stellt den alten Zustand innerhalb von Sekunden wieder her.

1.3 Wartungsroutine

Die tägliche Wartung besteht aus:

• Heartbeat-Lauf (automatisiert): Prüft Container-Status und angeschlossene Dienste
• Hardware-Monitoring (automatisiert): Temperatur, Speicher, Speicherplatz des Raspberry Pi

Die wöchentliche Wartung:

• Memory-Cleanup (automatisiert): Alte Caches und Session-Transkripte aufräumen
• Kurzer Blick in Logs auf Auffälligkeiten

Die monatliche Wartung:

• Docker-Image-Updates: docker compose pull für alle Container
• Dokumentationsabgleich: Stimmen die Pfade in der Doku noch mit der Realität überein?
• Backup-Verifikation: Sind die Backup-Dateien lesbar und vollständig?

Mehr ist nicht nötig. Die Architektur ist so ausgelegt, dass sie im Normalbetrieb ohne Eingriff läuft.

2. Ehrliches Fazit nach mehreren Monaten

2.1 Was gut läuft

Stabilität: Der Raspberry Pi 5 läuft seit Monaten ohne Neustart durch. Die durchschnittliche CPU-Last liegt unter 0.5, die Temperatur bei etwa 45–50 °C mit passiver Kühlung. Der OpenClaw-Container ist robust – selbst nach fehlgeschlagenen Updates oder abgebrochenen Cron-Jobs bleibt der Container lauffähig.

Kosten: Der VPS kostet etwa 5 €/Monat. Keine Cloud-KI-Abonnements mehr (die schnell bei 20–30 €/Monat pro Dienst liegen). Die Stromkosten des Raspberry Pi 5 liegen bei etwa 1–2 €/Monat. Gesamtbetriebskosten: rund 7 €/Monat.

Flexibilität: Der Wechsel zwischen Cloud-Modellen und lokalen Modellen ist eine Konfigurationsänderung. Der VPS-Endpunkt ist austauschbar. Die Skills sind erweiterbar. Das System wächst mit den Anforderungen, ohne dass die Grundarchitektur geändert werden muss.

Dokumentationsgetriebener Betrieb: Entscheidungen werden in Vault und Workspace dokumentiert, nicht im Chat-Verlauf vergessen. Jede Änderung ist nachvollziehbar. Das ist ein massiver Vorteil gegenüber Ad-hoc-Konfiguration.

2.2 Was nicht ideal ist

Antwortlatenz: Cloud-Modelle brauchen 2–15 Sekunden für eine Antwort, je nach Modell und Auslastung. Für Echtzeit-Dashboard-Updates reichen leichtere Modelle wie DeepSeek Flash (2–4 Sekunden), während komplexe Analysen mit Nemotron Super tolerierbare 10–15 Sekunden erfordern. Das ist für die meisten Anwendungen akzeptabel (Chat-Assistent, Dokumentenanalyse), aber ungeeignet für interaktive Szenarien unter 1 Sekunde.

Cloud-Abhängigkeit: Trotz Local-First-Ansatz sind leistungsfähige Antworten von der Cloud-Verfügbarkeit abhängig. Fällt der VPS oder die Ollama-Cloud aus, bleibt nur der lokale Notbetrieb mit kleinen Modellen.

Kein Multimedia: OpenClaw ist text- und API-basiert. Bilderkennung, Audio-Verarbeitung oder Video-Analyse sind nicht Teil des Kernsystems. Wer Multimedia-Funktionen braucht, muss externe Dienste anbinden.

Lernkurve: Die dokumentationsgetriebene Arbeitsweise ist nicht intuitiv. Wer schnell eine Lösung braucht und keine Dokumentation schreiben will, wird mit dieser Architektur nicht glücklich. Sie belohnt Disziplin und bestraft Ad-hoc-Hacks.

2.3 Für wen diese Architektur passt – und für wen nicht

Passt für:

• Technisch versierte Selbstbauer mit Linux-Erfahrung
• Datenschutzbewusste Nutzer, die nicht jede Anfrage an eine öffentliche API schicken wollen
• Bastler mit moderatem Budget (5–10 €/Monat Betriebskosten)
• Alle, die KI-Assistenten langfristig betreiben und nicht von einem Anbieter abhängig sein wollen

Passt nicht für:

• Nutzer ohne Docker- und Linux-Erfahrung
• Echtzeit-Anwendungen (unter 1 Sekunde Antwortzeit)
• Multimedia-Workflows mit Bild- oder Audio-Verarbeitung
• Unternehmen mit Compliance-Anforderungen, die Cloud-Modell-Zugriff ausschließen

3. Ausblick: Was als Nächstes kommt

Die Architektur ist kein Endzustand, sondern eine Plattform. Mögliche nächste Schritte:

• Zusätzliche lokale Modelle: Kleinere Quantisierungen neuer Modelle könnten direkt auf dem Raspberry Pi laufen – für Workflows, die keine Cloud-Anbindung erfordern
• Multi-VPS-Betrieb: Mehrere VPS-Endpunkte für Redundanz (nicht primär für Lastverteilung, da die eigentliche Inferenz in der Ollama-Cloud liegt – der VPS ist nur der Zugangspunkt)
• Dashboard: Eine Weboberfläche für den Systemstatus – keine reine Chat-Interaktion mehr
• Plugin-System: Statt manueller Skills-Konfiguration ein Marktplatz für vorgefertigte Erweiterungen

Aber: Jede Erweiterung muss sich an der Frage messen lassen, ob sie die Grundprinzipien nicht verletzt: Container-basiert, dokumentationsgetrieben, state-getrennt, kontrolliert.

Serien-Fazit

Die Hybrid-Architektur aus Raspberry Pi 5, VPS und Cloud-Modellen ist ein Kompromiss – aber ein bewusster, gut begründeter. Sie bietet die meiste Kontrolle für das geringste Budget, ohne auf moderne KI-Fähigkeiten zu verzichten.

Ob sie für dich passt, hängt von deinen Prioritäten ab. Wenn du bereit bist, Zeit in die Einrichtung und Wartung zu investieren und dafür die volle Kontrolle über deine KI-Infrastruktur bekommst – dann ist dieser Weg einen Blick wert.

Wenn du einfach nur einen funktionierenden KI-Assistenten willst und keine Bastelarbeit: Die Cloud-APIs sind bequemer, aber teurer und weniger kontrollierbar.

Beide Wege sind legitim. Wichtig ist nur, die Entscheidung bewusst zu treffen – und zu wissen, was man dafür bekommt und was nicht.

Diese Serie erschien auf alleswasbewegt.de – Technik für Selbstbauer, die mehr wissen wollen.