Inhaltsverzeichnis
Als ich OpenClaw auf meinem Raspberry Pi 5 eingerichtet habe, stand eine grundlegende Entscheidung an: direkte Installation auf dem Host oder Betrieb in Containern. Ich habe mich bewusst für Docker entschieden, weil diese Entscheidung maßgeblich über Stabilität, Wartbarkeit und Betriebssicherheit des gesamten Systems entscheidet.
Mein Raspberry Pi 5 mit NVMe-SSD war bereit. Anstatt OpenClaw direkt zu installieren, definierte ich zuerst die Architektur – eine Entscheidung, die ich aufgrund früherer Erfahrungen traf.
Mit Docker bleibt das System sauber getrennt: Anwendung, Abhängigkeiten und Laufzeitumgebung sind isoliert, während der Host stabil bleibt. Diese Trennung ist entscheidend für den dauerhaften Betrieb. In diesem Artikel zeige ich, warum dieser Ansatz langfristig der deutlich robustere ist.
Was ist OpenClaw eigentlich? – Kurze Einordnung
Bevor es in die technischen Details geht, eine kurze Einordnung: OpenClaw ist kein weiteres KI-Modell wie ChatGPT oder Claude. Es ist etwas anderes – eine Plattform, die KI-Workflows steuert und automatisiert.
Stell es dir wie einen Dirigenten vor: OpenClaw selbst erzeugt keine Musik, sondern koordiniert die Musiker. Im konkreten Fall verbindet es verschiedene KI-Modelle (lokale wie externe), integriert Dienste wie Telegram, Signal oder WordPress und führt Aufgaben aus, die über einfache Chat-Antworten hinausgehen.
Der entscheidende Unterschied zu klassischen KI-Diensten: OpenClaw arbeitet dauerhaft im Hintergrund. Es wartet nicht auf deine nächste Frage, sondern kann aktiv werden – etwa wenn neue Dokumente in Paperless-ngx eintreffen, wenn Blog-Drafts erstellt werden sollen oder wenn Systemzustände überwacht werden müssen. Genau diese Fähigkeit zur Automatisierung macht die Container-Architektur so wichtig. Ein solches System läuft nicht mal eben nebenbei, es braucht eine stabile, wartbare Basis.
Docker vs. Host-Installation – der direkte Vergleich mit Praxis-Ankern
Die Entscheidung für Docker ist nicht theoretisch motiviert. Sie kommt aus konkreter Erfahrung mit Problemen, die bei direkten Installationen auf Raspberry Pi OS regelmäßig auftreten.
Nachteile der direkten Installation
Bei einer Installation direkt auf dem Host greifen alle Komponenten ineinander. Python-Pakete, Node-Module, Systembibliotheken – alles teilt sich dieselbe Umgebung. Das funktioniert solange, bis das erste Update kommt oder eine neue Komponente hinzugefügt wird.
Ein konkretes Beispiel: Raspberry Pi OS mit Python 3.13 blockiert pip-Installationen mit der Meldung „externally-managed-environment“. Das ist kein Bug, sondern ein bewusstes Debian-Konzept, das das System vor Konflikten zwischen Debian-Paketen und manuell installierten Python-Modulen schützt. Genau solche Probleme treten real auf – nicht nur in der Theorie, sondern im produktiven Betrieb.
Dazu kommen Abhängigkeitskonflikte bei KI-Frameworks. TensorFlow, PyTorch und andere Bibliotheken haben spezifische Anforderungen an Python-Versionen und Systembibliotheken. Auf ARM-Architektur wie dem Raspberry Pi kommt erschwerend hinzu, dass viele vorkompilierte Pakete nur für x64 verfügbar sind. Das führt zu langen Kompilierzeiten oder inkompatiblen Installationen.
Genau an dieser Stelle wird es in der Praxis kritisch. Wenn du OpenClaw direkt auf dem Host installiert hast, betrifft jedes Update der Abhängigkeiten das gesamte System. Ein fehlgeschlagenes Update kann Stunden an Neuinstallation bedeuten. Die Fehlersuche wird komplex, weil nicht klar ist, welche Komponente das Problem verursacht.
Vorteile der Container-Lösung
Mit Docker bleibt jede Komponente in ihrer eigenen Umgebung. Das OpenClaw-Gateway läuft isoliert, mit genau den Abhängigkeiten, die es braucht. Der Host bleibt unberührt.
Reproduzierbare Zustände sind ein weiterer Vorteil. Die Container-Konfiguration ist im docker-compose.yml dokumentiert. Jederzeit nachvollziehbar, jederzeit wiederherstellbar. Wenn etwas schiefgeht, können Container neu gebaut und gestartet werden – ohne das Host-System zu beeinflussen.
Backups werden einfacher: Statt das gesamte System zu sichern, reicht es, den State-Bereich zu speichern. Der Container selbst ist jederzeit reproduzierbar, die Daten bleiben über Bind-Mounts erhalten. Diese Trennung macht das System langfristig wartbar.
Performance im Praxis-Check
Eine berechtigte Frage bei Containerisierung auf einem Raspberry Pi: Was kostet das an Leistung? Ist Docker Overhead, den sich ein Pi 5 nicht leisten kann? Die Antwort hat eine interessante Nuance.
Docker-Overhead auf dem Pi 5
Im praktischen Betrieb in meinem Setup ist kein relevanter Performance-Unterschied zwischen Docker und nativer Installation feststellbar. Die CPU-Auslastung bleibt im erwartbaren Rahmen, der RAM-Verbrauch steigt minimal – vernachlässigbar für die Vorteile, die Docker bietet.
Das liegt daran, wie Docker arbeitet: Container teilen sich den Kernel des Host-Systems und werden über Linux-Mechanismen wie Namespaces und Cgroups isoliert. Es gibt keine vollständige Virtualisierung wie bei einer VM. Für die meisten Workloads, einschließlich KI-gesteuerter Automatisierungen, ist dieser Overhead praktisch nicht spürbar.
Der NVMe-Unterschied
Hier kommt die entscheidende Erkenntnis: Der eigentliche Gamechanger ist nicht die Frage „Docker oder nicht“, sondern „SD-Karte oder NVMe-SSD“.
Die NVMe-SSD am Raspberry Pi 5 macht den spürbaren Unterschied bei I/O-intensiven Workloads. Docker-Container profitieren davon genauso wie native Installationen. Wenn du also vor der Wahl stehst, wo du investierst: NVMe-SSD priorisieren, Docker kommt praktisch ohne spürbaren Aufpreis dazu.
In meinem Setup mit NVMe-SSD läuft OpenClaw seit Wochen stabil, auch Updates und Neustarts verliefen problemlos. Startzeiten sind kurz, Reaktionen flink, und auch unter Last bleibt das System responsiv. Die Kombination aus Pi 5, NVMe und Docker ist für mich die Sweet-Spot-Konfiguration für einen produktiven Betrieb.
So ist mein Setup aufgebaut
Nach der Entscheidung für Docker stellt sich die Frage: Wie sieht eine saubere Struktur aus, die langfristig wartbar bleibt? Der Schlüssel liegt in einer konsequenten Trennung.
Die Verzeichnisstruktur – Code und State konsequent trennen
Die wichtigste architektonische Entscheidung: Code und State werden strikt getrennt. Diese Trennung ist fundamental für ein wartbares System.
Code umfasst alle Komponenten, die aus dem Repository oder den Container-Definitionen jederzeit neu erzeugt werden können. Das OpenClaw-Gateway, die Container-Images, die Basis-Konfigurationen – all das ist überwiegend reproduzierbar.
State umfasst alle systemindividuellen und persistenten Daten, die nicht verloren gehen dürfen. Dazu gehören laufend geänderte Konfigurationen, Skills, Logs, gespeicherte Daten und Datenbankinhalte.
In der Praxis wird diese Trennung über Docker Bind-Mounts bzw. Volumes umgesetzt. Der Container greift auf den State auf dem Host zu, während der Code im Container-Image liegt. Der Container kann jederzeit neu gebaut, aktualisiert oder sogar gelöscht werden. Der State bleibt auf dem Host in einem separaten Verzeichnis erhalten und wird beim nächsten Start wieder eingebunden. Diese Trennung schafft Klarheit und macht das System beherrschbar.
Backup-Strategie – Nur State sichern, Code reproduzieren
Aus der Trennung von Code und State ergibt sich eine einfache, aber effektive Backup-Strategie.
Es reicht, den State-Bereich zu sichern. Der Code ist über die docker-compose.yml und die Git-Repositorys jederzeit reproduzierbar. Das reduziert die Backup-Komplexität erheblich und fokussiert auf das, was wirklich schützenswert ist.
In meinem Setup wird der State-Bereich regelmäßig gesichert. Bei einem Restore muss nur der State wiederhergestellt und der Container neu gebaut werden. Das gesamte System ist damit innerhalb weniger Minuten wieder einsatzbereit.
Diese Herangehensweise hat einen weiteren Vorteil: Backups sind kleiner, schneller und gezielter. Statt das gesamte System zu sichern, konzentrierst du dich auf die Daten, die tatsächlich Wert haben.
Diese Probleme hatte ich konkret
Ich möchte ehrlich sein: Der Start war nicht völlig reibungslos. Es gab Punkte, die mich Zeit und Nerven gekostet haben – und genau daraus habe ich gelernt.
Die Unsicherheit bei den Pfaden war das erste große Thema. Als ich zum ersten Mal vor der Docker-Struktur stand, war nicht sofort klar, welche Verzeichnisstrukturen wo hingehören. Container-Pfad vs. Host-Pfad, Bind-Mounts – das musste ich mir erst erschließen.
Besonders die Frage, was in den Container gehört und was draußen bleiben muss, war anfangs unklar. Die Erkenntnis, dass der State auf dem Host bleiben muss, weil Container-Dateisysteme beim Rebuild ersetzt werden, kam nicht sofort. Das Verständnis für die Architektur hat sich erst Schritt für Schritt aufgebaut.
Die Trennung von Code und State war der Wendepunkt. Sobald ich begriffen hatte, dass diese Trennung nicht optional ist, sondern Kern der Architektur, wurde das System beherrschbar. Plötzlich war klar: Der Container ist austauschbar, der State ist wertvoll. Diese Klarheit hat die gesamte Komplexität reduziert.
Was mir gefehlt hat, war eine klare Dokumentation dieser Struktur am Anfang. Ich habe sie mir erarbeiten müssen – und genau deshalb schreibe ich diesen Artikel. Du sollst nicht dieselben Umwege gehen müssen.
Die gute Nachricht: Sobald diese Struktur einmal steht, läuft das System außergewöhnlich stabil. Die Anfangsinvestition in das Verständnis zahlt sich im Betrieb mehrfach zurück.
Warum ich mich gegen Alternativen entschieden habe
Vor der Entscheidung habe ich mich kurz mit Alternativen zu Docker Compose beschäftigt. Der Vollständigkeit halber möchte ich das kurz einordnen.
Podman wird oft als rootless-Alternative genannt. Für meinen Use Case bot es aber keine entscheidenden Vorteile, während Docker Compose besser dokumentiert ist und eine größere Community hat.
LXC/LXD bietet eine andere Art der Containerisierung, näher an virtuellen Maschinen. Der Verwaltungsaufwand ist höher und es ist weniger auf typische DevOps-Workflows ausgelegt. Für die Art von Microservices, die OpenClaw mitbringt, war mir Docker mit seiner Compose-Integration die pragmatischere Wahl.
Rootless Docker wäre eine Überlegung wert, wenn Sicherheitsanforderungen es erfordern. Für mein homelab-Szenario mit klarer Netzwerksegmentierung war der zusätzliche Aufwand nicht gerechtfertigt.
Die Entscheidung für Docker Compose war also keine ideologische, sondern eine pragmatische: Gute Dokumentation, große Community, stabile Tools. Für den Einstieg und den produktiven Betrieb auf dem Raspberry Pi ist das für mich die zuverlässigste Lösung.
Wer später spezifische Anforderungen hat, kann mit etwas Anpassung immer noch migrieren. Die Architektur von OpenClaw ist grundsätzlich container-agnostisch – das Setup lässt sich anpassen.
Fazit – Meine klare Empfehlung
Nach mehreren Wochen Betrieb mit OpenClaw auf dem Raspberry Pi 5 kann ich ein klares Fazit ziehen: Die Entscheidung für Docker war richtig.
Für wen sich Docker lohnt: Technisch interessierte Anwender, die ein stabiles, dauerhaft laufendes System aufbauen wollen, sollten Docker nutzen. Wenn du OpenClaw nicht nur testen, sondern produktiv betreiben willst – mit Automatisierungen, Integrationen und langfristiger Wartbarkeit – dann ist Docker der richtige Weg.
Wann eine Host-Installation vielleicht reicht: Wenn du OpenClaw nur kurz ausprobieren willst, ohne langfristige Pläne, kann eine direkte Installation ausreichen. Auch wenn du bereits erfahrener Docker-Nutzer bist und eine alternative Container-Strategie bevorzugst, bist du frei, einen anderen Weg zu gehen. Für den typischen Use Case – ein zuverlässiges System, das im Hintergrund arbeitet – ist Docker aber die bessere Wahl.
Mein persönliches Resümee: Die Anfangsinvestition in das Verständnis der Docker-Architektur hat sich gelohnt. Das System läuft stabil, Updates sind kontrollierbar, und die Trennung von Code und State gibt mir Sicherheit. Die NVMe-SSD war dabei der eigentliche Gamechanger für die Performance, Docker kommt praktisch ohne spürbaren Aufpreis dazu. Meine Erfahrung zeigt, dass die Kombination aus openclaw raspberry pi docker am besten funktioniert.
Wenn du vor derselben Entscheidung stehst, die ich am Anfang hatte: Nimm Docker. Es ist der robustere, wartbarere und langfristig bessere Weg. Hast du ähnliche Erfahrungen gemacht oder Fragen zur Installation? Schreib mir gerne einen Kommentar.