Comment auto-héberger OpenClaw en 2026 : Gateway, channels et sécurité

Considérez OpenClaw comme un petit système, et non comme une image Docker. L’objectif côté utilisateur est clair : un Gateway d’assistant IA avec plus de 22 intégrations de channels ; le déploiement n’est acceptable que lorsque vous pouvez appairer un channel de messagerie, envoyer un message entrant, approuver l’expéditeur, invoquer un outil inoffensif et reconnecter la Control UI après le redémarrage d’un Gateway.

Cette distinction permet d’identifier le mode de défaillance auquel les opérateurs sont confrontés après les tests locaux : le Gateway se lie uniquement à loopback ou le proxy ignore les upgrades WebSocket. Elle permet également de définir un plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Choisir la topologie OpenClaw viable la plus simple

La topologie OpenClaw la plus simple et responsable comprend un listener privé sur le port 18789, une route d’ingress et une limite d’état documentée. La seule exigence externe d’OpenClaw est une clé de fournisseur de modèles et au moins un channel appairé. Testez le DNS sortant, TLS et le comportement du fournisseur sans publier un autre service entrant.

Validez la topologie en demandant à un client vierge d’appairer un channel de messagerie, d’envoyer un message entrant, d’approuver l’expéditeur, d’invoquer un outil inoffensif et de reconnecter la Control UI après le redémarrage d’un Gateway. Pendant l’exécution, surveillez les tours d’agents parallèles, la latence du modèle, les processus des browser tools et la taille de l’historique de session accumulé. Le résultat vous indiquera si la prochaine amélioration concerne la mémoire, le stockage, le réseau ou un worker distinct, plutôt que de vous inciter à dimensionner arbitrairement le conteneur.

Diagnostiquer un OpenClaw qui semble sain

Un health check au repos ne renseigne pas beaucoup sur OpenClaw. Surveillez les tours d’agents parallèles, la latence du modèle, les processus des browser tools et la taille de l’historique de session accumulé, puis déclenchez une alerte sur le symptôme rencontré par les utilisateurs : l’échec de l’action « appairer un channel de messagerie, envoyer un message entrant, approuver l’expéditeur, invoquer un outil inoffensif et reconnecter la Control UI après le redémarrage d’un Gateway ». Gardez la liveness locale et légère ; laissez la readiness signaler les migrations ou l’initialisation sans provoquer une restart storm.

La zone de risque lors d’une mise à niveau tient au fait qu’une release peut modifier le schéma de configuration du Gateway, les skills intégrées, les dépendances du navigateur ou les adapters de channel. Lisez les release notes, faites un snapshot de l’état, déployez la version cible sur une copie restaurée et répétez le test d’acceptation. Si le Gateway se lie uniquement à loopback ou si le proxy ignore les upgrades WebSocket, corrélez la requête du client avec le premier log applicatif pertinent au lieu de supprimer l’état ou d’ajouter des redirects à l’aveugle.

Cinq contrôles plus fiables que la santé du conteneur

Le compte rendu de release d’OpenClaw doit contenir des faits, pas un simple « tout semble fonctionner ». Enregistrez le digest de l’image sélectionnée, le checksum de configuration, le hostname public et le résultat horodaté du test suivant : appairer un channel de messagerie, envoyer un message entrant, approuver l’expéditeur, invoquer un outil inoffensif et reconnecter la Control UI après le redémarrage d’un Gateway. Utilisez des données d’exemple non liées à la production afin que le contrôle puisse être exécuté après chaque déploiement.

Prouvez séparément deux événements du cycle de vie. Le remplacement d’un conteneur doit préserver le fonctionnement normal ; une recovery propre doit démontrer que le Gateway restauré peut rouvrir son workspace, reconnaître le channel appairé et utiliser l’authentification du fournisseur sans repasser par l’onboarding. Pendant l’exécution des contrôles, mesurez les tours d’agents parallèles, la latence du modèle, les processus des browser tools et la taille de l’historique de session accumulé, puis conservez le résultat comme enveloppe de référence pour cette version.

Testez également une condition refusée ou invalide : refusez temporairement le chemin de test utilisé par une clé de fournisseur de modèles et par au moins un channel appairé. OpenClaw doit échouer de manière diagnostiquable et ne doit pas écraser un état sain. Rétablissez la condition valide, relancez l’échantillon et joignez les logs pertinents après les avoir expurgés. Ces artefacts fournissent des éléments concrets pour décider d’un futur rollback.

Exécuter la première instance proche de la production

Gardez la première commande OpenClaw suffisamment reproductible pour pouvoir être relue dans une pull request.

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/home/node/.openclaw \
  -e OPENCLAW_GATEWAY_TOKEN=replace-with-a-long-random-value \
  -e OPENCLAW_GATEWAY_BIND=lan \
  ghcr.io/openclaw/openclaw:latest node dist/index.js gateway --bind lan --port 18789

