OpenClaw en production : Docker ou npm local ?

Docker Compose pour des runtimes reproductibles et l’isolation d’équipe ; npm local ou installateurs pour debugger vite au niveau source. Beaucoup d’équipes développent en local et exposent le Gateway en conteneur en production.

Le Gateway ne démarre pas—que vérifier en premier ?

Conflits de ports, chemins de health check, HTTPS sortant du conteneur vers les fournisseurs de modèles, droits des volumes d’état. Alignez les valeurs par défaut sur la doc du tag d’image figé.

Comment revenir en arrière après une mauvaise mise à jour ?

Noter le digest d’image et la révision compose, arrêter le Gateway, restaurer les snapshots de volume, relancer la stack avec le tag précédent. Évitez les pulls latest anonymes en production.

OpenClaw 2026 production : Docker, Gateway permanent, dépannage et rollback

Lecture ~16 min · MACCOME

Installer OpenClaw par plate-forme suffit en labo ; la production exige un Gateway 24/7, des volumes Docker sains et des mises à jour sans perte d’état. Ce guide s’adresse aux équipes qui veulent des agents « contratables » : checklist prévol, arbitrage Docker/npm, schémas Compose pour processus permanents, tableau de tri des symptômes, et ordre token, logs, sauvegarde, rollback. À lire avec le guide Windows/macOS/Linux ; pour une sortie réseau stable, voir aussi l’exécution sur Mac distant.

Six pièges entre « ça tourne » et « c’est de garde »

Un seul laptop de dev comme Gateway : veille, mises à jour et pop-ups GUI cassent les sessions ; l’incident coûte souvent plus qu’un nœud dédié.
Suivre latest anonymement : l’amont change ports ou schémas de config la nuit—les pulls CI deviennent des releases silencieuses.
Luttes d’UID sur volumes : root vs utilisateur conteneur sur l’état apparaît comme erreurs SQLite/I/O floues.
Sortie réseau mal alignée avec les fournisseurs : proxy d’entreprise ou blocage régional arrive en timeout, pas en 403 net.
Tokens Gateway en clair dans Git : mélanger secrets CI et laptop augmente risque offboarding/fork.
Pas de rollback hors « réinstaller » : pas de RTO crédible ni reprise reproductible.

Si Windows/macOS/Linux reste flou, lisez d’abord installation OpenClaw et choix de plateforme, puis revenez ici pour la conteneurisation.

Prévol : Node, mémoire, clés, egress (15 minutes)

Les installateurs communautaires et images Docker évoluent ; valeurs indicatives—vérifiez avec votre release figée.

Runtime : beaucoup de docs 2026 partent de Node 20 LTS ou 22 ; l’image embarque souvent un runtime testé, l’hôte demande Docker Engine et plugin Compose à jour.
Mémoire : prévoir 2–4 Go de limite conteneur pour un Gateway léger ; marge si canaux parallèles ou modèles locaux.
Secrets : clés minimales séparées fournisseurs vs auth gateway ; rotation conjointe du secret d’orchestration et des fichiers montés.
Egress : sonder les API fournisseurs depuis le même chemin réseau que le Gateway ; valider racines d’entreprise et proxies.

Dimension	Docker Compose (orienté prod)	npm local / installateur (itération)
Reproductibilité	Élevée : l’image fige les dépendances	Moyenne : dérive Node/OS globale
Isolation / multi-instance	Facile : réseaux, volumes, limites	Plus dur : collisions de ports/config
Rythme de mise à jour	Contrôlé : tag ou digest	Rapide : suivre upstream main
Debug	`exec` ou bind-mount sources	Débogueurs et breakpoints directs
Coût opérationnel	Pulls, sauvegardes volumes, hygiène compose	Pollution hôte, cohérence des démons

bash

# Flux indicatif—noms de services selon la doc du tag figé
git clone https://github.com/openclaw/openclaw.git && cd openclaw
# si fourni : bash docker-setup.sh
# docker compose pull
# docker compose run --rm <cli-service> onboard
# docker compose up -d <gateway-service>
# docker compose ps
# curl -fsS http://127.0.0.1:<health-port>/health || echo "voir la doc pour le chemin"

