2026 OpenClaw Gateway
hot reload et multi-instance distant

Le Gateway est un processus Node long qui multiplexe WebSockets, RPC CLI, sessions et adaptateurs de canaux sur un listener unique, 18789 par défaut. Le hot reload fusionne les deltas de configuration tout en cherchant à garder les sessions, mais tout changement qui exige de retirer le socket d'écoute ne peut pas être simulé par merge interne. Paramètres TLS, passage du loopback au LAN exposé, collisions de ports et garde-fous d'authentification qui empêcheraient une surface d'administration anonyme appellent un rebounce maîtrisé. Les modes hybrides gardent des listes internes des champs considérés sûrs en ligne contre ceux marqués redémarrage obligatoire ; en rythme pré-1.0 cette frontière glisse à chaque release, donc les runbooks doivent privilégier les logs vivants plutôt que des listes mémorisées.

Cinq signatures récurrentes imitent des bugs de reload mais relèvent souvent d'erreurs de catégorie ou de dérive de cible.

Ordre de triage : classer les edits touchant le socket contre routage seulement, valider câblage distant et variables d'environnement, puis santé du daemon. Le guide complet d'installation avec doctor vit ailleurs sur ce blog ; ici le focus est reload et mécanique multi-instance.

Archivez des instantanés de configuration avec identifiants de ticket dès que staging et production se mélangent ; la discipline git diff bat les merges héroïques de minuit.

La télémétrie d'exploitation confirme : si la latence médiane CLI ne grimpe que pendant les merges touchant le bloc gateway, vous avez probablement manqué une signature de redémarrage plutôt qu'une famine CPU systémique. Corrélez les dates de release avec des incidents de mise en sourdine des canaux et vous verrez des pannes grises où les messages semblent livrés en amont sans atteindre le routage modèle parce que le rebounce a été sauté. Former les intervenants juniors à greper les logs pour ces signatures paie plus vite qu'agrandir uniformément les CPU.

Documentez quels comptes d'automatisation peuvent invoquer des chemins sensibles au reload. Les pipelines CI qui réécrivent le JSON par templating naïf introduisent commas orphelins ou clés dupliquées que le parseur rejette discrètement jusqu'au redémarrage, souvent attribué à tort à un reload fragile. La validation de schéma en CI aligne edits humains et robotiques.

Les simulations d'incident sans vidéo suffisent : une chronologie textuelle avec rôles clairs. Mesurez le délai jusqu'à la reconnaissance et jusqu'au rétablissement des accusés de réception des canaux. Renouvelez trimestriellement avec des chefs d'incident différents pour éviter l'emprise d'un seul expert tacite.

Pour les équipes créatives sur Mac, la proximité avec les API graphiques Apple et Xcode peut justifier un nœud bare metal dans la même ville que les testeurs, sans remplacer un reverse proxy propre ni une rotation de jetons rigoureuse.

Plutôt que mémoriser des noms de champs volatils, ancrez les décisions sur la classe transport : listeners, TLS et couplage d'authentification touchent la frontière kernel et appartiennent aux redémarrages planifiés ; politiques de routage, nombreux paramètres de canaux, expériences de routage modèle et retouches de formatage tendent vers la fusion en ligne. Les logs Gateway font foi sur succès de merge ou obligation de redémarrage. L'exposition publique exige des upgrades WebSocket de reverse proxy synchronisés et une discipline de rotation comme dans l'article VPS de durcissement.

Pare-feu, extraits NGINX ou Caddy et groupes de sécurité restent dans le playbook Gateway public de ce site ; dupliquer des captures d'écran vieillit vite quand les consoles changent de libellés.

Des exercices avec trafic synthétique et bascules volontairement redémarrage-requises affinent la matrice. Partagez les enseignements en revue hebdomadaire pour aligner produit et plateforme.

Les organisations soucieuses des coûts confrontent cette matrice à l'historique d'incidents : le scaling vertical coûteux est rarement justifié quand les logs montrent du churn de socket. Investissez dans des chemins proxy documentés et un staging séparé.

