OpenClaw Gateway sur Mac distant
launchd, SSH, VPN, 18789 et double passerelle

Sur un Mac distant loué, l'enjeu est double : garder le binaire sous contrôle de launchd avec des journaux exploitables, et exposer le port d'écoute — souvent 18789 dans les guides récents — sans ouvrir la machine entière sur Internet. Ce guide résume un schéma éprouvé pour 2026 : résidence launchd, accès par tunnel SSH ou VPN, diagnostic des refus de connexion et des erreurs d'authentification, isolation de deux passerelles sur un même hôte, puis choix de région et de stockage chez nuzcloud. Pour le panorama régional et CI, voir aussi OpenClaw sur Mac distant : régions, stockage et CI.

launchd : rendre la passerelle résidente et observable

Créez un utilisateur de service dédié ou, à défaut, un LaunchAgent dans ~/Library/LaunchAgents avec RunAtLoad, KeepAlive et un ThrottleInterval raisonnable pour éviter les boucles de redémarrage bruyantes. Fixez explicitement WorkingDirectory vers le dossier de configuration, redirigez StandardOutPath et StandardErrorPath vers des fichiers rotatifs ou vers syslog via logger, et testez d'abord en foreground avant launchctl bootstrap. Après chaque mise à jour macOS, vérifiez que le domaine chargé correspond bien (gui versus user) : un job mal domainé ne repart pas à la session suivante.

Tunnels SSH et VPN : deux chemins complémentaires

Le tunnel SSH (ssh -N -L 0.0.0.0:18789:127.0.0.1:18789 adapté à votre bind) reste le plus simple pour du lab ou une équipe réduite : ServerAliveInterval, clés dédiées, AllowTcpForwarding côté serveur, et idéalement autossh sur une petite VM ou un poste fixe qui maintient le tunnel. Pour la production, un VPN site-à-site ou WireGuard / Tailscale sur le Mac hébergé supprime la dépendance à une session SSH longue et normalise le routage vers le port local ; mesurez le RTT et la perte avec mtr depuis chaque site client. Si vous comparez bail, latence et partage multi-utilisateur, le guide OpenClaw + Mac distant : louer ou acheter, SSH / VNC détaille les compromis.

Port 18789, TLS et auth : ordre de triage

Si rien n'écoute, launchctl print sur votre label et les journaux du plist tranchent avant tout firewall. Si le port répond en local mais pas à distance, vérifiez que le process écoute sur 127.0.0.1 seulement — alors seul le tunnel ou le VPN peut joindre le service, ce qui est souhaitable. Quand la connexion TCP s'établit mais le client échoue tout de suite, inspectez les jetons OPENCLAW_*, l'horloge NTP, les certificats intermédiaires derrière un reverse proxy et les en-têtes WebSocket ; un curl -v vers l'URL interne reproduit souvent l'erreur sans passer par l'IDE.

Deux passerelles sur un même Mac : isolation réelle

Évitez deux instances qui se battent pour le même répertoire de données ou le même trousseau. Créez deux utilisateurs macOS ou deux répertoires home distincts, deux labels launchd, deux ports locaux mappés différemment côté tunnel, et des variables d'environnement séparées. Séparez les journaux et les quotas disque : une passerelle « prod » et une « sandbox » partagent rarement le même volume de caches sans collisions sur les verrous de fichiers.

nuzcloud : US Est, APAC, paliers M4 et SSD abordable

Choisissez la région d'abord selon où se trouvent vos développeurs et vos API de modèles : US Est minimise souvent la latence vers les plans de contrôle américains, tandis que Singapour, Tokyo, Séoul ou Hong Kong servent mieux une équipe APAC — validez par mesures réelles, pas par la distance seule. Surdimensionnez le stockage NVMe : journaux d'agents, caches et instantanés APFS consomment vite la marge ; un palier M4 supérieur ou une option SSD plus large coûte moins cher qu'une panne de service le vendredi soir. La même discipline s'applique si vous cohabitez avec des runners Xcode sur la même machine : réservez de l'espace disque pour les pipelines qui tournent en parallèle.

Pourquoi macOS et le Mac mini M4 collent à ce schéma

Ce déploiement repose sur un Unix de bureau fiable : SSH natif, launchd intégré, trousseaux et outils Apple sans couche d'émulation. Le Mac mini M4 combine une faible consommation en veille (souvent de l'ordre de quelques watts), un silence compatible avec un rack « proche du bureau », et Apple Silicon avec Neural Engine pour les charges mixtes agents / outillage. macOS apporte Gatekeeper, SIP et FileVault en option, ce qui réduit la surface d'attaque par rapport à beaucoup de piles Windows équivalentes ; le volume réduit et l'absence de ventilateur bruyant abaissent le coût total sur la durée. Si vous voulez héberger cette passerelle sur du matériel qui tient la charge sans bruit ni surprise, le Mac mini M4 reste le point d'entrée le plus rationnel — découvrez les offres bare metal via la bannière ci-dessous.