Dieser Leitfaden richtet sich an Betreiber, die OpenClaw in echte Workflows einbinden: OpenClaw-Installations-Tutorial (CLI vs. Container), Docker-Deployment, Reverse-Proxy mit TLS, Produktions-Härtung, häufige Fehler und ein wiederholbares Muster für einen Remote-Mac-Workflow. Die Befehle wurden mit dem öffentlichen openclaw/openclaw-README und docs.openclaw.ai/install/docker abgeglichen (Stand Frühjahr 2026). Einstieg bei MacCompute: Startseite, Übersicht Notizen & Anleitungen, Dokumentation Hilfe-Center.
2026: OpenClaw-Deployments und typische Szenarien
OpenClaw ist ein self-hosted Assistenten-Stack: Gateway als WebSocket-Kontrollebene (Standard ws://127.0.0.1:18789), Control UI im Browser, CLI, optionale Kanäle und Werkzeugausführung auf dem Host oder in Sandboxes. Typische Schmerzpunkte vor dem Go-Live:
- Port/Bind-Drift — UI erreichbar im Container, vom Host aus „tot“ oder umgekehrt; falsche gateway.bind-Kombination mit Tailscale oder Proxy.
- Schwache Kanten-Sicherheit — Gateway-Token wie Root-Credentials behandelt, aber öffentlich ohne TLS oder ohne Rate-Limits exponiert.
- Last auf dem Laptop — lange Agent-Läufe und macOS-spezifische Builds blockieren lokale Maschinen statt entkoppeltem Worker.
Der Text bleibt tutorialnah: kopierbare Befehle, klare Ports, schnell scannbare Tabellen.
Umgebung: Vorab-Checkliste (abhacken)
- Node (CLI-Pfad) — README: Node 24 (empfohlen) oder Node 22.16+ vor npm install -g openclaw@latest.
- Docker + Compose v2 — aktuelle Engine/Desktop-Version; offizielle Docker-Doku warnt: ≥ 2 GB RAM für Image-Build (sonst OOM/Exit 137).
- Git — Klonen des Repos für ./scripts/docker/setup.sh.
- DNS + TLS — bei öffentlicher UI Hostname und Zertifikat (Caddy oder certbot/Nginx).
- Firewall — bei VPS: OpenClaw-Sicherheitshinweise zu Netz-Exposition und Docker-DOCKER-USER lesen.
Nachvollziehbare Installationspfade: globales CLI vs. Docker
Empfohlener CLI-Pfad (README):
npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw gateway --port 18789 --verboseControl UI: http://127.0.0.1:18789/. Nach Updates: openclaw doctor.
Docker-Pfad (offizielle Docker-Doku, im geklonten Repo-Root):
git clone https://github.com/openclaw/openclaw.git
cd openclaw
./scripts/docker/setup.shLokalen Build überspringen:
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.shOptional: export OPENCLAW_SANDBOX=1 vor dem Setup für Sandbox-Bootstrap (siehe upstream Sandboxing).
Vergleich: globales CLI vs. Docker
| Thema | Globales CLI | Docker (scripts/docker/setup.sh) |
|---|---|---|
| Ideal für | Schnelle lokale Iteration, nativer Daemon via onboard | Isoliertes Gateway, weniger Host-Zustand, reproduzierbare Server |
| Einstiegsbefehl | openclaw onboard --install-daemon | ./scripts/docker/setup.sh (nicht verwechseln mit inoffiziellem docker-setup.sh) |
| Control-UI-URL | http://127.0.0.1:18789/ | gleich nach Port-Publish |
| Health | curl -fsS http://127.0.0.1:18789/healthz | gleich; Image mit HEALTHCHECK auf /healthz |
| CLI im Container | Host-openclaw … | docker compose run --rm openclaw-cli … |
Minimale Produktions-Sicherheit: Bind, Token, Sandbox, Egress
Bind. Konfiguration gateway.bind mit Werten wie lan, loopback, tailnet, auto, custom. Docker-Setup setzt oft OPENCLAW_GATEWAY_BIND=lan. Mit Tailscale Serve/Funnel verlangt die Doku typischerweise loopback plus Proxy auf demselben Host.
Token & UI. Setup-Wizard schreibt Gateway-Token in .env—in den Control-UI-Einstellungen eintragen; wie Hochprivilegierung behandeln.
DM & Kanäle. Eingehende DMs sind untrusted input; Standard-Pairing blockiert Unbekannte bis openclaw pairing approve …. openclaw doctor zeigt riskante Richtlinien.
Sandbox. Für Gruppen-Sessions agents.defaults.sandbox.mode: "non-main" erwägen (pro Session Docker-Sandboxes, siehe Sandboxing-Doku).
Ausgehend. Egress auf Netzebene einschränken; Tool-Allow/Deny in der Config ergänzen.
Nginx oder Caddy: Reverse Proxy und HTTPS
Upstream empfiehlt u. a. Tailscale Serve/Funnel und SSH-Tunnel. Generisch: TLS auf Nginx/Caddy terminieren und zum Gateway auf 127.0.0.1:18789 proxyen.
Caddy (illustrativ):
claw.example.com {
reverse_proxy 127.0.0.1:18789
}Nginx: Upgrade und Connection für WebSocket-Pfade der UI setzen (Pfade: docs.openclaw.ai/web).
Checks: Zertifikat gültig; nur 443 exponiert; Admin-Routen rate-limiten oder per IP-Allowlist schützen; curl -fsS https://claw.example.com/healthz durch den Proxy testen.
Problem-Matrix: Symptom → Ursache → Maßnahme
| Symptom | Wahrscheinliche Ursache | Befehl / Fix |
|---|---|---|
| Port 18789 belegt | Altes Gateway oder anderer Dienst | Linux: ss -tlnp | grep 18789; macOS: lsof -nP -iTCP:18789 | grep LISTEN; Port ändern oder Stack stoppen |
| Control UI „unauthorized“ | Token oder Device-Pairing | docker compose run --rm openclaw-cli dashboard --no-open; Pairing laut Doku |
| CLI zeigt ws://172.x | Bind/Modus-Drift in Docker | Reset: config set gateway.mode local, config set gateway.bind lan, dann ws://127.0.0.1:18789 prüfen |
| Build Exit 137 | OOM bei pnpm install | ≥ 2 GB RAM oder OPENCLAW_IMAGE nutzen |
| EACCES auf Mounts | Bind-Mount-Besitz | sudo chown -R 1000:1000 … (Container-User uid 1000) |
| Gateway nicht „ready“ | Listener fehlt | curl -fsS http://127.0.0.1:18789/healthz und /readyz |
Praxisbeispiel: Remote-Mac—Build, Skript, Benachrichtigung
Für gemietete oder dedizierte Mac-mini-Kapazität: Mac als Ausführungsinsel, Geheimnisse auf dem Host, Steuerung per SSH (SSH/VNC-Checkliste).
- Provisionierung — Docker Desktop oder Colima, alternativ Node + globales CLI wie in Abschnitt 3.
- OpenClaw — openclaw onboard --install-daemon oder Repo klonen und ./scripts/docker/setup.sh mit persistentem OPENCLAW_CONFIG_DIR / Workspace auf Datenplatte.
- Batch — cron oder launchd ruft Build-Skript; Artefakte unter ~/.openclaw/workspace oder CI-Pfad; Exit-Codes in Logs.
- Notify — Webhook (Slack/Telegram) am Skriptende; optional Agent liest strukturierte Logs.
- Verifikation — vom Laptop: ssh mac 'curl -fsS http://127.0.0.1:18789/healthz'; UI-Tunnel: ssh -L 18789:127.0.0.1:18789 mac, dann http://127.0.0.1:18789/.
Erwartetes Ergebnis: Builds und Agent-Batches laufen unbeaufsichtigt; Gateway bleibt gesund; Debugging über Logs und gelegentliche UI per Tunnel ohne öffentliches 18789.
FAQ und Kurz-Triage
Brauche ich Docker nur für sandboxes Agents? Sandboxing kann Docker nutzen, Gateway nativ laufen—siehe upstream „Sandboxing“ vs. „Docker (optional)“.
Wo liegt der Zustand? Compose bind-mountet Config (OPENCLAW_CONFIG_DIR) und Workspace gemäß Docker-Doku; Backups wie für Secrets + Arbeitsverzeichnis planen.
Erster Schritt bei „nichts lauscht“? docker compose ps oder openclaw doctor, danach Health-curl.
Fazit
Produktivbetrieb mit OpenClaw hängt an richtigem Installationspfad (CLI-onboard vs. ./scripts/docker/setup.sh), stabilem Port 18789, Bind-Modus passend zur Exposition und Defense in Depth (Token, DM-Pairing, optionale non-main-Sandboxes, Firewall). Kombinieren Sie das mit einem Remote-Mac, wenn macOS-Toolchains oder lange Agent-Läufe einen dauerhaften Worker brauchen.
Für planbare 24/7-Mac-Kapazität—Build-Farmen, Agenten, Batch-Warteschlangen—Preise prüfen, über Kaufen Region und SKU wählen; das Hilfe-Center begleitet Zugang und Abrechnung.