OpenClaw en production : checklist complète

Introduction

Un déploiement openclaw production n’est pas un service Python exposant un endpoint fictif : c’est un Gateway Node/TypeScript supervisé, avec sa configuration, son état, ses workspaces, ses canaux et ses automatisations. Cette approche est utile dès que l’assistant agit sur des comptes ou doit rester disponible. Elle convient à un administrateur ayant déjà installé OpenClaw sur un VPS et qui doit prouver la santé, la restauration et le rollback. Pour un essai local sans canal ni tâche critique, restez sur une approche plus simple. Ce guide fournit les contrôles propres au produit actuel.

Résumé rapide

• Gardez le Gateway sur loopback et accédez-y par Tailscale ou tunnel SSH.
• Sauvegardez la configuration ~/.openclaw/openclaw.json, l’état et chaque workspace.
• Supervisez avec openclaw gateway status --require-rpc, openclaw health --json et les probes de canaux.
• Épinglez la version, testez la mise à jour et documentez le rollback.
• Auditez les outils, les accès inter-agents et les automations avant ouverture aux utilisateurs.
• Après chaque changement, faites un test réel depuis un canal autorisé.

Ce qui distingue vraiment la production

OpenClaw est un assistant IA personnel self-hosted. Un Gateway toujours actif constitue la source de vérité pour les sessions, le routage, les connexions aux canaux, le tableau de bord et le scheduler. Sa configuration canonique est un fichier JSON5 facultatif situé à ~/.openclaw/openclaw.json. Si le fichier est absent, des valeurs sûres s’appliquent ; s’il contient une clé inconnue ou un type invalide, la validation stricte peut empêcher le démarrage.

La disponibilité du processus ne suffit donc pas. Une production saine exige quatre preuves distinctes : le service est lancé, le RPC répond, les canaux sont réellement connectés et un tour d’agent peut utiliser seulement les outils attendus. Une ligne de session récente ne prouve pas la connectivité d’un canal.

L’état fonctionnel dépasse le fichier de configuration. Les workspaces contiennent instructions, fichiers et skills ; les répertoires d’agent contiennent profils d’authentification et historique SQLite. Une sauvegarde doit respecter ces périmètres sans copier des secrets dans un dépôt public. Pour les options de configuration, référez-vous au guide Configurer OpenClaw.

Enfin, un Gateway correspond à une frontière de confiance. Il peut servir plusieurs agents et plusieurs comptes de canaux, mais il n’isole pas des utilisateurs adversariaux. Pour des groupes qui ne se font pas confiance, séparez Gateway, credentials et idéalement utilisateur système ou hôte.

Checklist pour déployer OpenClaw en production

1. Figer l’installation et la configuration

Relevez l’état avant toute modification :

openclaw --version
openclaw gateway status --json
openclaw config get gateway
openclaw agents list --bindings
openclaw automations list

Versionnez une copie expurgée de la configuration et les fichiers d’instructions non secrets. Ne placez jamais les tokens, cookies, profils OAuth ou bases de sessions dans Git. La bonne structure mentale est la suivante :

~/.openclaw/
├── openclaw.json          # configuration canonique
├── workspace/             # instructions, skills et fichiers du défaut
├── agents/<agentId>/      # état et sessions propres à chaque agent
└── logs/                  # journaux et diagnostics

Évitez un lien symbolique pour openclaw.json : les écritures atomiques d’OpenClaw remplacent le chemin, ce qui peut produire un comportement inattendu. Pour une configuration ailleurs, utilisez OPENCLAW_CONFIG_PATH.

Checklist :

• version OpenClaw notée et méthode d’installation documentée ;
• configuration valide avec openclaw doctor ;
• secrets exclus du dépôt et des logs ;
• état et workspaces inclus dans une sauvegarde chiffrée ;
• image ou version précédente encore récupérable.

2. Installer un seul superviseur

La voie supportée installe le daemon pendant l’onboarding :

openclaw onboard --install-daemon
openclaw gateway status

Sur Linux, OpenClaw utilise un service systemd utilisateur. Pour qu’il reste actif après déconnexion sur un serveur headless :

sudo loginctl enable-linger "$(whoami)"
systemctl --user enable --now openclaw-gateway.service

Le nom exact peut inclure un profil. Ne superposez pas un service systemd maison, un conteneur et le daemon OpenClaw sur le même port. openclaw gateway status --deep aide à repérer des services concurrents. Pour redémarrer, utilisez openclaw gateway restart, plutôt qu’un enchaînement stop/start improvisé.

