Wenn du OpenClaw zum ersten Mal zum Laufen bringen willst, bremst dich meistens nicht der Installationsbefehl. Häufig ist das Problem, schon vor dem Start den falschen Weg zu wählen.

Viele landen in derselben Schleife. Man sieht Source-Setup, Docker, CLI-Onboarding, lokale Installation und Cloud-Deployment – und aus einer einfachen Frage wird plötzlich ein kleines Rechercheprojekt. Gehört das auf den Laptop oder auf einen Server? Ist das Source-Setup der „richtige“ Weg? Ist Docker automatisch einfacher? Wenn OpenClaw heute einfach nur laufen soll, welcher Pfad nervt am wenigsten?

Nachdem ich README und offizielle Docker-Dokumentation noch einmal durchgegangen bin, wirkt die Antwort viel weniger dramatisch als die Suchergebnisse. Es geht kaum darum, welche Befehle besser sind. Die eigentliche Frage lautet: Willst du OpenClaw jetzt benutzen, oder willst du vom ersten Tag an Verantwortung für Runtime und Build-Prozess übernehmen?

Zuerst entscheiden: benutzen oder besitzen?

Wenn du ein normaler Nutzer bist und OpenClaw einfach auf deinem eigenen Rechner zum Laufen bringen möchtest, würde ich nicht mit dem Source-Setup anfangen. Das README zeigt den vorgesehenen Nutzerpfad bereits: eine aktuelle Node-Umgebung verwenden – derzeit Node 24 oder mindestens Node 22.16+ –, CLI installieren und Onboarding starten:

npm install -g openclaw@latest
openclaw onboard --install-daemon

Dieser Ablauf wirkt genau wie das, was er sein soll: der Einstieg für Nutzer. CLI installieren, vom Onboarding durch die erste Konfiguration führen lassen und herausfinden, ob das Produkt für dich überhaupt nützlich ist.

Der Source-Pfad hat eine völlig andere Form:

git clone https://github.com/openclaw/openclaw.git
cd openclaw

pnpm install
pnpm ui:build
pnpm build

pnpm openclaw onboard --install-daemon
pnpm gateway:watch

Das ist nicht nur eine andere Installationsmethode. Es ist deutlich näher daran, eine Entwicklungsumgebung zu übernehmen. Du klonst das Repo, baust das UI, kompilierst das Projekt und sorgst gleichzeitig dafür, dass zukünftige Build-Probleme ebenfalls zu deinem Alltag gehören. Wenn du Kontrolle willst, ist das großartig. Wenn OpenClaw nur vor dem Abendessen laufen soll, eher nicht.

Genau hier stolpern viele. Source-Setup klingt ernsthafter und wirkt deshalb schnell wie die „korrekte“ Wahl. Für die meisten Erstnutzer ist es aber vor allem die schwerere. Node-Versionen, Dependencies, Build-Schritte, UI-Kompilierung und spätere Upgrade-Reibung gehören plötzlich zu deinem Problem, bevor du überhaupt entschieden hast, ob du OpenClaw behalten möchtest.

Docker ist nicht automatisch leichter: Laptop versus Server

Docker erzeugt eine ähnliche Verwirrung. „Docker“ klingt oft automatisch nach einfacher. Manchmal stimmt das, manchmal überhaupt nicht. Die OpenClaw-Docker-Dokumentation ist hier erfreulich ehrlich: Docker ist optional. Es ist sinnvoll, wenn du ein containerisiertes Gateway, Isolation oder einen Deployment-Pfad auf einem Host möchtest, der eher als Infrastruktur denn als Alltagsrechner behandelt wird. Wenn du am eigenen Rechner sitzt und einfach nur den kürzesten Weg zu einer funktionierenden Installation willst, führen die Docs zurück zum normalen Installationspfad.

Dieser Unterschied ist wichtig. Auf einem lokalen Rechner bringt Docker oft eigenen Setup-Aufwand mit. Docker Desktop oder Docker Engine, Compose v2, genug RAM zum Bauen oder Ausführen des Images und etwas mehr Geduld auf schwächerer Hardware. Die Dokumentation weist sogar darauf hin, dass der Image-Build mindestens 2 GB RAM möchte; sonst kann pnpm install auf einem Low-Memory-Host beendet werden. Das macht Docker nicht schlecht. Es bedeutet nur, dass Docker auf einem Laptop nicht automatisch der Weg mit dem geringsten Widerstand ist.