Vérifiez aussi que les health checks internes réutilisent le même protocole et les mêmes en-têtes que les clients externes ; sinon vous aurez des checks verts internes pendant des échecs externes réels.

Le tableau ne remplace pas les notes de version : une montée de version peut déplacer des champs entre colonnes. Le consensus des logs reste autoritaire pendant que la matrice structure la discussion en amont de la fenêtre de changement.

Le mode distant découple la machine qui exécute les commandes CLI quotidiennes de celle qui possède canaux et sessions. Le portable garde une configuration mince vers le WebSocket cloud et injecte les secrets par variables d'environnement, pas dans l'historique shell. Les Gateways parallèles pour staging exigent une triple isolation : ports, arborescences OPENCLAW_HOME et labels de log pour que le support ne mélange jamais stderr.

Hôte A production :
  OPENCLAW_GATEWAY_PORT=18789
  OPENCLAW_HOME=/var/openclaw/prod-a

Hôte B staging :
  OPENCLAW_GATEWAY_PORT=18790
  OPENCLAW_HOME=/var/openclaw/staging-b

CLI portable :
  gateway.remote.url=wss://gateway.example.com/openclaw
  gateway.remote.token=${OPENCLAW_REMOTE_TOKEN}

Après chaque upgrade, diff les clés remote : les défauts pré-1.0 se réordonnent souvent. Sur Mac cloud, validez le réveil LaunchAgent séparément de la sémantique reload ; les déconnexions liées au sommeil imitent des merges ratés.

Les reverse proxies superposent des URLs : terminaison TLS au bord signifie wss vers l'extérieur, peut-être ws interne sur localhost. Documentez trois URL explicitement, URL client public, URL amont interne, cible curl de santé, pour éviter le cerveau divisé où les tableaux sont verts mais les CLI perdent la poignée de main. Les timeouts d'inactivité doivent dépasser les plus longues rafales cron.

Lorsque vous mélangez plusieurs zones de disponibilité, notez par zone quelles adresses NAT de sortie doivent figurer sur les allowlists des fournisseurs amont et si les keepalive WebSocket peuvent être neutralisés par des filtres intermédiaires.

Le bleu-vert avec deux Gateways exige une rotation de jetons indépendante pour qu'un secret de staging compromis n'ouvre pas les canaux de production. Automatisez les rappels de rotation car les environnements parallèles amplifient l'oubli.

Annotez chaque étape avec rôles responsables pour que plateforme et propriétaires d'applis sachent qui sonde et qui contacte clients. La confusion à la quinzième minute d'incident coûte plus qu'une faute de frappe sur le port. Réexécutez le runbook à sec après chaque upgrade majeur.

Des checklists légères battent l'héroïsme improvisé quand les opérateurs sont fatigués. Liez-les aux calendriers de changement et aux validations pour exposer les périodes gelées.

La sixième étape évite les rollback paniqués : sans pin de version ni diff, vous risquez de republier le mauvais artefact pendant l'incident et d'allonger encore le chemin de récupération.

Exploiter Gateway comme contenant jetable sans contrat de reload clair brûle le temps d'incident aux pics. Des merges disciplinées et des hôtes stables font d'OpenClaw de l'infrastructure plutôt qu'un accessoire portable. Les locations Mac mini cloud MESHLAUNCH sont souvent le meilleur choix quand l'exclusivité Apple Silicon, l'alimentation résiliente et des baux élastiques sur Singapour, Tokyo, Séoul, Hong Kong, US Est et US Ouest permettent de colocaliser workloads macOS natifs avec le plan de contrôle Gateway, avec fenêtres de changement explicites plutôt qu'un Mac ouvert le week-end.

Les finances détestent le scale vertical inutile issu d'idées fausses sur le reload. Prouvez par logs si incidents et churn socket corrèlent ; sinon budgétisez clarté réseau ou double staging plutôt que CPU surdimensionnés inactifs.

Des utilisateurs régionaux à Singapour, Tokyo ou Séoul gagnent souvent à garder plan de contrôle et builds interactifs dans la même métropole, car des allers-retours CLI sporadiques deviennent perceptibles quand hôtes de gestion et de build divergent géographiquement.