warning

Attention : noms de services, variables d’environnement et chemins health changent par release—les snippets sont des motifs ; validez avec le tag figé.

Six étapes pour garder le Gateway résident sur Compose

Figez les versions : tags ou digests dans compose ; interdire le drift anonyme en prod.
Séparez les volumes : config, état, logs ; RPO de sauvegarde par classe de volume.
Dépendances & restart : restart: unless-stopped gère les crashs, pas les mauvaises configs—ajoutez des health checks.
Health checks : sondes HTTP/TCP du fournisseur ; alignez LB/watchdog.
Observabilité : au moins un journal indexable (stdout ou fichier) pour les alertes.
Change control : chaque changement port/volume/env avec diff et tag de rollback—pas d’« infra orale ».

Symptôme	Cause probable	Actions
Gateway quitte tout de suite	Env manquante, entrypoint modifié	Lire les logs compose ; comparer clés requises aux notes de version
Port occupé	Processus obsolète ou conflit hôte	`ss -lntp` ; remapper ou arrêter le propriétaire
Timeouts modèle	Egress, proxy, DNS, région	curl depuis le conteneur ; certificats/proxy
SQLite / verrous	Double écriture, UID incohérent	Un seul writer principal ; corriger les droits volume

Durcissement prod : tokens, exposition, sauvegardes, ordre de rollback

Injectez les tokens Gateway via secrets—pas dans les couches d’image. HTTP public : terminaison TLS et limitation de débit en frontal ; même en interne, anticipez le mouvement latéral.

Ordre de rollback : ① noter digest + révision compose ② arrêter le Gateway ③ restaurer snapshot volume ④ docker compose up -d avec le tag précédent ⑤ health checks + une sonde de bout en bout.

Trois critères mesurables pour revue ops

Cold start → healthy : P95 de compose up à sonde OK ; si ça saute, pulls et I/O volume avant d’acheter du CPU.
Mix d’erreurs vs latence : séparer 4xx/5xx et timeouts TCP pour ne pas confondre throttling et Gateway mort.
Drills de restauration : chaque trimestre, restaurer les volumes sur un hôte isolé et booter le Gateway—publier un RTO chiffré.

Quand héberger le Gateway sur un Mac distant toujours allumé

Les équipes qui mélangent toolchain Apple (Xcode, Simulator, signature) et agents gagnent à sortir le Gateway des laptops personnels vers un Mac dédié facturable 24/7. SSH par défaut pour démons et logs, VNC seulement pour triage GUI—voir guide SSH vs VNC.

Pourquoi les seuls laptops font rarement de bons Gateways de prod

Politiques de veille, mises à jour OS désordonnées, ports exposés quand plusieurs personnes déboguent. Conteneurs sans digest figé masquent la dérive hôte derrière une fausse reproductibilité.

Modèle durable : runtimes figés par Compose sur Mac distants dédiés (ou bare metal équivalent) comme plan d’exécution. Les cloud Mac MACCOME offrent de l’Apple Silicon multi-régions avec conditions de location claires—utile si OpenClaw partage l’hôte avec l’automatisation iOS/macOS. Comparez les régions avec le guide multi-régions et les tarifs publics, puis commandez Singapour, Tokyo, Séoul, Hong Kong, US Est ou US Ouest.

Aide sessions : centre d’aide.

FAQ

Docker ou npm en production ?

Compose pour la reproductibilité ; npm local pour debugger en profondeur. Commencez par installation & choix de plateforme.

Gateway en panne—premiers réflexes ?

Ports, chemins health, egress conteneur, droits volumes. Centre d’aide pour SSH/VNC et connectivité.

Lien avec l’accès Mac distant ?

SSH d’abord, VNC si besoin—guide SSH/VNC Mac distant.

Comparer régions et tarifs ?

Tableau multi-régions + tarifs.