Auf einem VPS oder Linux-Server sieht es anders aus. Soll OpenClaw dort langfristig laufen, fühlt sich Docker deutlich natürlicher an. Nicht weil es magisch wäre, sondern weil es besser zum Job passt. Runtime-Isolation hilft, Rebuilds sind sauberer und ein späterer Umzug auf eine andere Maschine ist leichter zu verstehen. In diesem Kontext wirkt Docker weniger wie ein Installations-Shortcut und mehr wie die richtige Deployment-Grenze.

Der offizielle Docker-Workflow spiegelt das wider. Er ist nicht als hübscher One-Liner geschrieben. Der dokumentierte Hauptweg ist, ./scripts/docker/setup.sh im Repo-Root auszuführen und das Skript Image-Setup, Onboarding, .env und Docker-Compose-Start erledigen zu lassen. Wer nicht lokal bauen möchte, kann zuerst ein vorgefertigtes Image setzen:

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

Das verrät viel darüber, was der Docker-Pfad erreichen soll. Er versteckt nicht jedes bewegliche Teil, sondern verpackt die Runtime. Selbst die Dokumentation unterscheidet zwischen Setup-Aktionen und dem CLI-Workflow nach dem Start. Das ist Deployment-Territorium – nicht „erste Softwareinstallation auf einem neuen Laptop“.

Die Kurzfassung: Einen Pfad wählen heißt Wartungskosten wählen

Wenn ich es auf eine einfache Regel reduzieren müsste: Läuft OpenClaw auf deinem eigenen Rechner, beginne mit dem offiziellen CLI-Onboarding. Soll es auf einer Linux-Cloud-Maschine dauerhaft laufen, ist Docker wahrscheinlich passender. Wenn du bereits weißt, dass du Interna untersuchen, Verhalten ändern, eng am Repository bleiben und den Build-Prozess selbst besitzen möchtest, ist das Source-Setup sinnvoll.

Der wirkliche Unterschied zwischen Source-Setup und Docker ist für mich nicht die Anzahl der Befehle. Es geht darum, wo die Wartungslast liegen soll. Source-Setup bietet Transparenz und Flexibilität, macht aber Dependency-Installationen, UI-Builds, Environment Drift und Repo-Änderungen zu deinem Problem. Docker verschiebt vieles davon hinter eine Container-Grenze, was auf Servern angenehm ist. Dafür musst du dort weiterhin über Persistenz, Ports, Health Checks, Image-Updates und Exposure nachdenken. Die Docs sprechen über healthz, readyz, lan, loopback und sogar Docker-Firewall-Policy auf öffentlichen Hosts – ein ziemlich deutlicher Hinweis darauf, dass dies ein Deployment-Workflow für Operatoren ist.

Die vier häufigsten Fehler

Die typischen Fehler sind vorhersehbar. Leute behandeln Source-Setup als Standardpfad, obwohl es eher Dev Mode ist. Sie nehmen an, Docker müsse selbst auf dem lokalen Rechner einfacher sein. Sie ignorieren Runtime-Anforderungen wie die Node-Version und debuggen anschließend Symptome statt Ursachen. Oder sie bekommen ein Server-Deployment einmal zum Laufen und vergessen, dass Persistenz und Recovery langfristig wichtiger sind als der erste erfolgreiche Start.

Wenn OpenClaw auf einem Server bleiben soll, werden Backups praktisch ebenfalls verpflichtend. Mein früherer Beitrag über Docker-Volumes zu GitHub sichern als kostengünstigen Recovery-Pfad liegt genau in diesem Bereich. Das ist weniger spannend als Installation, wird aber beim ersten notwendigen Rebuild deutlich wertvoller.

Was mir an der OpenClaw-Dokumentation gefällt, sobald man sie nicht mehr als generische Installationsanleitung liest: Sie trennt die Zielgruppen eigentlich recht klar. Es gibt einen Weg für Nutzer, einen für Deployment und einen für Leute, die am Projekt selbst arbeiten wollen. Die meiste Verwirrung entsteht, wenn diese Rollen zu früh miteinander vermischt werden.

Wenn du deinen eigenen Server-Workflow aufbaust, lohnt sich außerdem der Deployment-Themenbereich. Dort kommen weitere Beiträge aus demselben Cluster hinzu: lokales Setup, VPS-Deployment, Docker-Trade-offs und die Frage, wie man einfache Installationen nicht unnötig schwer macht.