OpenClaw Docker auf VPS 2026
Exit 137 und Control-UI-Fehler im Überblick

Ressourcen zuerst: free -h, mem_limit und das erste WASM-Build („scheinbar hängend“)

Beim ersten Start des OpenClaw Gateway im Container ist hohe CPU, aber der Port öffnet spät oft die WASM-Sandbox-Kompilierung, kein Deadlock. Wie in v2026.4 Installationsartikel beschrieben: sind freier RAM auf dem Host und mem_limit zu knapp, liefert Linux OOM oft Exit 137, ohne klare Anwendungsmeldung in den Logs.

1. 01

   Host: Auf dem Host free -h ausführen; dauerhaft weniger als etwa 1,5–2 GiB freier Puffer erhöht das 137-Risiko; ohne Swap noch stärker.

2. 02

   Compose: mem_limit: 2g oder höher setzen und schwere Konkurrenten auf derselben Maschine vermeiden.

3. 03

   Erstes Fenster: Nach Kaltstart 3–7 Minuten warten, bevor ein Fehler angenommen wird; docker logs -f zeigt, ob noch kompiliert wird.

4. 04

   Healthcheck: healthcheck.start_period mindestens 360s, damit compose nicht vor Ende des WASM neu startet.

5. 05

   Fehldiagnose vermeiden: Während des ersten Fensters nicht wiederholt docker compose restart – jeder Neustart triggert den Kaltstart-Spitzenbedarf erneut.

Diese fünf Punkte auf Seite eins des Runbooks „OpenClaw auf VPS“ reduzieren Tickets vom Typ „Tutorial befolgt, startet nicht“. Mehrstufiges Gateway-Troubleshooting: Laufzeit-Artikel.

Control UI, 127.0.0.1 und Reverse Proxy: allowedOrigins und Host-Header-Optionen

18789 öffentlich auf dem VPS zu exponieren ist ein häufiger Fehler. Installationsartikel: Container nur an Loopback, TLS-Terminierung mit Caddy oder Nginx auf 443. non-loopback in der Control UI bedeutet: Browser-Origin und erlaubte Origins am Gateway stimmen nicht – nicht „Docker defekt“.

{
  "gateway": {
    "mode": "local",
    "controlUi": {
      "allowedOrigins": ["https://openclaw.example.com"]
    }
  }
}

Compose-Skelett, zehn Go-Live-Checks und Notebook statt Server

Drei typische Prüfintervalle – mit echten Monitoring-Werten Ihres Hosts füllen und ins README, damit neue Teammitglieder dieselben Fallen vermeiden.

• Erster Start: Nach Kaltstart mindestens 3–7 Minuten warten, bevor ein Ticket geöffnet wird; unter drei Minuten wiederholt neu starten verstärkt 137.
• RAM: Pro Instanz dauerhaft etwa 2 GiB freier Puffer auf dem Host anstreben; darunter eher skalieren als Features stapeln.
• Log-Rotation: Docker json-file z. B. ≤10 MiB pro Datei, ≤3 Dateien, damit die Platte nicht als zweite Ausfallursache wird.

services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:latest
    restart: unless-stopped
    mem_limit: 2g
    ports:
      - "127.0.0.1:18789:18789"
    volumes:
      - ${HOME}/.openclaw:/home/node/.openclaw
    env_file:
      - .env
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:18789/health"]
      interval: 60s
      timeout: 15s
      retries: 5
      start_period: 360s

Gateway dauerhaft auf dem Notebook leidet unter Ruhezustand, zugeklapptem Deckel und instabilem Uplink; reines Heim-DSL liefert selten messbares SLA. Ein Mac mini in der Cloud mit nutzungsbasierter Abrechnung passt besser zu gemischten Workflows mit VPS-OpenClaw und grafischer oder Xcode-Seite.

Soll Docker-Gateway stabil online bleiben und schwere Builds oder Geräteschritte auf vertraglich fassbarer macOS-Umgebung laufen, sind Anschaffung und Multi-Standort-Sync oft teurer als Miete. Für 7×24 prüfbare Knoten und flexible Größen ist VpsMesh Mac mini Cloud häufig die bessere Option: Architektur mit VPS-OpenClaw und dediziertem Remote-Mac skizzieren, Kapazität mit Mietpreisen und Bestellseite belegen – das lässt sich leichter vertraglich absichern als mündliche Zusagen.