2026 OpenClaw mit Docker Compose auf Mac-Cloud 24/7: Healthchecks, Ressourcenlimits, compose pull, Rollback

Ein Container, der startet, ist nicht dasselbe wie ein Gateway, das eine Woche überlebt: Compose ohne healthcheck und Speicherlimits endet oft in nächtlichen Neustarts, OOM bei Builds und Tokens, die nach einem Upgrade nicht mehr passen. Der Text richtet sich an Teams, die das offizielle OpenClaw-Image auf Mac-Cloud oder Self-Hosting betreiben. Er benennt drei Betriebsirrtümer, vergleicht Ad-hoc-Container mit produktivem Compose, liefert ein siebenstufiges Runbook für Ihre Pager-Dokumentation und verweist auf unseren Artikel zu Exit 137, Volume-Rechten und DNS sowie das Longread Production Hardening: Exposure, Token, Sandboxing.

OpenClaw-Gateway unter Docker Compose auf Mac-Cloud-Host

Auf dieser Seite

1. Drei Irrtümer: compose up -d als fertig werten

Schnellstarts zielen auf ein grünes Terminal am ersten Tag. Produktion auf der Mac-Cloud interessiert sich für wiederholbare Fehlerbilder, die erst sichtbar werden, wenn die SSH-Sitzung endet und der Host weiterläuft. In Incident-Notizen 2026 dominieren drei Muster.

  1. Container-Status statt Readiness beobachten: running ohne Listener auf 18789 oder ohne beschreibbaren Workspace führt dazu, dass Orchestrierer und Reverse-Proxies den Stack zu früh als gesund werten und die Kanal-Reconnect-Logik fluten.
  2. Laptop-Speicherwerte 1:1 in Cloud-SKUs kopieren: Image-Rebuilds, Dependency-Installs und einmalige pnpm-Jobs spitzen höher als der Chat im Leerlauf. Wenn das Speicher-limit nur dem RSS des Gateways im Leerlauf entspricht, ist der erste compose pull, der einen Rebuild triggert, jener mit OOM. Die Geschichte folgt dem Exit-137-Leitfaden, erscheint aber im Upgrade statt beim ersten Boot.
  3. latest statt Tippen von Tags: Auf unbeaufsichtigten Hosts ist ein schwebendes Tag keine Ersparnis, sondern eine undokumentierte Konfigurationsmigration. Rollback ohne Archiv des Konfigurationsbaums und gepinntes Digest ist Rätselraten.

Trennen Sie die Zeitfenster für Build, Kaltstart und stabilen Proxy-Traffic. Mit Compose lassen sich unterschiedliche Ressourcen-Envelopes und Neustartrichtlinien zuordnen, was in einer losen docker run-History mühsam zu beschreiben ist.

Wer nur Logs im Terminal sieht, übersieht oft, dass der Docker-Daemon selbst Speicher und I/O beansprucht und dass auf gemieteten Macs die Root-SSD kleiner wirkt, sobald mehrere große Images parallel liegen. Ein kurzer Smoke-Test nach up -d reicht nicht: planen Sie gezielt Lastspitzen für Abhängigkeitsinstallationen und dokumentieren Sie, welche Compose-Profile in der Nacht aktiv sind, damit der nächste Dienst nicht heimlich denselben Speicherpool leert.

2. Entscheidungstabelle: Ad-hoc-Container vs. Compose auf Mac-Cloud

Die Matrix zeigt, welche Betriebsfunktionen Sie wirklich haben, und wann im Hardening-Artikel die Sprungmarke sinnvoll ist, wenn das Risiko Token und Netzwerkexposure statt CPU ist.

BedarfEinzel-Container ad hocCompose plus Mac-CloudNotiz
Dokumentierte ReadinessManuelle Curlshealthcheck und geordnete depends_onProben müssen echte App-Readiness prüfen, kein nacktes TCP
Build- vs. Laufzeit-Speicher trennenEin Limit für allesProfile oder Dienste mit höherer Build-DeckelungReduziert Exit 137 beim Upgrade
Auditierbare UpgradesSchwebendes latestUnveränderliches tag@digest und ChangelogRollback: Tag umschwenken, tar einspielen
Security-FlächeBind-Mounts und Bridge leicht vergessbarNetz und read-only in Gitmit Token- und Sandbox-Hardening kombinieren
Praxis: Pro Host eine Zeile mit Compose-Projektname, Datenverzeichnis und Port für SSH-Tunnel. Triage beginnt mit Identität, nicht mit grep über Laptops.

Die Tabelle ist absichtlich knapp gehalten, damit Produkt- und Sicherheitsrollen dieselbe Seite unterschreiben können. Wenn eine Zeile leer bleibt, ist das ein Signal, dass Sie entweder noch kein echtes Compose-Setup haben oder dass kritische Kontrollen nur in privaten Notizen existieren. Beides ist vorhersagbar riskanter als ein explizites „wir machen das später“ im Backlog, weil später oft der nächste Release-Druck ist und Docker-Details dann wieder unter den Tisch fallen.

