Déplacer OpenClaw depuis un portable sujet au sommeil, un Mac domestique saturé ou un ancien nœud loué vers un Mac mini classe M4 fraîchement provisionné au Canada, ce n'est pas « copier des fichiers » : c'est changer quelle machine porte la continuité opérationnelle — le processus qui écoute sur le TCP 18789, le fichier plist LaunchAgent ou LaunchDaemon qui survit au reboot, le répertoire workspace que vos agents modifient en boucle, et les secrets que vos canaux réseau croient légitimes. Si une seule de ces couches dérape, vous pourchassez des fantômes : clients qui semblent sains en local alors que le trafic production frappe encore le mauvais jeton, ou un Gateway qui redémarre sans PATH parce que launchd n'a jamais vu votre shell interactif. Ce billet propose une colonne vertébrale de migration réutilisable dans Confluence : jalons avec garde-fous, deux tableaux comparatifs, commandes d'empaquetage concrètes, contrôles de recette adaptés au SSH et au Partage d'écran à très longue latence, et une voie de rollback explicite qui ne suppose pas de réinstaller macOS.
Si vous n'avez jamais durci un Mac distant auparavant, enchaînez avec OpenClaw 2026 : installation, déploiement et dépannage sur Mac distant — openclaw onboard, démon Gateway et planification des ressources M4 au Canada pour le vocabulaire d'onboarding. Pour arbitrer tunnel SSH contre exposition directe du listener sur une machine Hashvps, croisez avec OpenClaw 2026 sur Mac distant M4 au Canada : tunnel SSH ou passerelle directe ? gateway.remote.token, port 18789, PATH et launchd. Enfin, si votre équipe répartit déjà la journée APAC et les batches nord-américains, les fenêtres de gel décrites ici s'alignent naturellement sur Équipes APAC 2026 (quatre zones) et Mac distant Canada en « suivre le soleil » : nœud nord-américain de nuit, M4 16 Go / 256 Go vs 24 Go / 512 Go, extensions 1 To / 2 To et sièges parallèles — checklist de passation, matrice et FAQ.
Ce que signifie une migration « stable » en production
Une bascule stable n'est pas « ça a marché une fois dans Terminal ». Pour OpenClaw en tant qu'hôte d'agents en bordure, la stabilité est un faisceau de garanties observables après un démarrage à froid : un seul listener Gateway documenté sur 127.0.0.1:18789 ou la liaison que vous avez écrite noir sur blanc, le même jeu de variables d'environnement pour l'utilisateur d'automatisation et pour le plist, des identifiants de canaux qui se résolvent sans invite interactive, de la marge disque APFS pour les profils navigateur et les journaux, et la capacité pour des opérateurs en Asie ou en Europe de boucler édition de fichiers en SSH plus un test VNC optionnel sans deviner si la latence ou l'authentification a cassé la chaîne. Ces garanties deviennent des cases à cocher que l'astreinte peut exécuter depuis un Wi‑Fi d'hôtel à l'autre bout du monde.
La latence transpacifique n'est pas une « faute morale » du réseau ; c'est une contrainte de conception. Privilégiez de petites sondes idempotentes (un health check Gateway authentifié, un ping synthétique sur canal) plutôt que de faire transiter des artefacts multi‑giga dans les deux sens pendant la même fenêtre de changement. Réservez la synchronisation massive du workspace au créneau maintenance où un échec peut basculer vers une restauration tarball sans corrompre un agent actif.
Côté réseau sortant, rappelez-vous pourquoi les équipes choisissent souvent un Mac cloud avec adresse stable : les listes blanches de webhooks et les contrôles anti‑abus des API réagissent mal aux adresses résidentielles qui pivotent. Pour le vocabulaire « une IP physique par machine », ouvrez aussi IP Native Physique : Pourquoi Mac Cloud a aussi Besoin d'une IP par Machine lorsque vous rédigez la section sécurité du dossier de migration.
Prévol : instantané, gel du changement et propriété
Deux semaines avant de toucher au trafic production, figez trois artefacts : la ligne majeure Node.js et le fichier de verrouillage des paquets attendu par votre build Gateway, la chaîne de version OpenClaw CLI vérifiée sur l'hôte source, et une archive tarball ou un instantané style ZFS du workspace tel qu'il existait après la dernière tâche planifiée réussie. Stockez ce bundle dans un stockage objet avec somme de contrôle ; il devient à la fois la source de migration vers l'avant et l'oracle de rollback si le nouveau Mac altère des métadonnées.
Répartissez les rôles sans ambiguïté : une personne approuve les modifications de plist, une autre fait pivoter gateway.remote.token si votre politique impose une rotation lors du changement d'hôte, une troisième valide les webhooks de canaux depuis l'extérieur du périmètre fournisseur. Lorsque la propriété se brouille, les LaunchAgents doublonnent et lsof montre deux listeners qui se disputent le même port après reboot.
Empaqueter le workspace : discipline tarball contre rsync incrémental
Choisissez la méthode selon la taille et la sensibilité. Pour des workspaces inférieurs à quelques gigaoctets mais riches en petits fichiers, une archive compressée créée sur la source pendant que les agents sont en repos forcé (Gateway arrêté, aucune automatisation navigateur) fournit un artefact stable octet par octet que vous vérifiez avec shasum -a 256 des deux côtés. Pour des workspaces de plusieurs centaines de gigas avec dérive continue, utilisez rsync sur SSH avant la fenêtre de bascule, puis une passe finale courte pendant le gel pour minimiser l'indisponibilité.
Excluez explicitement les chemins bruyants régénérables : node_modules, caches navigateur éphémères, fichiers macOS .DS_Store si la politique le permet, et tout secret purement local que vous préférez régénérer plutôt que copier. Réinstallez les dépendances sur la destination avec le même fichier de verrouillage pour que les modules natifs correspondent à l'architecture CPU M4. Sauter cette étape est une cause classique de plantages « fonctionne sur Intel, échoue sur Apple Silicon » dans des piles façon Puppeteer.
openclaw gateway stop tar --exclude='node_modules' --exclude='.git' -czf openclaw-workspace-pre-migrate.tgz ./openclaw-workspace shasum -a 256 openclaw-workspace-pre-migrate.tgz | tee workspace-sha256.txt
Après extraction sur l'hôte Canada, corrigez les propriétaires si vous avez décompressé en tant que super-utilisateur : chown -R utilisateur-auto:staff sur l'arborescence workspace et vérifiez que les attributs étendus n'ont pas retiré le bit exécutable des scripts helpers. Si votre fournisseur monte des volumes externes, placez les artefacts lourds sur le niveau disque étendu pour garder le volume système réactif pour journaux et swap lors des pics.
Gateway sur le port 18789 : bascule par phases et orientation du trafic
Organisez le déplacement du Gateway en trois phases explicites plutôt qu'en bascule globale instantanée. Phase A : mettre en ligne le nouveau Mac avec le workspace importé et un jeton temporaire ; seuls les opérateurs internes se connectent, souvent via un tunnel SSH -L 18789:127.0.0.1:18789 pour éviter toute exposition TCP brute. Phase B : parité fonctionnelle — mêmes gabarits de prompts, identifiants de canaux, listes blanches sortantes ; comparez les journaux structurés ancien et nouveau sur une tâche synthétique contrôlée. Phase C : mettre à jour la configuration client ou les routes reverse-proxy pour que les appelants production atteignent l'écoute Canada, puis drainer l'hôte legacy.
Pendant la Phase B, laissez l'ancien Gateway joignable mais lecture seule pour les humains (pas de nouvelles tâches planifiées). Si votre architecture ajoute un frontal TLS géré par le fournisseur, coordonnez SAN de certificat et sondes amont pour qu'une sonde idle sur /health ne clignote pas uniquement parce que le RTT transpacifique dépasse un délai naïf. En cas de doute, augmentez modérément les budgets de santé la première heure après bascule, puis resserrez une fois les métriques calmes.
Concernant le port 18789 : après chaque reboot pendant le week-end de migration, confirmez l'adresse de liaison avec lsof -iTCP:18789 -sTCP:LISTEN. Si vous voyez une liaison publique inattendue, arrêtez-vous et réconciliez avec la politique sécurité avant d'exposer quoi que ce soit au-delà de loopback plus tunnels SSH.
Reconstruction LaunchDaemon / LaunchAgent pour Mac M4 sans écran
Un SSH interactif ne prouve rien sur l'environnement réel du démon. Reconstruisez les fichiers plist sur la destination plutôt que de copier du XML périmé : chemins absolus vers openclaw, injection PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin via EnvironmentVariables, WorkingDirectory pointant vers la racine workspace, sorties stdout/stderr vers des fichiers rotatifs sous /usr/local/var/log ou un chemin approuvé par le fournisseur. Chargez avec launchctl bootstrap dans le bon domaine (utilisateur GUI versus démon arrière-plan) conformément à la façon dont votre organisation provisionne les Mac headless.
Après chargement, validez avec une sonde non interactive : un petit script invoqué par launchctl start qui affiche which node et la longueur de $GATEWAY_REMOTE_TOKEN sans divulguer le secret. Si cette sonde diverge de votre shell SSH, corrigez les variables d'environnement du plist avant d'ouvrir les canaux clients. Planifiez un reboot volontaire pendant la journée au Canada pour que les pairs APAC observent le démarrage à froid pendant que les mentors sont disponibles.
Recette SSH et VNC transpacifique : critères qui résistent au biais opérationnel
Les contrôles SSH doivent inclure l'authentification par clé sans mot de passe et une voie de secours documentée avec votre fournisseur. Mesurez non seulement la latence moyenne mais aussi les queues : exécutez mosh ou ssh avec ServerAliveInterval réglé pour que les sessions idle survivent aux NAT d'hôtel sans masquer une mort réelle du Gateway derrière un tunnel bloqué. Pour le VNC via Partage d'écran, validez le sens du presse-papiers si les opérateurs collent des jetons, vérifiez que le scaling HiDPI ne masque pas les invites de permission, et notez si plusieurs sessions simultanées sont permises ou se font concurrence.
La recette doit inclure un scénario « pire réaliste » : un opérateur sur liaison montante contrainte ouvre SSH, redémarre le Gateway via le plist, surveille les journaux pendant soixante secondes et déclenche un message sortant sur canal. Si ce scénario réussit deux fois de suite, vous avez une preuve plus solide que dix boucles curl triviales depuis le même datacenter.
Tableau des jalons de migration (qui signe quoi)
| Jalon | Objectif | Signal obligatoire | Propriétaire typique |
|---|---|---|---|
| G0 inventaire | Aucun listener mystère ni plist doublon | launchctl list + lsof propres ; chemin binaire Gateway unique |
Ingénieur plateforme |
| G1 plan de données | Parité octets du workspace ou dérive maîtrisée | Somme SHA256 identique ou journal rsync final sans fichiers en attente | Responsable automatisation |
| G2 secrets | Jetons isolés par génération d'hôte | Ancien jeton retiré des clients ; nouveau jeton uniquement plist + coffre | Sécurité / IAM |
| G3 runtime | Résilience au démarrage à froid | Test reboot OK ; journaux montrent handshake canal réussi | Astreinte primaire |
| G4 routes clients | Le trafic atterrit au Canada | Sonde externe voit certificat TLS attendu + corps health attendu | Propriétaire DNS / bordure |
Mac source versus nœud M4 Canada : écarts qui changent OpenClaw
| Dimension | Mac local / ancien nœud | Cible M4 distante Canada |
|---|---|---|
| Alimentation & veille | Couvercle fermé, surprises Économiseur d'énergie, jitter Wi‑Fi | Alimentation datacenter ; imposez pmset / politiques avec le fournisseur |
| Sortie & histoire IP | CGNAT résidentiel, IP qui pivotent | Sortie fournisseur stable ; listes blanches webhooks plus simples |
| Disposition disque | Fusion Drive ou SSD portable plein | APFS extensible ; séparez journaux et workspace sur des niveaux |
| Portail TLS | Souvent aucun (pur tunnel SSH) | Souvent reverse-proxy ; alignez timeouts idle avec le RTT |
| Observabilité | Coup d'œil Console.app ad hoc | Expédier les journaux vers un agrégateur dès le jour un |
| Distance opérateurs | Clavier attaché | SSH/VNC ; planifiez recettes avec fenêtres APAC |
Rollback qui préserve la dignité (et le sommeil)
Le rollback n'est pas une honte ; c'est une assurance exécutée calmement. Pré-stagez trois artefacts avant la Phase C : le dernier plist sain sur l'hôte ancien, la valeur précédente de gateway.remote.token dans votre coffre (marquée dépréciée mais récupérable), et les extraits de configuration DNS ou clients versionnés dans Git pour pouvoir revenir en une fusion. Si le trafic production doit retourner sur le Mac legacy, arrêtez d'abord le Gateway Canada pour éviter des réponses canal en split-brain, restaurez le routage, réchauffez l'ancien listener, puis rejouez une transaction synthétique unique pour prouver que lecteurs et writers sont d'accord.
Gardez le tarball de prévol intact pendant les expériences de rollback ; si corruption suspectée, restaurez depuis ce bundle vérifié par somme plutôt que de réparer à moitié des fusions Git à quatre heures du matin. Fixez des limites de temps : si la recette échoue deux fois pour des causes racines distinctes, déclenchez le rollback plutôt qu'une pile de rustines qui masquent la faute d'origine.
Synthèse
Traitez une migration OpenClaw vers un Mac M4 distant au Canada comme un mouvement réseau et identité, pas comme une copie de fichiers. Empaquetez les workspaces sous repos forcé avec sommes de contrôle, reconstruisez launchd avec chemins absolus et environnement explicite, stagez le Gateway 18789 derrière SSH avant d'exposer la bordure, et acceptez le résultat avec des scénarios SSH/VNC réalistes à très longue distance. Gardez des jetons uniques par génération d'hôte, limitez les Gateways parallèles, et répétez le rollback avant d'en avoir besoin. Avec le tableau des jalons et la matrice comparative ci-dessus, votre équipe partage un vocabulaire go/no-go qui survit à la fatigue et aux fuseaux horaires.
FAQ
Dois-je réutiliser le même gateway.remote.token sur le nouveau Mac ?
Seulement si votre modèle de menace autorise explicitement la continuité d'hôte sans rotation. La bonne pratique lors d'un changement de fournisseur est de créer un nouveau jeton, mettre à jour le coffre, faire pivoter les clients, puis révoquer l'ancien jeton après une journée ouvrée complète au vert sur les moniteurs.
Combien de temps puis-je faire tourner ancien et nouveau en parallèle sans risque ?
Quelques minutes à quelques heures pendant la Phase B restent raisonnables ; plusieurs jours invitent à la dérive. Si vous devez prolonger le chevauchement, figez les écritures sur les chemins workspace partagés ou acceptez qu'une réconciliation supplémentaire via rsync sera nécessaire.
Pourquoi mon Gateway fonctionne en SSH mais meurt après reboot ?
Presque toujours PATH ou visibilité du jeton dans le contexte plist. Appliquez la sonde non interactive décrite dans la section LaunchDaemon et comparez à votre shell SSH ; alignez EnvironmentVariables jusqu'à correspondance.
Le VNC seul suffit-il pour exploiter OpenClaw au quotidien ?
Le VNC aide pour les dialogues de permission et le débogage visuel, mais automatisez les tâches récurrentes via SSH et édition plist. Partage d'écran sur RTT élevé sans réglages façon ServerAliveInterval frustre les opérateurs ; composez les protocoles volontairement.
Ai-je besoin d'un listener public sur 18789 ?
Pas nécessairement. Beaucoup d'équipes gardent loopback et tunnels SSH ou un reverse-proxy TLS. Choisissez en conscience ; lier 0.0.0.0 sans plan de contrôle additionnel est rarement approprié.
Quel est le signal le plus rapide que la bascule a réussi ?
Un health check authentifié sur le chemin Canada plus un message sortant observé de bout en bout sur canal. La latence seule est un faible proxy ; le trafic sémantiquement correct est la preuve.
Comment éviter les erreurs de permissions APFS après extraction tar ?
Extrayez en tant qu'utilisateur runtime lorsque c'est possible ; sinon corrigez propriétaire et groupe récursivement, puis vérifiez les bits exécutable sur les scripts helpers avant de relancer l'automatisation.
Quand augmenter RAM ou disque au milieu de la migration ?
Si les journaux au démarrage à froid ou l'automatisation navigateur approchent du swap pendant les tests de parité, redimensionnez avant de déclarer la Phase C terminée. La pression disque pendant la migration amplifie chaque glitch réseau transient en échecs de job.