Ne vous fiez pas à latest une fois que de vraies données existent. Consignez le digest utilisé, l’utilisateur du conteneur et les permissions du mount. Suivez le log de l’application pendant un test complet — appairer un channel de messagerie, envoyer un message entrant, approuver l’expéditeur, invoquer un outil inoffensif et reconnecter la Control UI après le redémarrage d’un Gateway — et notez les éventuelles migrations avant d’exposer la route au trafic de production.

Rendre la recovery d’OpenClaw mesurable

Une image de conteneur peut être téléchargée à nouveau ; le workspace OpenClaw, l’état des channels et la configuration, eux, ne le peuvent pas. Montez /home/node/.openclaw avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour prouver que ce chemin est réellement persistant. Inspectez le mount effectif au lieu de faire confiance à un nom de fichier Compose, et vérifiez que l’utilisateur d’exécution peut écrire à l’emplacement attendu par OpenClaw.

Choisissez une politique de rétention et une destination off-host, puis répétez la recovery sans toucher à la production. L’exercice n’est réussi que lorsque le Gateway restauré peut rouvrir son workspace, reconnaître le channel appairé et utiliser l’authentification du fournisseur sans repasser par l’onboarding. Pour les états stockés dans une base de données, associez les snapshots du stockage à des exports cohérents au niveau applicatif, comme indiqué dans recovery point-in-time versus snapshots.

Tester OpenClaw depuis l’extérieur du serveur

Considérez l’URL externe d’OpenClaw comme une configuration qui doit survivre aux redeploys. Commencez par configurer l’adresse publique du Gateway et un proxy compatible avec WebSocket ; routez ensuite le hostname vers le port 18789 en conservant l’host et le scheme d’origine.

La checklist d’accessibilité du déploiement peut prouver que les requêtes entrent bien dans le conteneur. Au-delà de ce point, le problème connu — le Gateway se lie uniquement à loopback ou le proxy ignore les upgrades WebSocket — doit être recherché dans OpenClaw, son état ou sa charge de travail, et non dans l’automatisation des certificats.

Réduire les privilèges détenus par OpenClaw

Les identifiants de bootstrap sont temporaires ; le modèle de confiance est permanent. Avec OpenClaw, vérifiez notamment que le token du Gateway n’est pas laissé vide et qu’aucun appairage de channel inconnu n’est approuvé. Utilisez une trust boundary par Gateway, examinez chaque appairage DM et sandboxez les tools qui accèdent à l’hôte.

Traitez OPENCLAW_GATEWAY_TOKEN selon son rôle dans OpenClaw : gardez les valeurs sensibles hors de Git, documentez les effets d’une rotation et ne remplacez jamais un exemple public en production. Exécutez l’image sans capabilities Linux superflues et n’exposez que la route applicative publique. Gardez l’activité des administrateurs visible sans enregistrer les valeurs secrètes.

Intégrer OpenClaw au cycle de vie de Dockup

La couche plateforme d’OpenClaw comprend le port 18789, l’ingress, TLS, la configuration d’exécution, le stockage et l’accessibilité des dépendances. Dockup peut reproduire ces éléments pour sa propre infrastructure ou pour un serveur connecté par le client.

L’opérateur termine ensuite la couche produit : configurez l’adresse publique du Gateway et un proxy compatible avec WebSocket ; appliquez cette règle d’accès — utilisez une trust boundary par Gateway, examinez chaque appairage DM et sandboxez les tools qui accèdent à l’hôte ; puis exécutez « appairer un channel de messagerie, envoyer un message entrant, approuver l’expéditeur, invoquer un outil inoffensif et reconnecter la Control UI après le redémarrage d’un Gateway ». Enregistrer ce test avec le déploiement évite de confondre le provisioning automatisé avec la readiness de l’application.

Foire aux questions

De quoi OpenClaw a-t-il besoin pour un déploiement en production ?

Routez le conteneur OpenClaw sur le port 18789 via une origine HTTPS unique. L’exigence de livraison externe est une clé de fournisseur de modèles et au moins un channel appairé. Ne considérez pas OpenClaw comme prêt tant que vous ne pouvez pas appairer un channel de messagerie, envoyer un message entrant, approuver l’expéditeur, invoquer un outil inoffensif et reconnecter la Control UI après le redémarrage d’un Gateway.

Quelles données OpenClaw doivent figurer dans une sauvegarde ?

Conservez /home/node/.openclaw et incluez le workspace OpenClaw, l’état des channels et la configuration dans le même recovery manifest. Une restauration propre d’OpenClaw n’est réussie que lorsque le Gateway restauré peut rouvrir son workspace, reconnaître le channel appairé et utiliser l’authentification du fournisseur sans repasser par l’onboarding.

OpenClaw nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique d’OpenClaw et conservez le port 18789 sur la route interne. Appliquez correctement le paramètre OpenClaw : configurez l’adresse publique du Gateway et un proxy compatible avec WebSocket. Pour OpenClaw, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent du client sensible à l’origine.

Comment tester une mise à niveau d’OpenClaw ?

Restaurez l’état actuel d’OpenClaw dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car une release peut modifier le schéma de configuration du Gateway, les skills intégrées, les dépendances du navigateur ou les adapters de channel. Conservez l’image OpenClaw précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.