Avec Docker, utilisez le script et l’image officiels, des volumes persistants et un tag de version. Docker est une variante de déploiement, pas un prérequis d’OpenClaw.

3. Vérifier liveness, readiness et canaux

N’inventez pas un endpoint /health ou /api/health. Les contrôles documentés passent par la CLI et le RPC du Gateway :

openclaw gateway status
openclaw gateway status --require-rpc
openclaw status --deep
openclaw health --json
openclaw channels status --probe

Une baseline saine affiche un runtime actif, une probe de connectivité correcte et les capacités attendues. Pour une surveillance automatisée, parsez le JSON et alertez sur le code de sortie ou les champs de santé. Gardez aussi openclaw logs --follow à portée de main pour le diagnostic.

L’ordre de triage recommandé est : service, RPC, santé globale, probe du canal, puis tour d’agent. Cette séquence évite de confondre un problème Telegram ou WhatsApp avec une panne du Gateway.

4. Fermer l’exposition réseau

Le port par défaut est 18789, avec un bind loopback. Conservez ce réglage et accédez au tableau de bord par Tailscale ou SSH :

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

Un bind non local nécessite une authentification explicite par gateway.auth.token, gateway.auth.password ou proxy de confiance. Si un reverse proxy est indispensable, déclarez ses adresses précisément, remplacez proprement les en-têtes transférés et configurez les origines de la Control UI. Consultez aussi Sécuriser OpenClaw.

Exécutez l’audit avant chaque élargissement d’accès :

openclaw security audit --deep

5. Réduire les permissions par agent

Un agent possède son workspace, son état et ses sessions, mais le workspace n’est pas un sandbox. Sans sandboxing, un chemin absolu peut atteindre l’hôte. Pour les agents recevant du contenu non fiable, activez une sandbox et accordez seulement les outils nécessaires.

La visibilité des sessions et les communications inter-agents méritent une décision explicite. Les valeurs par défaut conviennent à un propriétaire unique, pas à des niveaux de confiance divergents. Un profil restrictif peut notamment fixer la visibilité à l’agent et désactiver les handoffs :

{
  tools: {
    sessions: { visibility: "agent" },
    agentToAgent: { enabled: false },
    elevated: { enabled: false },
  },
}

Validez les champs exacts avec le schéma de votre version avant d’éditer. Les allowlists de canaux, les règles de mention et les restrictions d’outils doivent être testées depuis un compte autorisé et un compte non autorisé.

6. Sauvegarder puis restaurer

Sauvegardez au minimum la configuration réelle, les workspaces, l’état par agent et les éventuels répertoires de skills gérés. Chiffrez la copie et séparez-la du VPS. Un snapshot fournisseur accélère le rollback machine, mais une sauvegarde indépendante protège d’une suppression de compte ou d’une corruption propagée.

Le test de restauration doit recréer une VM, installer la version compatible, restaurer les chemins avec leurs permissions, puis vérifier :

openclaw doctor
openclaw gateway status --require-rpc
openclaw agents list --bindings
openclaw automations list
openclaw channels status --probe

Une archive jamais restaurée n’est pas une preuve de reprise.

7. Mettre à jour avec un rollback réel

Selon votre méthode d’installation, utilisez le canal stable ou une image officielle épinglée. Avant changement : lisez les notes de version, sauvegardez, notez la version et capturez l’état des probes. Testez si possible avec un profil et un état séparés.

Après mise à jour :

openclaw doctor
openclaw gateway restart
openclaw gateway status --require-rpc
openclaw health --json
openclaw channels status --probe
openclaw security audit --deep

Le rollback doit restaurer le couple version + état compatible. Avec Docker, repointez vers le tag précédent et restaurez les volumes seulement si une migration les a rendus incompatibles. Avec npm, gardez la version exacte précédente et la commande de réinstallation. Fixez un seuil : si RPC, canal ou tour critique échoue après quelques minutes de diagnostic, revenez à N-1.

8. Tester les fonctions qui produisent de la valeur

Terminez par un test de fumée fonctionnel. Envoyez un message depuis chaque canal critique, invoquez un skill important, confirmez une action sans effet destructif et inspectez les automations :

openclaw skills list
openclaw agent --agent ops --message "Résume l’état du service" --json
openclaw automations list
openclaw automations runs --id <job-id>

Pour une tâche planifiée, le Gateway doit rester actif : les automations tournent dans son processus et persistent dans l’état SQLite. Vérifiez le statut de la dernière exécution et la livraison, pas seulement l’existence du job.

Exemple concret