3. Sieben Schritte: Baseline bis Rollback

  1. Baseline einfrieren: Docker-Engine- und Compose-Minor, RAM-Headroom, Lage der Layer relativ Root-Volume; df -h ins interne Wiki.
  2. Minimales compose.yaml: restart, explizite Host-Pfade für Volumes, UID-Ausrichtung, damit das Gateway nicht permanent Permission denied kämpft.
  3. Healthchecks: Die Sonde muss Gateway-Bereitschaft belegen, nicht nur TCP offen. interval über Kaltstart-P95, start_period großzügig für neue Major-Images.
  4. Ressourcen: CPU- und Speicherlimits pro Dienst; Build- oder Migrationsjobs nie dieselbe cgroup wie den Langläufer.
  5. Pre-Upgrade-Backup: env und Konfigverzeichnis taren, docker image ls --digests ins Ticket. Automatisierung schlägt Kopfnotiz.
  6. Upgrade: docker compose pull, danach up -d mit offenem Ticket; Smoke fail → vorherigen Tag in einem Change set und tar wiederherstellen. docker compose ps neben curl/CLI auf 18789.
  7. Post-Rollback: Kanal-Smoke, Modellliste, JSONL auf Reconnect-Loops, dann offene Punkte aus Hardening zu Token-Scope und Sandboxes.
# Skizze—Pfade/Endpunkte anpassen # healthcheck: test: ["CMD", "curl", "-fsS", "http://127.0.0.1:18789/ready"] docker compose up -d # Rollback: PREVIOUS_TAG pinnen, dann docker compose up -d

4. Richtwerte: Speicher, Wiederholungen, Tags

Diese Anker starten Review-Gespräche; messen Sie mit Ihren Images und Ihrem Mac-Cloud-Plan neu. Erstens: Apple-Silizium-Knoten mit nur dem Langläufer-Gateway verlangen praktisch zwei bis vier GB Puffer unter dem Plan-Deckel; ein sinnvoller Dienst-Speicherlimit-Startwert ist etwa 1,2–1,5× gemessener RSS, während getrennte Jobs eigene Limits oder Profile erhalten. Zweitens: healthcheck.start_period mindestens 1,2–1,5× Ihres Kaltstart-P90, interval meist 20–45s, retries an die erlaubten Minuten für „Blips“ in der On-Call-Guidance. Drittens: aktuelle und vorherige Release als unveränderliches tag/digest, CI setzt IMAGE_TAG inkl. Changelog-Link. Viertens: bei 18789 via SSH-Tunnel die Tabelle loopback, Tunnel, Live-Channel. Fünftens: Config-Verzeichnis im gleichen Rhythmus wie Merges zu Default-Branch-Config, damit nie Image ohne Secrets passt. Teams ohne Zahlen fehlt oft auch Budget, und Docker-Komplexität mutiert heimlich zu Headcount.

Sechstens sollten Sie timeout-Werte für Health-Probes dokumentieren, damit langsame Festplatten nicht fälschlich als Ausfall gewertet werden, und siebte Ergänzung: halten Sie ein kleines Skript bereit, das nach jedem Upgrade dieselben drei Befehle ausführt (compose ps, Probes auf 18789, kurzer Kanal-Ping), damit Junior-On-Call dieselbe Reihenfolge wie Senior nutzt. Wenn diese Schritte nicht im Ticket stehen, wird jedes Rollback zur individuellen Kunstform und verlängert die Mean-Time-to-Recovery ohne technischen Grund.

5. FAQ

Reicht ein TCP-Check auf 18789?

Nur wenn Sie False Positives wollen. Besser HTTP- oder CLI-Test, der zeigt, dass die Initialisierung vollendet ist.

Nach Upgrade Gateway grün, Kanäle rot?

Token- und Channel-Configs zuerst diffen, danach die Sandbox- und Exposure-Checkliste im Hardening, bevor Sie die Upstream-APIs beschuldigen.

Genügt restart: always ohne Health?

Prozesse starten neu, Klarheit nicht. Ohne mehrschichtige Signale drohen Crash-Loops, die Uptime-Monitoren trügerisch grün lassen.

6. Von Docker-Abstraktion zur steuerbaren Mac-Ebene

Container sind gutes Packaging, doch 24/7 Mac-Cloud addieren Volume-, Bridge- und Image-Tag-Flächen ohne Laptop-Demo. Jede Abstraktion heißt mehr Mitternachts-Seiten, sofern sie nicht wie Code versioniert, limitiert und gesichert ist. Ad-hoc fühlt sich schnell an, bis der Ausführende offline und der Host trotzdem der SLA verpflichtet ist. Heim-„Laptop-Server“ fehlen Uplink, Strom, Isolation, Docker ersetzt kein Operationsvertrag. Wenn Führung OpenClaw in unterschreibbarer Form braucht, lohnt sich gemietete VPSMAC M4 Mac-Cloud-Kapazität mit gepinntem Gateway- und Build-Plan eher als Container aufgetürmt auf schwacher Consumer-Hardware. Sie SSH gleich, Modelle und Audit bleiben in einer Linie mit Hardening, Beobachtbarkeit und Exit-137-Playbooks auf der Seite, ohne in endloser docker ps-Archäologie hängen zu bleiben.

Langfristig zählt weniger die Frage „läuft Docker?“ als „kann ein Kollege in zehn Minuten nachvollziehen, welche Compose-Datei, welches Digest und welches Backup zu diesem Host gehören?“. Wenn die Antwort nein ist, haben Sie kein Infrastruktur-Repository, sondern eine Sammlung privater Experimente. Legen Sie deshalb dieselben Review-Regeln wie für Anwendungscode auf Ihre Compose-Dateien an: Pull Requests, zweite Augen für Mount-Pfade und ein monatlicher Drill, der einen kontrollierten Rollback ohne Produktionspanik übt.