mem_limit · Healthcheck und start_period · Restart-Backoff · json-file-Rotation und Plattenkontrolle
Teams, die OpenClaw auf einem VPS 24/7 betreiben, kollidieren oft mit drei Mustern: ein zu kurzer healthcheck tötet den Kaltstart des Gateways, ein mem_limit unter WASM-Spitzen erzeugt Exit 137, und Standard-json-file-Logs füllen die Root-Partition. Dieser Artikel definiert die kleinste Differenzmenge zwischen Dev- und Prod-Compose, eine sechsstufige reproduzierbare Baseline und wann Restart-Jitter menschliches Stoppen erfordert, mit Querverweisen auf den Exit-137- und allowedOrigins-Leitfaden sowie den Image-Pin- und Rollback-Text.
Entwicklungsstacks verzichten oft auf Caps, verkürzen Health-Fenster und loggen auf die Konsole. In unbeaufsichtigten Umgebungen entsteht daraus ein Restart-Sturm: Unhealthy bevor das Gateway lauscht, restart: always im Sekundentakt, und Logdateien verbrauchen Inodes oder Quota schneller als Backoff hilft.
OpenClaw hebt den RSS beim ersten Build und Modellladen. mem_limit nur nach Mittelwerten im Steady-State lädt den OOM-Killer nachts. Jede Einstellung soll sich auf docker inspect oder Hostmetriken im Ticket abbilden lassen.
start_period zu kurz: Proben scheitern vor Port 18789, die Oberfläche zeigt Endlosschleifen.
mem_limit vs. Spitzen: Erste WASM- oder Dependency-Spikes überschreiten das cgroup-Limit mit Code 137 und dünnen App-Logs.
Unbegrenztes json-file: Callbacks und Debug-Logs füllen die Root-Partition in heißen PR-Phasen.
Restart ohne Backoff: Fehlkonfiguration plus falsches Unhealthy hungern CPU und IO gleichzeitig aus.
Dev-Binds in Prod: Hot-Reload-Bäume und lockere Rechte vergrößern die Geheimnisfläche.
Ausgangspunkt sind zwei Overrides im selben Repo: docker-compose.yml für gemeinsame Dienste, docker-compose.prod.yml nur für Prod-Deltas, um Copy-Paste-Drift zu vermeiden.
| Dimension | Dev-Default | Prod-Baseline |
|---|---|---|
| Speicher | Kein Cap oder nur Hostweit | Explizites mem_limit mit Kaltreserve; Abgleich mit Exit-137-Text |
| Healthcheck | Kurzes Intervall, kein start_period | start_period deckt Kaltstart; retries und timeout passend zur SLA-Sprache |
| Restart | unless-stopped oder fehlt | on-failure oder begrenztes always plus Host-Alarme |
| Log-Treiber | json-file-Defaults | max-size + max-file; kein manuelles truncate |
| Volumes und Secrets | Source-Binds | Config read-only; Secrets aus env_file oder Docker Secret, nicht in Image-Layern |
Jede Prod-only-Zeile braucht ein Grafana-Feld oder Ticketfeld, sonst bleibt es Wunschdenken.
Die Schritte setzen Images voraus, die dem Pinning-Playbook folgen; mit :latest zuerst auf Staging einen vollen Kaltstart messen, dann das Prod-Override setzen.
Spitzen samplen: Auf Staging docker stats --no-stream und ps im Container, RSS zehn Minuten um den ersten Ready herum.
mem_limit schreiben: Spitze mit vereinbartem Sicherheitsfaktor; Swap-Richtlinie auf dem Host dokumentieren.
Readiness definieren: HTTP oder CMD auf derselben Loopback-Adresse wie das Gateway.
start_period setzen: Erste Dependency-Installation und WASM-Compile abdecken; p95 des Kaltstarts statt Mittelwert.
json-file straffen: Pro Dienst logging mit max-size und max-file; Wachstumsrate des Log-Verzeichnisses alarmieren.
Restarts üben: Einen fehlgeschlagenen Probe injizieren und Intervalle, Backoff und Paging gegen das Runbook prüfen.
services:
openclaw:
mem_limit: "2g"
logging:
driver: json-file
options:
max-size: "20m"
max-file: "5"
healthcheck:
test: ["CMD", "curl", "-f", "http://127.0.0.1:18789/health"]
interval: 30s
timeout: 5s
retries: 5
start_period: 180s
restart: on-failure:5
Hinweis: Health-Pfade müssen zum Image passen; nur TCP verfügbar, dann CMD-SHELL mit nc, aber höheres Fehlalarm-Risiko gegenüber HTTP dokumentieren.
Überschreiten docker events-Restarts pro fünf Minuten das Runbook, zuerst Fehlkonfiguration und falsches Unhealthy prüfen, nicht nur RAM. Blindes Neustarten verstärkt Log-Schreibverstärkung.
Ist Root schreibgeschützt, Traffic abziehen oder Reverse Proxy stoppen, dann Platz nach dem Exit-137-Artikel freimachen; ohne Platten-Gesundheit kein erzwungenes compose up -d über Daten-Volumes.
Achtung: Niedrigeres max-file rotiert Hot-Logs schneller weg; längere Aufbewahrung braucht Objektspeicher oder Log-Host statt unbegrenzter Dateigröße.
Releases einfrieren: Pipeline-Eingang schließen, wenn Stürme über Schwellen liegen.
Zustand sichern: Health- und OOM-Ausschnitte aus inspect plus letzte zweihundert Logzeilen.
Compose zurücksetzen: Vorheriges Override wiederherstellen und Repro-Paket für Postmortem behalten.
Die Werte sind Charter- und On-Call-Startpunkte; ersetzen Sie sie durch echte Kaltstart-Histogramme und Plattenwachstum. Nicht als Kunden-SLA verkaufen.
Teilt sich der VPS mit Reverse Proxy oder kleiner Datenbank, konkurrieren mem_limit und Log-IO mit Nachbarn; Reviews sollten Container-RSS, freien Hostspeicher und Schreiblatenz auf einem Board verlangen.
| Host-Form | Logging-Start | Bezug zu Image-Pins |
|---|---|---|
| 2 vCPU / 4 GB | Kleineres max-size, kürzere Retention, aggressiveres Ship | Digest-Pin verhindert Überraschungs-Kaltstarts |
| 4 vCPU / 8 GB | max-file etwas lockern, Rotation nie abschalten | Staging und Prod mit verschiedenen Tags, gleicher Digest-Check |
| Gemischte Last | Datenplatte oder Log-Volume getrennt von DB-Partition | Upgrade-Fenster an Pin-Artikel koppeln |
OpenClaw auf einem kleinen Wegwerf-VPS unterfinanziert Speicher, Platte und Secret-Rotation gleichzeitig; Bare-Metal-DIY tauscht das gegen Strom- und Leitungs-SLA-Risiko.
Teams, die vertraglich gebundene Rechenleistung, wählbare Regionen und prüfbare Bandbreite brauchen und Gateway plus Kanäle 24/7 beobachtbar halten wollen, profitieren oft von gemieteten Cloud-Mac-Minis; VpsMesh Mac Mini Cloud-Miete fasst Compose-Baseline, Proxy und Backup in einer Kapazitätsgeschichte zusammen.
Nutzer und PATH der Probe prüfen sowie start_period für Kaltstart; bei Proxy/Loopback den allowedOrigins- und Reverse-Proxy-Artikel vergleichen.
Zuerst dmesg und Exit-Code, dann Peaks neu messen, dann Limit ändern; Details im Exit-137-Artikel. Pläne auf der Preisseite.
Hot-Retention lokal kürzer; längere Fristen zentral auslagern. Richtlinien im Hilfezentrum.