OpenClaw auf dem Raspberry Pi betreiben: das sinnvolle Setup für lokale Agents ohne Cloud-Zirkus
Warum Raspberry Pi in OpenClaw-Kreisen gerade wieder Thema ist
Ein nützlicher OpenClaw-Thread heute drehte sich ausnahmsweise nicht um Modell-Benchmarks, Agent-Coins oder das übliche „die Zukunft ist autonom“-Gerede. Es ging um etwas viel Praktischeres: Jemand beschrieb ein echtes Setup auf einem Raspberry Pi, basierend auf OpenClaw und ein paar sauber ausgewählten Tools, und sofort war klar, warum das viele interessiert.
Das ergibt Sinn.
Viele stoßen gerade auf dieselbe Hürde. Sie mögen die Idee, OpenClaw selbst zu hosten, wollen aber nicht direkt mit einem vollen Homelab-Rack, einem dauerhaft laufenden Desktop oder einem öffentlichen VPS beginnen, den sie sofort wie eine produktive Internet-Exposition härten müssten. Sie wollen etwas Kleines, Günstiges, Lokales und Verständliches.
Genau da ist der Raspberry Pi stark.
Nicht weil er magisch leistungsfähig wäre. Ist er nicht. Wer so tut, als sei ein Pi ein Mini-Rechenzentrum, landet schnell bei Enttäuschung. Interessant ist der Pi, weil er für die Teile von OpenClaw ausreicht, die im Alltag wirklich zählen: Gateways, Memory-Dateien, Cron-Jobs, Benachrichtigungen, API-Calls, leichte Automationen und die Orchestrierung anderer Systeme.
Wenn dein mentales Modell von OpenClaw lautet: „eine einzige Box muss zusätzlich schwere lokale Inferenz, Browser-Schwärme, Videopipelines und sechs parallele Coding-Agents stemmen“, dann wird ein Pi eng. Wenn dein Modell aber lautet: „dauerhaft laufende persönliche Agent-Infrastruktur mit sauberen Grenzen“, dann ist der Pi oft der Sweet Spot.
---
Wofür ein Raspberry Pi tatsächlich gut ist
Lass uns konkret werden.
Ein Raspberry Pi passt gut zu OpenClaw, wenn du:
Gerade der letzte Punkt ist wichtig.
OpenClaw muss nicht jede rechenintensive Aufgabe lokal erledigen, um nützlich zu sein. In vielen praxisnahen Deployments ist der Pi die Control Plane. Er empfängt Nachrichten, entscheidet über nächste Schritte, aktualisiert Memory, plant Jobs, ruft APIs auf und delegiert schwerere Arbeit, wenn sie wirklich nötig ist.
Das ist eine völlig andere Last als „große Modelle lokal ausführen“.
Viele werfen diese Dinge ständig zusammen.
Wenn du lokale Inferenz willst, nimm die passende Hardware. Mac Mini, Workstation oder GPU-Server sind eine andere Diskussion. Wenn du aber einen stabilen persönlichen Agent willst, der bei dir zuhause lebt, standardmäßig privat bleibt und weiterläuft, während dein Laptop schläft, dann ist ein Pi absolut vernünftig.
---
Warum ein Pi für viele Einsteiger sinnvoller ist als ein billiger VPS
Hier kommt der Teil, gegen den manche instinktiv ankämpfen, weil „stell es auf einen VPS“ immer noch ernster klingt.
Für viele OpenClaw-Nutzer ist ein Raspberry Pi aber tatsächlich das sicherere erste Deployment.
Warum?
Weil ein Pi im Heimnetz, erreichbar nur über Tailscale oder einen anderen privaten Pfad, mit deutlich weniger versehentlichen Exposure-Punkten startet als irgendein öffentlicher VPS. Du bindest das Gateway seltener an <code>0.0.0.0</code>, vergisst seltener Firewall-Regeln, lässt seltener schwache Tokens aktiv oder exponierst Hilfsports, an die du eine Woche später nicht mehr denkst.
Ein VPS kann absolut richtig sein. Aber er bringt sofort erwachsene Verantwortung mit:
Auf einem Pi kannst du zuerst die operativen Gewohnheiten lernen, ohne gleichzeitig deine Fehler dem offenen Internet anzubieten.
Das ist keine Feigheit. Das ist sinnvolle Reihenfolge.
Wenn dein Ziel später ein gehärtetes öffentliches Deployment ist, ist der Pi sogar eine gute Generalprobe, weil die Grundprinzipien dieselben bleiben: explizite Mounts, sauberes Env-Management, Non-Root-Runtime, vorsichtiger Skill-Einsatz und null Vertrauen in unklare Ambient-Rechte.
---
Die richtige Architektur: Pi als Steuerzentrale, Cloud für Intelligenz, andere Maschinen für schwere Arbeit
Das ist die Architektur, die ich den meisten Leuten gerade empfehlen würde.
Nutze den Raspberry Pi für:
Nutze gehostete Modelle für Reasoning und Generierung.
Nutze eine weitere Maschine nur dann, wenn du wirklich eines davon brauchst:
Diese Architektur hält den Pi in genau der Rolle, für die er hervorragend ist: immer verfügbar, günstig, leise, privat und nachvollziehbar.
Der größte Fehler ist aus meiner Sicht der Versuch, aus ideologischer Reinheit ein winziges Gerät alles machen zu lassen. Das ist nicht elegant. Das ist fragil.
OpenClaw wird besser, wenn die Topologie ehrlich ist.
---
Docker auf dem Pi: immer noch mein Standard
Ja, auch auf dem Raspberry Pi würde ich mit Docker starten, solange du keinen konkreten Grund dagegen hast.
Die Logik ist dieselbe wie auf größeren Hosts. Docker gibt dir eine sauberere Deploy-Fläche, klarere Volumes, einfachere Updates und eine bessere Standardgrenze zwischen Agent und Rest des Systems.
Ein vernünftiges Pi-Deployment sollte trotzdem langweilig aussehen:
Wenn du Compose verwendest, sollte dein Setup wie eine Liste absichtlicher Entscheidungen aussehen, nicht wie ein Panikprotokoll aller Optionen, die irgendeinen Fehler kurzfristig verschwinden ließen.
Eine vereinfachte Grundform reicht oft schon:
<pre><code class="language-yaml">services:
openclaw:
image: ghcr.io/openclaw/openclaw:latest
user: "1000:1000"
volumes:
- ./workspace:/home/openclaw/.openclaw/workspace
- ./.env:/home/openclaw/.openclaw/.env:ro
ports:
- "127.0.0.1:18789:18789"
security_opt:
- no-new-privileges:true
restart: unless-stopped</code></pre>
Damit startet man bereits sauber.
---
Das Sicherheitsmodell, das Pi-Deployments wirklich sinnvoll macht
Der eigentliche Gewinn eines Pi-Setups ist nicht der Preis. Es ist kontrollierbares Vertrauen.
Wenn du die Maschine lokal hältst und keine Ports öffentlich exponierst, schneidest du eine ganze Risikoklasse weg. Wenn du dann noch Tailscale für privaten Zugriff nutzt, starke Gateway-Tokens setzt, Workspace-Rechte sauber hältst und Skills vorsichtig behandelst, hast du plötzlich etwas, das viele in der Cloud nie erreichen: ein Setup, dessen Blast Radius du wirklich erklären kannst.
Meine klare Empfehlung für OpenClaw auf einem Pi lautet:
1. Gateway niemals direkt ins öffentliche Internet hängen
2. <code>tailscale serve</code> oder einen anderen privaten Zugriffspfad nutzen, keine öffentlichen Tunnel-Abkürzungen
3. <code>.env</code> nur für den OpenClaw-User lesbar machen
4. Service als Non-Root laufen lassen
5. Approval-Grenzen für riskante Exec-Flows setzen
6. Skills vor Installation prüfen
7. dokumentieren, worauf der Agent zugreifen darf
Das klingt banal, aber fast jede „ich wurde gehackt“-Geschichte ist am Ende nur die selbstbewusste Missachtung banaler Regeln.
---
Die Performance-Frage, die immer kommt
Also, fühlt sich OpenClaw auf einem Raspberry Pi langsam an?
Manchmal ja, aber meistens nicht aus den Gründen, die Leute erwarten.
Der Flaschenhals in vielen OpenClaw-Workflows ist der Modell-Call, die Netzwerklatenz oder eine externe API, auf die du wartest, nicht die rohe CPU-Leistung. Wenn der Agent Memory-Dateien liest, zwischen Tools entscheidet, einen HTTP-Request abschickt oder in einem Chat antwortet, reicht der Pi oft völlig aus.
Eng wird es eher, wenn du gleichzeitig stapelst:
Genau deshalb ist ehrliches Workload-Design so wichtig.
Bewerte einen Pi nicht anhand von Aufgaben, die du ohnehin besser delegiert hättest.
Für eine Person, oder sogar ein kleines internes Team, kann ein Pi-gehostetes OpenClaw-Gateway absolut reichen, wenn du es als Koordinator behandelst und nicht als rohe Rechenmaschine.
---
Operative Realität: Ein Pi ist besser, wenn du ihn auch wirklich pflegst
Das ist der unterschätzte Vorteil.
Ein Raspberry Pi gehört dir physisch. Du weißt, wo er steht. Du kannst ihn beschriften, sichern, an eine USV hängen, neu starten und nachvollziehen, was sonst noch darauf läuft. Für viele Operatoren führt das zu besserem Wartungsverhalten als bei einem 5-Dollar-VPS, der einmal aufgesetzt und dann mental vergessen wurde.
Gute OpenClaw-Infrastruktur hängt nicht davon ab, wo die Maschine steht. Sie hängt davon ab, ob du sie gesund hältst.
Kannst du Updates einspielen?
Kannst du Logs prüfen?
Kannst du einen kaputten Container wiederherstellen?
Kannst du Secrets rotieren?
Kannst du deine Vertrauensgrenzen sechs Wochen später noch erklären?
Wenn die Antwort auf dem Pi ja und auf dem VPS nein lautet, dann ist der Pi das ernsthaftere Deployment.
---
Wer dieses Setup tatsächlich wählen sollte
Ein Raspberry Pi ist der richtige erste OpenClaw-Host, wenn du zu einer dieser Gruppen gehörst:
Es ist der falsche erste Host, wenn dein echter Bedarf schwere lokale Compute-Last, breite Browser-Automation oder viel parallele Engineering-Arbeit auf derselben Maschine ist.
Das ist kein Versagen des Pi. Das ist einfach ehrliche Hardware-Wahl.
---
TL;DR
Der Raspberry-Pi-Trend rund um OpenClaw ist nicht zufällig.
Nicht weil ein Pi die stärkste Option wäre, sondern weil er oft die vernünftigste ist.
Er gibt dir eine günstige, leise, dauerhaft laufende Steuerzentrale für deine Agents. Er hält dein Setup lokal. Er macht private-by-default-Zugriff einfacher. Er hilft dir, die richtigen Gewohnheiten rund um Docker, Secrets, Rechte und Netzwerk-Exposure zu lernen, bevor du auf etwas Größeres wechselst.
Wenn du OpenClaw willst, das nach Infrastruktur aussieht und nicht nach Theater, ist ein Raspberry Pi ein verdammt guter Startpunkt.
Komplette Setup-Anleitungen, Härtungsschritte und praxistaugliche Architekturmuster findest du im OpenClaw Setup Playbook.