OpenClaw Docker sur VPS en 2026
Exit 137 et erreurs Control UI : tableau de correspondance

Ressources d’abord : free -h, mem_limit et la première compilation WASM « bloquée »

Au premier démarrage du Gateway OpenClaw dans le conteneur, CPU élevé mais port tardif correspond souvent à la phase WASM, pas à un interblocage. Comme dans l’article v2026.4 : si la mémoire disponible sur l’hôte et mem_limit sont trop justes, l’OOM Linux donne Exit 137, parfois sans message applicatif clair dans les journaux.

1. 01

   Hôte : exécuter free -h ; un tampon durable nettement inférieur à environ 1,5 à 2 Gio augmente le risque 137 ; sans swap, encore plus.

2. 02

   Compose : définir mem_limit: 2g ou plus et éviter la concurrence mémoire avec d’autres services lourds sur la même machine.

3. 03

   Première fenêtre : après un démarrage à froid, attendre 3 à 7 minutes avant de conclure à l’échec ; docker logs -f pour voir si la chaîne de compilation continue.

4. 04

   Sonde de santé : healthcheck.start_period au moins 360 s pour que compose ne tue pas avant la fin du WASM.

5. 05

   Éviter les faux positifs : ne pas enchaîner les docker compose restart dans cette fenêtre ; chaque redémarrage relance le pic à froid.

Ces cinq points en page un du runbook « OpenClaw sur VPS » réduisent les tickets du type « j’ai suivi le tutoriel, ça ne monte pas ». Dépannage Gateway plus détaillé : article d’exécution.

Control UI, liaison 127.0.0.1 et reverse proxy : allowedOrigins et options d’en-tête Host

Exposer 18789 sur Internet depuis le VPS est une erreur fréquente. L’article d’installation recommande le conteneur en loopback uniquement, TLS terminé par Caddy ou Nginx sur 443. Une erreur non-loopback dans la Control UI signifie que l’origine du navigateur et les origines autorisées par la passerelle divergent, pas que « Docker est cassé ».

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

Squelette compose reproductible, dix contrôles avant mise en ligne et portable à la place du serveur

Trois intervalles de vérification typiques : remplissez-les avec les métriques réelles de votre hôte et ajoutez-les au README pour éviter les pièges répétés.

• Budget premier démarrage : après démarrage à froid, attendre au moins 3 à 7 minutes avant d’ouvrir un ticket ; redémarrer avant trois minutes amplifie le 137.
• Niveau mémoire : viser durablement plus de 2 Gio de marge disponible sur l’hôte par instance ; en dessous, monter en capacité plutôt qu’empiler les fonctions.
• Rotation des journaux : limiter json-file Docker par exemple à ≤ 10 Mio par fichier, ≤ 3 fichiers pour éviter un disque plein comme second incident.

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

Faire tourner le Gateway en continu sur un portable subit veille, capot fermé et montée instable ; le seul accès résidentiel offre rarement un SLA mesurable. Un Mac mini cloud facturé à l’usage convient mieux aux flux hybrides OpenClaw sur VPS avec besoins graphiques ou Xcode.

Pour un gateway Docker stable et les étapes lourdes sur un macOS contractuel, l’achat et la synchronisation multi-sites coûtent souvent plus que la location. Pour des nœuds vérifiables 7×24 et des tailles flexibles, la location Mac mini cloud VpsMesh est souvent préférable : dessinez la séparation VPS OpenClaw et Mac distant dédié, puis validez la capacité avec les tarifs de location et la page de commande, plus simple à contractualiser que des engagements oraux.