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.
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.
- Container-Status statt Readiness beobachten:
runningohne Listener auf18789oder 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. - 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-limitnur dem RSS des Gateways im Leerlauf entspricht, ist der erstecompose pull, der einen Rebuild triggert, jener mit OOM. Die Geschichte folgt dem Exit-137-Leitfaden, erscheint aber im Upgrade statt beim ersten Boot. lateststatt 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.
| Bedarf | Einzel-Container ad hoc | Compose plus Mac-Cloud | Notiz |
|---|---|---|---|
| Dokumentierte Readiness | Manuelle Curls | healthcheck und geordnete depends_on | Proben müssen echte App-Readiness prüfen, kein nacktes TCP |
| Build- vs. Laufzeit-Speicher trennen | Ein Limit für alles | Profile oder Dienste mit höherer Build-Deckelung | Reduziert Exit 137 beim Upgrade |
| Auditierbare Upgrades | Schwebendes latest | Unveränderliches tag@digest und Changelog | Rollback: Tag umschwenken, tar einspielen |
| Security-Fläche | Bind-Mounts und Bridge leicht vergessbar | Netz und read-only in Git | mit Token- und Sandbox-Hardening kombinieren |
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
- Baseline einfrieren: Docker-Engine- und Compose-Minor, RAM-Headroom, Lage der Layer relativ Root-Volume;
df -hins interne Wiki. - Minimales
compose.yaml:restart, explizite Host-Pfade für Volumes, UID-Ausrichtung, damit das Gateway nicht permanentPermission deniedkämpft. - Healthchecks: Die Sonde muss Gateway-Bereitschaft belegen, nicht nur TCP offen.
intervalüber Kaltstart-P95,start_periodgroßzügig für neue Major-Images. - Ressourcen: CPU- und Speicherlimits pro Dienst; Build- oder Migrationsjobs nie dieselbe cgroup wie den Langläufer.
- Pre-Upgrade-Backup: env und Konfigverzeichnis
taren,docker image ls --digestsins Ticket. Automatisierung schlägt Kopfnotiz. - Upgrade:
docker compose pull, danachup -dmit offenem Ticket; Smoke fail → vorherigen Tag in einem Change set und tar wiederherstellen.docker compose psneben curl/CLI auf18789. - Post-Rollback: Kanal-Smoke, Modellliste, JSONL auf Reconnect-Loops, dann offene Punkte aus Hardening zu Token-Scope und Sandboxes.
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.