OpenClaw auf Raspberry Pi klingt nach einem Wochenendprojekt: Pi starten, Installer ausführen, Bot verbinden, fertig. Für den ersten Start stimmt das sogar teilweise. Für ein System, das jeden Tag als persönlicher Agenten-Host laufen soll, stimmt es nicht. Dauerbetrieb bringt andere Fragen nach vorne: Node-Version, systemd, Autostart, Tailscale, Rechte, Logs, Secrets und Update-Disziplin.
Dieser Artikel ist deshalb keine perfekte Erstinstallationsanleitung. Er ist ein Praxisbericht nach mehreren Monaten Betrieb: Was beim OpenClaw Raspberry Pi Setup wirklich zählt, welche Entscheidungen sich bewährt haben und wo aus einem schnellen Test ein fragiles System werden kann.
OpenClaw auf Raspberry Pi: Voraussetzungen
Ein Raspberry Pi 5 mit 8 GB RAM ist komfortabel. Ein Raspberry Pi 4 mit 4 GB RAM reicht für viele OpenClaw-Setups ebenfalls aus. OpenClaw selbst ist kein lokales LLM, das die CPU ausreizt. Die eigentliche Modellarbeit läuft in typischen Setups über externe APIs wie OpenAI, Anthropic oder Gemini. Der Pi hält Gateway, Sessions, Channels, Logs, Cron-Jobs und kleine lokale Hilfsprozesse zusammen.
Der lokale Engpass ist deshalb selten reine Rechenleistung. Spürbarer sind I/O, RAM-Reserve und thermische Stabilität. Eine schnelle A2-microSD oder besser eine SSD per USB macht bei Logs, Paketinstallationen und wiederholten CLI-Aufrufen einen Unterschied. Beim Pi 5 lohnt aktive Kühlung, wenn das Gerät dauerhaft läuft. Passiv gekühlt funktioniert der erste Test, aber Dauerbetrieb ist eine andere Lastklasse.
Als Betriebssystem bietet sich ein 64-Bit-Linux an, etwa Raspberry Pi OS Lite 64-Bit oder Debian 12/13 ARM64. Das 64-Bit-Image ist wichtig, weil aktuelle Node.js-Binaries und viele npm-Pakete auf ARM64 sauberer laufen. 32-Bit-Setups sind für diese Nutzung unnötige Reibung.
Die eigentliche Designfrage lautet: Soll der Pi ein privater Agenten-Knoten sein oder ein offen erreichbarer Dienst? Für ein persönliches OpenClaw-Setup ist die Antwort klar. Der Pi gehört nicht direkt ins Internet. Er gehört in ein privates Netz, idealerweise Tailscale oder ein vergleichbares WireGuard-Mesh.
Node.js und Installation
Die häufigste technische Stolperfalle ist Node.js. Distributionen liefern oft Versionen, die für moderne JavaScript-Tools zu alt sind oder später im Betrieb Ärger machen. Für ein wartbares Setup ist eine aktuelle LTS- oder projektseitig empfohlene Node-Version sinnvoller als das Paket aus der Standardquelle.
Zwei Wege funktionieren in der Praxis:
# Beispiel: NodeSource-Pfad für aktuelle Node-Versionen
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs
oder, für Nutzer die bewusst mehrere Node-Versionen verwalten:
# NVM-Pfad, wenn Versionen pro User verwaltet werden sollen
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
nvm install 24
nvm use 24
NVM ist flexibel, erzeugt aber einen wichtigen Folgeeffekt: Das openclaw-Binary liegt dann unter ~/.nvm/versions/node/.../bin/ und nicht unter /usr/bin/. systemd löst diese Shell-Umgebung nicht automatisch auf. Wer später einen User-Service debuggt, landet genau dort.
Der sauberste Einstieg ist der offizielle OpenClaw-Onboarding-Pfad. Er richtet Workspace, Provider, Channels und Gateway-Konfiguration zusammen ein. API-Keys gehören in diesen Wizard beziehungsweise in die von OpenClaw verwaltete Konfiguration, nicht in Shell-Profile, Bash-Skripte oder zufällige .env-Dateien.
Telegram als Channel
Telegram ist für einen Raspberry-Pi-Agenten praktisch: asynchron, ressourcenschonend, mobil gut nutzbar und tolerant gegenüber kurzen Offline-Phasen. Der Setup-Ablauf ist simpel:
- Bot bei
@BotFatheranlegen. - Token nur einmal in OpenClaw eintragen.
- Token wie ein Passwort behandeln.
Der letzte Punkt ist der wichtige. Ein Telegram-Bot-Token gehört nicht in Git, nicht in Logs und nicht in Chat-Screenshots. Wer den Pi als persönlichen Agenten-Host betreibt, baut sich sonst eine unnötige Seitentür.
Gateway und systemd
Der Gateway-Daemon hält Channels, Sessions und Agentenlaufzeit zusammen. Für Dauerbetrieb muss er nach Reboot automatisch starten. Auf einem headless Pi führt kein Weg an systemd vorbei.
Wenn OpenClaw den User-Service selbst installiert, ist das die wartungsärmste Variante. Danach sind drei Prüfungen wichtig:
systemctl --user status openclaw-gateway
journalctl --user -u openclaw-gateway -n 100 --no-pager
loginctl show-user "$USER" | grep Linger
Lingering ist der Punkt, der oft vergessen wird. Ohne Lingering startet ein User-Service erst, wenn der Benutzer eingeloggt ist. Nach einem Stromausfall steht der Pi dann zwar wieder im Netz, aber der Gateway läuft nicht, bis jemand per SSH verbunden war.
sudo loginctl enable-linger "$USER"
Bei NVM-Installationen muss der Service den korrekten Pfad kennen. Wer openclaw im Terminal starten kann, aber systemd scheitert, sollte zuerst PATH und ExecStart prüfen. Ein Service, der zufällig von einer interaktiven Shell abhängt, ist kein stabiler Service.
Signal der Woche abonnieren
Eine Nachricht. Eine Analyse. Jeden Freitag im Newsletter.
Kostenlos als Member. Gratis abonnieren
Sicherheit: Tailscale, Firewall, Rechte
Ein Raspberry Pi, der 24/7 läuft und externe APIs nutzt, ist kein Spielzeuggerät. Er ist ein kleiner Server mit Secrets, Logs und Kommunikationskanälen. Die wichtigste operative Regel lautet, unnötige Internet-Exposition im Dauerbetrieb konsequent zu vermeiden.
Tailscale ist für private Setups die einfachste Lösung. Der Pi bleibt hinter NAT und ist nur über authentifizierte Geräte erreichbar. Router-Port-Forwarding für SSH ist in diesem Szenario überflüssig.
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
Für SSH gilt: Key-Login, kein Passwort-Login, kein offener Port ins Internet. UFW sollte nur erlauben, was wirklich nötig ist. Wenn der Zugriff über Tailscale läuft, kann SSH auf das private Netz begrenzt werden.
Secrets und Konfiguration verdienen eine eigene Routine. Typische Dateien unter ~/.openclaw/ enthalten API-Keys, Channel-Token oder Auth-Informationen. Sie sollten nicht gruppen- oder weltlesbar sein.
chmod 700 ~/.openclaw
find ~/.openclaw -type f -name '*key*' -o -name '*auth*'
Das konkrete Rechtekonzept hängt vom Setup ab. Die Grundregel bleibt: Secrets nur für den Benutzer, der den Gateway betreibt. Keine Backups in unverschlüsselte Cloud-Ordner, keine Tokens in Skripten, keine Debug-Ausgaben mit Key-Werten.
Diagnose und Wartung
Die besten Pi-Setups sind langweilig. Sie starten nach Reboot, loggen verständlich und zeigen Probleme früh. Drei Befehle gehören zur Routine:
openclaw doctor
openclaw status
journalctl --user -u openclaw-gateway -n 200 --no-pager
doctor prüft typische Konfigurationsprobleme. status zeigt den aktuellen Zustand von Gateway, Channels und Laufzeit. journalctl liefert den Verlauf, wenn etwas nicht sauber startet. Blindes Neustarten des Gateway löst selten die Ursache. Die Logs sagen meist schneller, ob Node, PATH, Rechte, Provider-Key oder Netzwerk das Problem ist.
Nach Updates lohnt sich ein kurzer Smoke-Test. Gateway neu starten, Telegram anpingen, doctor laufen lassen, Logs prüfen. Das klingt banal, verhindert aber die häufigste Fehlerklasse: Ein Update war erfolgreich, aber ein Service-Pfad, eine Node-Version oder ein Token ist nicht mehr konsistent.
Wer OpenClaw mit Agenten-Infrastruktur, Tools oder MCP-ähnlichen Konzepten verbindet, sollte zusätzlich die Sicherheitsgrenzen der Agenten verstehen. Der Artikel zum MCP-Standardkampf um KI-Agenten-Infrastruktur ordnet ein, warum Tool-Zugriff und Protokollgrenzen keine Nebensache sind.
Was nach drei Monaten Betrieb bleibt
Nach mehreren Monaten Betrieb ist die Bilanz nüchtern: Der Raspberry Pi ist selten der Engpass. Die Probleme entstehen an den Rändern.
Node-Versionen und Paketupdates bleiben die häufigste technische Reibung. Wer Node über apt/NodeSource verwaltet, hat weniger Shell-Magie. Wer NVM nutzt, braucht mehr Disziplin bei systemd-Pfaden.
Autostart ist die zweite Sollbruchstelle. Ohne Lingering oder korrekt installierten User-Service startet der Gateway nach Reboot nicht automatisch. Das fällt oft erst beim ersten Stromausfall auf.
Secret-Hygiene ist die dritte. Ein Pi sammelt mit der Zeit Tokens, Auth-Dateien, Logs und temporäre Artefakte. Wenn diese Dateien zu breit lesbar sind oder in Backups landen, ist das Sicherheitsversprechen dahin.
Scope-Kontrolle ist die vierte. Ein persönliches Agentensystem wächst schnell: erst Telegram, dann Cron-Jobs, dann Social-Posting, dann RAG, dann Tools. Der robuste Ausbaupfad ist langsamer: ein Channel, ein klarer Use Case, ein stabiler Gateway, saubere Rechte. Danach erst weitere Werkzeuge.
Wer lokale Modellinferenz sucht, sollte den Pi nicht überfordern. OpenClaw auf Raspberry Pi ist ein guter Orchestrierungs- und Gateway-Knoten, kein sinnvoller LLM-Inferenzserver. Für lokale Modelle sind Mac mini, Workstation, DGX-Spark-Klasse oder ein dedizierter Inferenzserver realistischere Geräteklassen. Der Artikel zu lokaler LLM-Inferenz mit vLLM, llama.cpp, Ollama und TensorRT-LLM zeigt, warum Serving-Stack und Hardware zusammen entschieden werden müssen.
Der Raspberry Pi scheitert in solchen Setups selten an seiner Hardware. Er scheitert an Nachlässigkeit: offener Port, falscher systemd-Pfad, zu breite Rechte, Token in einem Skript. Wer diese kleinen Dinge sauber hält, bekommt einen erstaunlich robusten Agenten-Knoten. Wer sie ignoriert, baut sich ein Langzeitproblem.
Fazit: klein, robust, aber nicht wartungsfrei
OpenClaw auf Raspberry Pi ist eine gute Kombination, wenn der Pi als privater Gateway- und Orchestrierungsknoten verstanden wird. Er ist günstig, leise, stromsparend und stark genug für Channels, Sessions und leichte Automatisierung. Er ist keine magische Appliance.
Der Unterschied zwischen Bastelsetup und belastbarem Betrieb liegt in den unspektakulären Details: aktuelle Node-Version, sauberer systemd-Service, Lingering, Tailscale, enge Rechte, Logs und regelmässige Diagnose. Wer diese Basis baut, kann auf dem Pi ein stabiles persönliches Agentensystem betreiben. Wer sie auslässt, spart am falschen Ende.
Kann OpenClaw auf einem Raspberry Pi 4 laufen?
Ja. Ein Pi 4 mit 4 GB RAM reicht für viele persönliche Setups, solange die Modellberechnung über externe APIs läuft. Der Pi 5 ist komfortabler, aber nicht zwingend nötig.
Welche Node-Version ist sinnvoll?
Eine aktuelle LTS- oder projektseitig empfohlene Version. Wichtig ist weniger der einzelne Versionsname als ein konsistenter Installationspfad, den auch systemd sauber findet.
Sollte der Pi direkt aus dem Internet erreichbar sein?
Nein. Für persönliche Setups ist Tailscale oder ein vergleichbares privates VPN die bessere Lösung. Offenes SSH per Port-Forwarding erhöht das Risiko ohne echten Nutzen.