Une équipe exploite un agent ops relié à Slack pour résumer les incidents. Avant une mise à jour, l’administrateur exporte une sauvegarde chiffrée de ~/.openclaw, note la version, vérifie les bindings et conserve la version N-1. Le Gateway reste sur loopback, accessible par Tailscale ; Slack est le seul canal de production.

Le pré-contrôle enregistre les résultats de gateway status --json, health --json et channels status --probe. L’administrateur met à jour en heure creuse, exécute openclaw doctor, puis redémarre avec la commande OpenClaw. Il envoie ensuite un message depuis Slack demandant un résumé d’un jeu de logs de test. Le résultat doit arriver dans la bonne session, sans outil élevé et sans accès aux sessions d’un autre agent.

Enfin, il vérifie une automation de rapport :

openclaw automations list
openclaw automations runs --id <job-id>
openclaw logs --follow

Le déploiement est accepté seulement si RPC, Slack, tour d’agent et historique d’automation sont verts. Si l’un échoue et que la cause n’est pas corrigée dans la fenêtre prévue, il réinstalle N-1 et restaure l’état sauvegardé si nécessaire. Ce protocole mesure le service réellement rendu, pas un endpoint générique.

Bonnes pratiques

• Ne modifiez pas production et sécurité dans le même déploiement : un changement à la fois simplifie le diagnostic.
• Utilisez openclaw doctor après une évolution de configuration ou de port ; le daemon peut devoir être réinstallé pour refléter ses paramètres.
• Gardez les automations idempotentes. Après une perte de transport, vérifiez l’historique avant de relancer pour éviter une double action.
• Limitez les outils exec, navigateur, fichiers et contrôle du Gateway aux agents de confiance. Le contenu externe peut contenir une injection de prompt.
• Surveillez la saturation autant que la panne : mémoire, délai de boucle événementielle, files de sessions et espace disque.
• Conservez un runbook court avec propriétaire, commandes de diagnostic, emplacement des sauvegardes, délai de rollback et procédure de rotation des secrets.

La dette principale d’une OpenClaw prod n’est pas le nombre de fichiers de configuration. C’est l’autorité accumulée par les canaux, tools, skills et sessions. Réévaluez-la régulièrement.

Questions fréquentes

Comment vérifier un OpenClaw health check ?

Utilisez openclaw gateway status --require-rpc, puis openclaw health --json et openclaw channels status --probe. Ces commandes distinguent la supervision du processus, la réponse RPC et la connectivité des canaux. Ne supposez pas qu’un endpoint HTTP /health existe sur votre version.

Où se trouve la configuration OpenClaw en production ?

Le chemin par défaut est ~/.openclaw/openclaw.json. Il s’agit de JSON5 validé strictement. L’état et les workspaces se trouvent aussi sous ~/.openclaw par défaut, mais ce sont des périmètres différents. Utilisez OPENCLAW_CONFIG_PATH et OPENCLAW_STATE_DIR seulement si votre architecture exige de les séparer.

Docker est-il plus stable que systemd pour OpenClaw ?

Pas automatiquement. L’installation normale avec le daemon OpenClaw est le chemin le plus direct sur Linux. Docker apporte une frontière et une image reproductible, mais ajoute volumes, permissions et réseau. Choisissez-le pour ces propriétés, puis utilisez l’image officielle et un tag épinglé.

Comment éviter de perdre les tâches cron OpenClaw ?

Les automations sont persistées dans l’état SQLite partagé et s’exécutent dans le Gateway. Sauvegardez donc l’état, gardez le Gateway supervisé et contrôlez openclaw automations list ainsi que openclaw automations runs --id <job-id> après restauration. openclaw cron reste un alias, mais la CLI actuelle privilégie openclaw automations.

Peut-on partager un Gateway entre plusieurs clients ?

Seulement s’ils appartiennent à la même frontière de confiance. Plusieurs agents sur un Gateway apportent des workspaces et sessions séparés, pas une isolation multi-tenant hostile. Pour des clients mutuellement non fiables, utilisez des Gateway, credentials et environnements système séparés.

Articles liés

Une production OpenClaw fiable repose sur des preuves : RPC, canaux, permissions, sauvegarde restaurable et automatisations observées. Gardez le Gateway privé, réduisez l’autorité de chaque agent et préparez N-1 avant de mettre à jour. Une fois cette base stable, vous pouvez automatiser des tâches métier sans transformer chaque incident en enquête.

• Guide complet OpenClaw
• Installer OpenClaw sur un VPS
• Sécuriser OpenClaw avant la production
• Configurer OpenClaw correctement
• Surveiller les logs OpenClaw
• Automatiser avec OpenClaw