De nombreuses équipes utilisent l’application OpenClaw pour macOS sur un portable tout en voulant un Gateway stable sur un Mac mini M4 Pro distant bare metal à Singapour, Tokyo, Séoul, Hong Kong, US East ou US West. Le portable reste une console légère. L’échec typique n’est pas le premier login SSH, mais un Remote à moitié configuré : tableau de bord sain via tunnel, Node Host jamais appairé, outils navigateur sur la mauvaise machine, ou coupure silencieuse du tunnel prise pour une panne Gateway. Ce guide couvre Local versus Remote over SSH versus Remote direct (ws/wss), ws://127.0.0.1:18789 via tunnel, le Node Host CLI et le keepalive de session sur les longs chemins. Tarifs : page tarifs NOVAKVM ; commande : page commander ; politique SSH : centre d’aide. À lire avec Gateway et Control UI SSH/TLS et première installation.
À la fin vous choisissez Local, Remote over SSH ou Remote direct ; vous savez où faire tourner le Node Host pour l’automation navigateur et Canvas ; vous configurez keepalive et clés d’hôte SSH pour éviter qu’un SSH inactif ne ressemble à un Gateway tombé. Rouvrez la documentation officielle OpenClaw après chaque mise à niveau.
[ SECTION_01 ] // REMOTE_PITFALLS Cinq pièges quand l’app macOS pilote un Gateway OpenClaw distant
Premier piège : traiter le Remote comme « exposer 18789 sur Internet », ce qui contredit loopback plus tunnel et affaiblit l’audit. Deuxième : attendre le nœud intégré de l’app pour l’automation navigateur en Remote — l’amont délègue au Node Host CLI via openclaw node install. Troisième : exit 127 si openclaw manque dans le PATH BatchMode. Quatrième : transports scindés quand Web Chat pointe encore un ancien port local. Cinquième : SSH sans keepalive — le Gateway sur NOVAKVM vit, le tunnel portable est mort, on redémarre les démons sous ~/.openclaw.
En revue d’architecture, une page avec trois colonnes — owner Gateway, owner tunnel, owner Node Host — évite des semaines de débat sur la latence modèle alors que seul le forward SSH a chuté. Si des journaux ou captures contiennent des données personnelles, alignez finalité, durée de conservation et accès sur le RGPD et vos accords avec NOVAKVM, au même titre que la rotation des clés SSH.
- 18789 brut public : bruit scanners, incompatible avec le design loopback-first.
- Node Host absent : dashboard OK, barre de menus « paired · disconnected » pour les capacités Mac.
- CLI distant hors PATH : Test remote et sondes en exit 127.
- Tunnel sans keepalive : chutes silencieuses mimant une panne Gateway.
- Mauvaise région : RTT élevé pour Test remote et timeouts SSH idle.
- Utilisateur macOS partagé : rollback faible si portable et hôte distant écrivent le même workspace.
Le Remote réussit quand Gateway, URL de tunnel et Node Host sont trois composants nommés avec des owners — pas une vague « connexion cloud ».
[ SECTION_02 ] // MODE_MATRIX Local, Remote over SSH et Remote direct en matrice de décision
Local : tout sur le portable. Remote over SSH : défaut NOVAKVM — commandes distantes, ssh -N -L en BatchMode, gateway.remote.url sur ws://127.0.0.1:18789 pour Web Chat et CLI. Remote direct (ws/wss) : sans SSH si LAN, Tailnet ou URL TLS déjà de confiance ; le Gateway voit l’IP client réelle.
| Dimension | A · Local sur portable | B · Remote over SSH (défaut) | C · Remote direct ws/wss |
|---|---|---|---|
| Meilleur cas | Essais solo, démos hors ligne, pas d’agent 24/7 | Gateway sur M4 Pro NOVAKVM ; portable console seule | URL Tailnet/LAN auditée ; histoire certificats stable |
| Bind Gateway | Loopback sur portable | Loopback sur Mac distant ; tunnel vers portable | LAN/Tailscale/public selon revue sécurité |
| IP Node vue par Gateway | IP réelle du portable | Souvent 127.0.0.1 via tunnel (attendu) | IP client réelle sur le fil |
| Six régions | N/A pour agents cloud | Région selon modèle, données, RTT opérateurs | Terminaison TLS près du Mac ; pas de double saut transfrontalier |
Colocalisez le Gateway principal près de la majorité des opérateurs, pas seulement la région la moins chère sur la page tarifs. Une location journalière ou hebdomadaire suffit pour comparer deux villes avec Test remote avant un engagement mensuel.
Défaut : Remote over SSH sur Gateway loopback NOVAKVM ; passage en direct ws/wss seulement avec Tailnet ou TLS audités.
[ SECTION_03 ] // GATEWAY_NODE_HOST Prérequis distants, pont Node Host et keepalive SSH
Sur l’hôte NOVAKVM : openclaw dans le PATH des shells BatchMode, Gateway en loopback, SSH par clés. Approbations TCC distantes (Automation, Screen Recording) si les agents en ont besoin. Dans l’app Réglages → Général → Remote : SSH ou Direct, Test remote, puis openclaw node install sur le Mac qui exécute les outils. Dashboard OK avec capacités Mac hors ligne : souvent node appairé mais disconnected.
L’amont documente openclaw-mac configure-remote, champs de ports, exit 127, santé WS Web Chat et rotation des pins TLS Tailscale. Relire après chaque release.
https://docs.openclaw.ai/platforms/mac/remote
https://github.com/openclaw/openclaw
ssh -N \
-o BatchMode=yes \
-o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
-L 18789:127.0.0.1:18789 \
user@novakvm-sg-m4.example
Aligner gateway.remote.remotePort sur l’écoute distante ; pré-approuver les clés d’hôte SSH ; en direct wss:// sur Tailscale Serve, effacer les pins TLS obsolètes ou définir gateway.remote.tlsFingerprint. Ne pas lier les forwards sur 0.0.0.0.
Le Node Host n’embarque pas le transport SSH comme les clients Gateway : unifier sur 127.0.0.1:port-forwardé. Après redémarrage Gateway, inclure openclaw node restart dans la checklist pour éviter les zombies silencieux post-1012.
[ SECTION_04 ] // RUNBOOK Douze étapes pour déployer le Remote sur un Gateway M4 Pro en six régions
- Choisir la ligne de mode : documenter Local, Remote-SSH ou Remote-direct avec owners et raccourcis interdits sur une page.
- Commander et provisionner le Mac : ville sur la page commander ; accès SSH selon le centre d’aide.
- Installer le CLI distant :
openclawdans le PATH BatchMode ; joindreopenclaw gateway statusau ticket de changement. - Gateway en loopback : port WebSocket de contrôle sur 127.0.0.1 sauf revue sécurité pour direct.
- Standardiser la config SSH :
LocalForward,IdentityFile,BatchMode=yes, keepalives ; pas de bind toutes interfaces. - Préconfigurer l’app (optionnel) :
openclaw-mac configure-remoteavec--ssh-target, ports et jeton avant l’onboarding GUI. - Test remote dans Réglages : succès =
openclaw status --jsondistant ; corriger exit 127 avant d’inviter les opérateurs. - Node Host sur la machine qui exécute les outils : portable pour navigateur local, Mac distant si les outils tournent là ; démarrer le service, vérifier
node.list. - Aligner les racines workspace : racine projet et chemins CLI sur le checkout distant ; sandbox séparé de la production.
- Exercice de coupure tunnel : tuer SSH en réunion ; reprise en cinq minutes sans redémarrer le Gateway.
- Scorer les six régions : villes opérateurs, région modèle, résidence des données ; choisir SG, JP, KR, HK, US East ou US West.
- Revue trimestrielle : échantillonner journaux SSH et Gateway ; si pile CI superposée, comparer nœuds parallèles sur la page tarifs.
[ SECTION_05 ] // DATA_FAQ Paramètres cités, notes six régions et FAQ
Les éléments suivants sont des conventions terrain pour la planification — pas des garanties sur votre build. Réconcilier ports, flags et libellés de menu avec la doc OpenClaw après chaque upgrade.
Utilisez ces valeurs en revue d’architecture, pas comme SLA métier. Si Web Chat, journaux Node ou captures contiennent des données personnelles, documentez utilisateurs macOS séparés pour CI et agent, plus durées de conservation, en parallèle du palier de location — quel que soit le transport SSH ou direct.
- Port WebSocket Gateway par défaut : la communauté et la doc Remote ancrent souvent sur 18789 ; si vous changez le port distant, régler
gateway.remote.remotePortet les cibles de forward ensemble. - Paire keepalive SSH :
ServerAliveInterval=30etServerAliveCountMax=3limitent les pertes silencieuses ; l’app gère aussi sa session SSH via Réglages. - IP Node 127.0.0.1 sous SSH : attendu via tunnel ; pour l’IP réelle du portable dans les logs Gateway, passer en Remote direct.
- RTT six régions : opérateurs US East avec Gateway Tokyo : Test remote et santé Web Chat s’étirent ; colocaliser ou ajouter une console in-region.
FAQ
- Q : Test remote OK mais Web Chat bloqué ? R : Gateway distant actif et port local forwardé = port WS Gateway ; l’UI exige un WebSocket sain, pas un ancien serveur HTTP WebChat.
- Q : Gateway la nuit sur le portable ? R : pour agents 24/7, Gateway sur M4 Pro loué et mode Remote — le sommeil du portable tue les canaux.
- Q : Voice Wake en Remote ? R : l’amont transmet les phrases déclencheuses via la config distante ; pas de forwarder séparé si Remote correct.
- Q : M4 ou M4 Pro pour Gateway Remote ? R : console légère mono-workspace souvent M4 ; Gateway multi-workspace stable plus Node distant → paliers M4 Pro sur la page tarifs.
Les Mac domestiques subissent le sommeil ; les VM génériques manquent de TCC macOS et d’outils canal ; les tunnels ad hoc masquent exit 127 et les lacunes Node Host. Pour OpenClaw, CI iOS et agents IA sur un chemin Remote-SSH documenté vers un Gateway six régions, la location Mac mini bare metal NOVAKVM est souvent le meilleur fit : M4 Pro exclusif, essais journaliers ou hebdomadaires, nœuds parallèles si la charge s’empile. Phrase standard en réunion : Gateway loopback, SSH vers 127.0.0.1:18789 sur le portable, Node Host sur la machine qui exécute les outils — direct seulement avec owner nommé.