01_L’écart démo–production
Lancer OpenClaw en local prend moins d’une heure. La production est une discipline à part. En janvier 2026, Shodan recensait 42 665 instances OpenClaw exposées. Les causes racines sont prévisibles : identifiants en clair, liaisons réseau mal configurées, absence de supervision des processus, et tâches cron qui échouent en silence. Ce guide comble ces lacunes avec des étapes concrètes pour les nœuds M4 bare metal et OpenClaw v2026.2.26.
Le lecteur cible est le développeur qui souhaite une exécution OpenClaw stable et durable sans surveiller un portable. Les limites de performance locale, les cycles de veille et la limitation thermique rendent le matériel grand public peu adapté aux charges agent 24/7. Un nœud M4 dédié assure un débit constant, une IP stable et aucune surcharge de virtualisation. Les sections suivantes traitent de la gestion des secrets, de la fiabilité cron, de l’allocation des ressources multi-agents et du déploiement sur les hôtes bare metal MACGPU.
02_OpenClaw Secrets : éviter le texte clair au repos
OpenClaw v2026.2.26 introduit une gestion externalisée des secrets avec un flux opérateur complet : audit, configure, apply et reload. Les credentials sont résolus dans un snapshot runtime en mémoire. L’activation utilise un échange atomique : succès total ou retour à la dernière configuration valide connue. Le démarrage échoue rapidement si une référence de credential ne peut être résolue, évitant ainsi de placer les indisponibilités de fournisseurs sur le chemin de requête critique.
Le contrat SecretRef est une forme objet unique pour toutes les références : source (env, file ou exec), provider et id. Les références env lisent les variables d’environnement ; les références file utilisent des JSON pointers dans des fichiers locaux (ex. ~/.openclaw/secrets.json) ; les références exec appellent des binaires externes tels que Vault ou 1Password CLI. Les providers sont définis sous secrets.providers dans openclaw.json.
Le provider file lit un fichier JSON local. Assurez-vous que le chemin satisfait les vérifications de propriété et de permissions ; OpenClaw valide cela à l’activation. Utilisez mode: "json" lorsque le fichier est un objet JSON et que id est un JSON pointer (ex. /providers/openai/apiKey). Utilisez mode: "singleValue" lorsque le fichier contient une seule credential et que id vaut "value". Ne commitez jamais secrets.json en versionning ; ajoutez-le à .gitignore et documentez le schéma dans un fichier template.
Appliquez le flux opérateur par défaut avant d’exposer la gateway :
secrets audit signale les valeurs en clair au repos, les références non résolues et les ombres de précédence. secrets configure exécute la migration interactive, la résolution prévol et le nettoyage optionnel de l’ancien auth.json et .env. Après avoir appliqué un plan enregistré, appelez openclaw secrets reload pour re-résoudre les références sans redémarrer la gateway. L’état dégradé est signalé via SECRETS_RELOADER_DEGRADED ; le rétablissement via SECRETS_RELOADER_RECOVERED.
03_Fiabilité cron : heartbeat et supervision
Cron est souvent utilisé pour déclencher les heartbeats OpenClaw ou des tâches périodiques. Les échecs cron sont silencieux : pas de retry, pas de file morte, aucune garantie que le job a tourné. En production, associez cron à une supervision de processus afin que la gateway soit redémarrée en cas de crash. Utilisez un utilisateur cron dédié avec des privilèges minimaux et assurez-vous que la crontab utilise des chemins absolus et l’injection d’environnement.
La Gateway expose POST /hooks/wake pour les déclencheurs heartbeat à distance. Avec mode: "now" le heartbeat s’exécute immédiatement ; avec mode: "next-heartbeat" l’événement est mis en file pour le prochain cycle périodique. Une tâche cron peut appeler cet endpoint depuis la même machine :
Ne comptez pas sur cron seul pour la disponibilité. Exécutez la Gateway sous un gestionnaire de processus (launchd, systemd ou supervisord). Sur macOS, utilisez launchd avec KeepAlive et RunAtLoad afin que le service redémarre en cas d’échec et démarre au boot. Journalisez la sortie cron dans un fichier et surveillez les réponses 401 ou 5xx répétées ; elles indiquent une mauvaise configuration ou une panne de gateway.
1Password, Vault, sops, variables d’env
Succès total ou dernière config valide
Re-résolution manuelle sans redémarrage
04_Configuration des ressources multi-agents
Exécuter plusieurs agents sur un même nœud M4 impose une allocation explicite des ressources. Les configurations par défaut supposent une machine dédiée ; les hôtes partagés exigent des limites mémoire et CPU pour éviter OOM et thrashing. Le M4 Pro propose 36 Go ou 48 Go de mémoire unifiée et un CPU 14 cœurs ; le M4 Max monte jusqu’à 128 Go. Chaque exécution agent consomme de la RAM pour le contexte du modèle et du CPU pour l’exécution des outils.
Configurez les défauts des agents dans openclaw.json sous agents.defaults. Définissez les allowlists models pour que les agents n’utilisent que des providers et modèles approuvés. Limitez les niveaux thinking pour maîtriser les coûts ; utilisez timeoutSeconds pour borner les exécutions longues. Pour les agents pilotés par webhook, restreignez hooks.allowedAgentIds afin que les appelants ne puissent pas cibler des agents arbitraires. Utilisez des préfixes sessionKey distincts par intégration (ex. hook:ingress) pour l’isolation.
La pression mémoire est la contrainte principale. L’inférence LLM sur des modèles 10B–70B peut utiliser plusieurs Go par requête concurrente. Si vous exécutez plusieurs agents, échelonnez les déclencheurs cron et utilisez un dispatch basé sur file d’attente pour qu’une seule exécution lourde s’exécute à la fois. Surveillez la RSS et le swap ; définissez des limites ulimit ou cgroup si l’hôte exécute d’autres services. Évaluez vos modèles cibles avant de valider une taille de nœud : une exécution 70B unique peut culminer à plus de 40 Go de mémoire unifiée sur M4 Pro ; les nœuds 36 Go conviennent aux échelles 10B–34B avec un agent actif. Pour le parallélisme multi-agents, privilégiez le M4 Max en 64 Go ou 128 Go.
05_Provider Exec : 1Password et Vault
Pour les équipes utilisant déjà 1Password ou HashiCorp Vault, le provider exec évite la duplication des magasins de credentials. Le résolveur reçoit sur stdin un payload JSON avec protocolVersion, provider et ids ; il renvoie values ou des errors par id sur stdout. Configurez allowSymlinkCommand: true et trustedDirs: ["/opt/homebrew"] lorsque le binaire est un lien symbolique Homebrew.
Des règles de validation s’appliquent : id doit respecter ^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$, et la commande doit pointer vers un fichier régulier (ou un symlink autorisé). Les providers exec supportent le timeout, les limites de bytes en sortie et les allowlists d’env. Utilisez-les pour les déploiements production où les credentials résident dans un coffre centralisé.
06_Durcissement réseau et binding
Lie la Gateway à loopback (127.0.0.1) ou à une interface privée. Exposez-la à l’internet uniquement via un reverse proxy (Caddy, nginx) avec terminaison TLS et validation de token. Restreignez les IP sources ou utilisez un tailnet (Tailscale) pour que seuls les clients de confiance atteignent les endpoints hook. Journalisez les requêtes hook pour audit ; évitez de journaliser les payloads bruts pouvant contenir des secrets.
Utilisez un token hook dédié distinct de l’auth gateway. Définissez hooks.allowedAgentIds sur une liste explicite ; omettez ou utilisez "*" uniquement dans des environnements maîtrisés. Gardez allowRequestSessionKey à false sauf besoin explicite de sessions choisies par l’appelant, et restreignez allowedSessionKeyPrefixes (ex. ["hook:"]) dans ce cas.
07_Launchd et supervision des processus
Sur macOS, launchd est le superviseur de processus natif. Créez un plist sous ~/Library/LaunchAgents/ ou /Library/LaunchDaemons/ (pour un service système, exécuté en root). Entrées clés : KeepAlive true pour que le service redémarre en cas de sortie ; RunAtLoad true pour démarrage au boot ; StandardOutPath et StandardErrorPath pour la capture des logs ; EnvironmentVariables pour les variables d’env requises (ex. PATH, HOME). Utilisez launchctl load et launchctl unload pour activer ou désactiver.
N’exécutez pas la Gateway en root. Créez un utilisateur dédié (ex. openclaw) et définissez la propriété de ~/.openclaw pour cet utilisateur. Restreignez les permissions des fichiers secrets.json et openclaw.json (ex. 600). Si vous utilisez le provider exec avec 1Password ou Vault, assurez-vous que l’utilisateur launchd a accès au binaire résolveur et aux variables d’env requises (ex. VAULT_ADDR, HOME pour op).
08_M4 Bare Metal : pourquoi il convient à la production
Les Mac locaux se mettent en veille, limitent sous charge et disposent d’une connectivité grand public. Un nœud M4 bare metal en location tourne 24/7 sans cycle de veille, avec une marge thermique stable et une IP publique fixe. MACGPU fournit des nœuds Apple Silicon dédiés : pas d’hyperviseur, pas de voisinage bruyant, accès complet à l’API Metal pour tout futur workload agent accéléré GPU.
Étapes de déploiement : provisionnez le nœud, installez OpenClaw et les dépendances, configurez openclaw.json avec hooks.enabled: true, les providers de secrets et les agents autorisés. Ajoutez les credentials de canaux (WhatsApp, Telegram, Slack) si vous utilisez la messagerie. Exécutez openclaw secrets audit --check et configure avant mise en service. Placez la Gateway derrière un reverse proxy, restreignez les tokens hook et exécutez sous launchd ou systemd pour redémarrage automatique. Pointez cron vers /hooks/wake pour les heartbeats périodiques.
Cette configuration donne un déploiement OpenClaw de qualité production : secrets hors texte clair, heartbeats pilotés par cron avec supervision, prise en compte des ressources multi-agents et hôte M4 stable. Le coût total est généralement inférieur à l’exécution de VMs cloud équivalentes, avec de meilleures performances pour les charges natives Apple Silicon. Les instances Mac AWS EC2 et offres similaires facturent à l’heure avec engagement minimum ; la location bare metal évite ce verrouillage et offre un nœud fixe pour une dépense mensuelle prévisible. L’accès distant par SSH, partage d’écran ou Tailscale rend le nœud gérable depuis n’importe où : inspection des logs, exécution de openclaw secrets reload ou ajustement des plannings cron sans accès physique.
09_Synthèse
Le déploiement production OpenClaw v2026.2.26 requiert : (1) une gestion des secrets via openclaw secrets audit/configure/apply/reload pour ne jamais stocker les credentials en clair ; (2) une fiabilité cron en associant les déclencheurs heartbeat à la supervision des processus et à la journalisation ; (3) une configuration des ressources multi-agents avec allowlists de modèles explicites, timeouts et isolation de session ; (4) un hôte stable—M4 bare metal—qui ne se met pas en veille ni ne limite. Les nœuds MACGPU fournissent cet hôte avec accès Metal complet et sans surcharge de virtualisation, adaptés aux charges OpenClaw multi-agents 24/7.