Votre Gateway s’arrête quand votre ordinateur portable se met en veille, ou votre Agent ne peut pas lancer un outil macOS depuis Linux.
La solution la plus simple à exploiter est généralement de garder OpenClaw Gateway sur un hôte Linux durablement disponible, puis de connecter un Mac distant uniquement lorsque des tâches exigent macOS. Placez aussi le Gateway sur Mac seulement si son fonctionnement doit dépendre directement d’une session graphique, d’autorisations natives ou d’un état local propre à cette machine.
À qui s’adresse ce choix ? Aux développeurs indépendants qui veulent un service disponible sans attacher toute leur infrastructure à leur ordinateur de travail. Aux équipes de plateforme, DevOps et outils Apple qui doivent définir les responsabilités, les accès et les preuves de bon fonctionnement avant de mettre une architecture en service.
Séparer le contrôle du Gateway de l’exécution sur Mac
Pour choisir entre Linux et Mac, commencez par distinguer deux rôles qui sont souvent confondus. Le Gateway coordonne les sessions, l’authentification et l’état des canaux ; les nœuds sont des périphériques reliés au Gateway et apportent des capacités d’exécution propres à leur environnement. La documentation officielle décrit le fonctionnement des connexions distantes au Gateway et précise que les nœuds constituent des points d’exécution distincts.
Cette séparation permet d’éviter une mauvaise décision d’architecture : installer le Gateway sur un Mac ne rend pas automatiquement toute tâche plus « native », et exécuter un Agent sur un nœud Mac ne déplace pas le Gateway sur cette machine. Le routage peut rester centralisé sur Linux, tandis qu’une tâche particulière est dirigée vers le Mac qui dispose des outils et des droits nécessaires.
Dans une topologie hybride, tracez donc deux chemins plutôt qu’un seul. Le premier relie les utilisateurs ou canaux au Gateway ; le second relie le Gateway au nœud chargé d’exécuter une action. Si le résultat revient correctement, vérifiez séparément que le message a été reçu, que la bonne route a été choisie, que l’action a abouti sur le Mac et que sa sortie a été renvoyée. Un état « connecté » ne prouve pas à lui seul que toutes ces étapes fonctionnent.
**À retenir :** un nœud Mac peut fournir des capacités de la machine sans héberger le service de contrôle. Avant de déplacer le Gateway, vérifiez quelle étape de votre flux dépend réellement de macOS.
Indépendant : sortir le Gateway de l’ordinateur de travail
Si vous lancez le Gateway sur votre ordinateur portable, vous liez sa disponibilité à des choix quotidiens qui n’ont rien à voir avec le travail de l’Agent : fermeture du capot, veille, déplacement hors du réseau ou redémarrage pour une mise à jour. Vous devrez aussi conserver sur la machine de développement les identifiants et l’état nécessaires au service. Le conflit est opérationnel : vous voulez pouvoir interrompre votre poste de travail, mais le Gateway doit rester accessible.
Un hôte Linux déjà maintenu pour des services permanents est souvent un point de départ plus simple à administrer. La documentation d’installation et de déploiement du Gateway aide à vérifier les options adaptées à cet hôte ; la configuration du Gateway doit ensuite correspondre à votre mode d’exploitation. Cela ne garantit ni une meilleure disponibilité ni de meilleures performances : ces résultats dépendent de votre infrastructure et de son entretien.
Un Mac unique reste cohérent si votre travail dépend déjà étroitement de cette machine, si son environnement natif est nécessaire au contrôle lui-même et si vous acceptez que l’indisponibilité de l’hôte affecte à la fois le Gateway et l’exécution locale. À l’inverse, si le Mac sert seulement à lancer Xcode ou un outil graphique à la demande, séparer le contrôle du poste d’exécution évite de rendre le Gateway dépendant de cette session.
Le tableau ci-dessous compare les compromis d’exploitation, et non des résultats de performance mesurés. « Très adapté » signifie que le rôle correspond naturellement à la topologie ; cela ne constitue pas une promesse de disponibilité.
| Architecture | Gateway indépendant du poste | Outils macOS natifs | Charge d’exploitation | Indication de choix |
|---|---|---|---|---|
| Gateway Linux seul | Très adapté si l’hôte est maintenu pour rester disponible | Non, pas par le seul fait d’utiliser Linux | Faible si Linux appartient déjà à votre parc géré | À retenir si vos tâches ne réclament aucune capacité Mac |
| Gateway et exécution sur le même Mac | Conditionnel : le service dépend de cet hôte | Adapté aux besoins locaux de macOS | Un seul hôte, mais rôles et accès réunis | À retenir si le Gateway lui-même dépend de l’environnement Mac |
| Gateway Linux avec nœud Mac distant | Le contrôle reste séparé du poste Mac | Adapté si le nœud dispose des outils et autorisations nécessaires | Deux environnements et leur connexion à superviser | À retenir si seules certaines tâches exigent macOS |
Plateforme : réutiliser l’hôte et les règles déjà administrés
Si votre équipe possède déjà des hôtes Linux supervisés, des procédures de mise à jour et une gestion des secrets, héberger le Gateway dans cette zone permet de conserver un plan de contrôle soumis à des règles connues. Cela ne dispense pas de vérifier le réseau entre les utilisateurs, le Gateway et ses nœuds : une machine déjà administrée n’est pas nécessairement accessible depuis les bons segments, ni correctement autorisée à joindre un Mac distant.
Avant de choisir Linux, faites l’inventaire des responsabilités que votre organisation sait effectivement assurer : qui maintient le processus Gateway, où sont conservés sa configuration et son état, qui peut modifier les accès, et comment l’équipe repère une perte de connexion au nœud. La documentation des connexions distantes décrit le modèle de connexion à examiner ; elle ne remplace pas votre revue des pare-feu, des identités et des chemins réseau.
Une équipe peut également préférer le Mac comme hôte unique si son environnement impose que Gateway et exécution locale partagent une session ou un état de machine. Mais ce choix regroupe la gestion du service, le maintien du Mac et la disponibilité des outils natifs dans un même périmètre. Il est raisonnable uniquement si une personne ou une équipe est clairement responsable de ces trois éléments.
Équipe Apple : réserver le Mac aux tâches qui en ont besoin
Pour une tâche qui utilise Xcode, un outil graphique ou une fonction propre à macOS, déterminez d’abord où le processus doit réellement s’exécuter. Si le binaire, la session graphique ou l’autorisation demandée est local au Mac, le Gateway peut rester sur Linux et transmettre la tâche à un nœud Mac. La documentation de l’application macOS décrit le rôle du Mac dans ce modèle ; consultez aussi la référence des capacités des nœuds pour ne pas attribuer au Gateway les fonctions du nœud.
Il faut distinguer la présence d’un outil de l’autorisation de l’utiliser. Une commande peut être installée mais ne pas disposer des accès nécessaires ; une tâche graphique peut dépendre d’une session active ; un Agent autorisé à demander une action ne doit pas, par défaut, recevoir la permission d’exécuter toute commande locale sans contrôle. Définissez donc, pour chaque tâche, le système cible, les outils requis, l’identité autorisée et la manière de vérifier le résultat.
Cette distinction est particulièrement utile dans les équipes qui alternent développement d’applications, tests d’interface et production de médias. Un Mac peut être nécessaire pour une étape qui utilise une application ou une session native, mais pas pour le routage des demandes ni les tâches ordinaires qui s’exécutent déjà dans l’environnement Linux. Vous évitez ainsi de déplacer l’ensemble du service à cause d’une seule dépendance Apple.
Pour évaluer les modalités d’accès à un hôte Mac géré par MACGPU, vous pouvez consulter la page de configuration Mac. La présentation des solutions Mac distantes de MACGPU peut également vous aider à repérer les informations à vérifier avant de retenir un environnement. Vérifiez que l’offre et les conditions proposées correspondent à vos exigences d’administration ; ne supposez pas qu’une configuration ou une capacité particulière est incluse sans la confirmer.
Sécurité : délimiter les accès et l’impact d’un incident
Dans une architecture mixte, examinez séparément les identifiants et l’état du Gateway, le processus d’association du nœud, puis les permissions locales du Mac. La documentation officielle sur l’association des nœuds permet de vérifier le mécanisme prévu ; les règles d’approbation des commandes exécutées sont pertinentes lorsque des actions locales nécessitent un contrôle explicite.
Consignez qui peut approuver l’association, qui peut envoyer une demande d’exécution, quelles catégories d’actions sont autorisées et comment retirer l’accès lorsqu’un utilisateur ou un nœud ne doit plus intervenir. Un Gateway installé sur Mac ne supprime pas ces questions : les permissions de la machine restent à examiner, tandis que la centralisation ou la séparation des rôles ne dépend pas du nom du système d’exploitation.
Une panne doit aussi avoir un périmètre compréhensible. Si le Gateway devient indisponible, les demandes qu’il contrôle peuvent être affectées ; si le Mac ou sa session ne répond plus, les tâches qui dépendent de ce nœud sont les premières à vérifier. Distinguez ces scénarios dans vos consignes d’exploitation au lieu de traiter chaque échec comme une panne générale d’OpenClaw.
FAQ : clarifier le déploiement Linux et le nœud Mac
Le Gateway OpenClaw peut-il être installé sur Linux ?
Oui, si Linux correspond à votre environnement d’exploitation et que vous pouvez maintenir la configuration, le réseau et l’état du Gateway. Les tâches qui réclament un outil natif de macOS ne s’exécuteront pas simplement parce que le Gateway les reçoit : elles nécessitent un environnement d’exécution Mac approprié. Vérifiez la topologie et les conditions de connexion dans la documentation officielle avant de choisir le mode de déploiement.
En quoi le nœud Mac diffère-t-il du Gateway ?
Le Gateway assure des fonctions de contrôle, notamment la gestion des sessions, l’authentification et le routage. Le nœud Mac se connecte à lui pour rendre disponibles des capacités locales de la machine, selon ses réglages et ses autorisations. Le nœud n’est donc pas un second Gateway et ne remplace pas le service central ; il fournit une cible à laquelle le flux peut confier certaines actions.
Faut-il déplacer le Gateway sur Mac pour utiliser des outils macOS ?
Non, pas si seul l’environnement d’exécution requiert macOS. Vous pouvez conserver le Gateway sur Linux et connecter un Mac comme nœud pour les actions qui exigent ses outils, une session graphique ou des permissions locales. En revanche, si le Gateway lui-même doit partager un état ou une session propre au Mac, examinez un déploiement sur cette machine et prenez en charge les conséquences sur son exploitation.
Comment connecter un Mac distant à un Gateway Linux ?
Vérifiez d’abord que le chemin réseau autorisé permet aux deux composants de communiquer, puis configurez la connexion et l’authentification selon les instructions OpenClaw. Testez ensuite séparément l’association, l’appel d’une capacité du nœud et le retour du résultat. Gardez une trace de l’identité qui autorise la connexion et de la procédure permettant de retirer l’accès ; ne confondez pas connectivité réseau et droit d’exécuter des commandes.
Choisir la topologie à partir des tâches réelles
Utilisez ces embranchements pour décider, sans choisir un système par préférence générale :
- Si aucune tâche ne dépend d’un outil, d’une session ou d’une permission macOS, choisissez un Gateway Linux seul si vous disposez déjà d’un hôte administré ; sinon, choisissez l’environnement que votre équipe sait maintenir. N’ajoutez pas de Mac sans besoin d’exécution identifié.
- Si certaines tâches exigent macOS, mais que le Gateway peut rester indépendant, gardez le Gateway sur Linux et connectez un Mac comme nœud. C’est le choix par défaut pour séparer le contrôle et l’exécution.
- Si le Gateway doit lui-même partager la session graphique, les permissions natives ou l’état local du Mac, envisagez un Gateway hébergé sur Mac, puis vérifiez que la responsabilité de disponibilité et de maintenance de cet hôte est explicitement attribuée.
- Si l’équipe ne peut pas superviser deux hôtes et leur liaison, commencez par réduire le périmètre ou choisir une architecture unique que vous savez opérer. Ne mettez pas en production un nœud distant avant de pouvoir diagnostiquer qui contrôle le Gateway et qui contrôle l’exécution.
- Écrivez les tâches attendues. Pour chacune, notez si elle traite un message, appelle un service, lance une commande locale ou exige une interface graphique. Remplacez les formules vagues comme « l’Agent doit accéder au Mac » par l’outil et l’action effectivement requis.
- Repérez le processus qui doit rester disponible. Déterminez si le Gateway doit fonctionner quand votre ordinateur de travail est éteint ou en veille. Si oui, choisissez un hôte que vous pouvez maintenir sans dépendre de votre présence quotidienne.
- Associez chaque action à son environnement. Confirmez si elle doit être exécutée sur Linux ou sur macOS. Pour le Mac, vérifiez les outils présents, le contexte de session et les permissions ; ne déduisez pas ces éléments de la seule réussite de l’association.
- Définissez les frontières réseau et d’identité. Documentez les machines autorisées à joindre le Gateway et le nœud, les personnes qui peuvent approuver leur association et les identifiants qui donnent accès à chaque niveau.
- Effectuez un test de bout en bout. Envoyez une demande connue, relevez la réception par le Gateway, vérifiez la route choisie, constatez l’exécution sur la machine attendue, puis conservez la preuve du résultat renvoyé. Si une étape manque, localisez-la avant de changer toute la topologie.
- Vérifiez la reprise et le retrait d’accès. Après un redémarrage planifié ou une interruption contrôlée, observez séparément le retour du Gateway et celui du nœud. Confirmez également que l’équipe sait désassocier un Mac et révoquer les accès devenus inutiles.
Passer du choix à une architecture exploitable
Le choix le plus prudent est souvent un Gateway Linux séparé et un nœud Mac ajouté uniquement pour les tâches qui démontrent un besoin macOS. Cette organisation évite de lier le contrôle au poste de travail tout en préservant l’accès aux outils Apple ; elle ajoute toutefois un second environnement à administrer, une liaison à surveiller et des permissions Mac à encadrer. Si vos tâches ne réclament pas ces capacités, le Mac distant n’apporte pas de raison suffisante à cette complexité.
À l’inverse, un environnement Linux seul ne peut pas fournir les outils natifs macOS ; l’achat d’un Mac mobilise du matériel que vous devrez maintenir même lorsque le besoin est ponctuel. Si votre décision aboutit à un nœud Mac et que vous souhaitez éviter cet achat pour un besoin temporaire, la location d’un Mac auprès de MACGPU peut fournir un environnement d’exécution distinct du Gateway Linux. Vérifiez avant de retenir cette voie la période de location, le mode de livraison et les conditions d’accès applicables à votre tâche ; pour un usage continu et intensif ou un besoin matériel local, comparez aussi la location à un Mac détenu et administré par votre équipe.