Lorsque OpenClaw tourne de façon fiable sur un Mac mini M4 Pro bare-metal distant à Singapour, Tokyo, Séoul, Hong Kong, US Est ou US Ouest, la prochaine crise concerne rarement le quota de modèle. Il s’agit de qui peut ouvrir la Control UI, comment atteindre le port 18789 et si un raccourci expose par erreur une surface d’administration sur Internet. Cet article propose une échelle d’exposition pratique, du loopback seul au forwarding SSH local puis reverse proxy TLS avec contrôle d’accès, relie ces choix à une matrice de placement pour des équipes distribuées, et se termine par un runbook en douze étapes prêt à coller dans un modèle de changement. Les tarifs et stocks font foi sur la page tarifs NOVAKVM, les commandes sur la page de commande, les références de politique d’accès distant dans le centre d’aide. Lisez-le avec l’article sur les canaux et le dépannage reverse proxy, l’article multi-workspace et la note SSH contre partage d’écran afin d’aligner certificats et ports pour les Webhooks et les humains.
Après lecture vous devez répondre sans improviser à trois questions. Premièrement : votre posture par défaut maintient-elle 18789 sur loopback et amène-t-elle les humains via tunnels SSH, ou avez-vous réellement besoin d’un nom d’hôte public avec TLS parce que la direction ou un fournisseur refuse les clés SSH ? Deuxièmement : si la moitié de l’équipe est en APAC et l’autre en Amérique du Nord, dans quelle ville héberger le Mac de contrôle principal pour que les allers-retours modèle, les intervenants incident et la stabilité Gateway s’alignent plutôt qu’ils ne se contredisent ? Troisièmement : comment accorder aux prestataires une fenêtre temporelle bornée avec un utilisateur macOS dédié ou un workspace afin qu’un clic erroné ne mute jamais les identifiants de production sous ~/.openclaw ? Les flux d’installation, les verbes CLI et les ports par défaut évoluent entre versions OpenClaw ; traitez les commandes comme des exemples structurels et rouvrez la documentation officielle après chaque montée de version.
[ SECTION_01 ] // TEAM_RISKS Cinq pièges et coûts cachés quand plusieurs personnes partagent un hôte OpenClaw distant
Le premier piège est d’exposer 18789 directement sur Internet public sans couche d’authentification alignée sur votre système d’identité. Les scanners remplissent les journaux de bruit, les incidents réels se perdent, et chaque astreinte dépense de l’énergie à prouver qu’un pic était bénin. Le deuxième piège est un seul utilisateur macOS partagé pour exécuter Gateway et parcourir la Control UI. Un prestataire modifie un fichier de configuration à minuit, les canaux se réacheminent silencieusement, et le lendemain matin personne n’attribue le changement car l’historique shell et les actions GUI s’entrelacent. Le troisième piège est une documentation qui dit seulement ouvrir un navigateur sans préciser si l’URL est du loopback sur le portable, du loopback sur l’hôte distant via partage d’écran, ou un nom d’hôte derrière reverse proxy. Les collaborateurs distants perdent des heures à enchaîner NAT et bastions alors que le service était sain.
Le quatrième piège est des sessions SSH fragiles. Les keepalives par défaut laissent la pause déjeuner tuer un forward local pendant que Gateway continue ; l’équipe croit à une panne et redémarre inutilement, parfois en doublon des changements risqués. Le cinquième piège est la contention disque. Quand plusieurs personnes exportent des transcripts, téléchargent de grosses pièces jointes et suivent des logs verbeux sur un volume 256 Go, l’espace libre APFS oscille près des seuils d’alerte. Gateway peut hoqueter en écrivant des logs structurés et les observateurs interprètent à tort la latence modèle. Inscrire ces pièges dans un avis de changement coûte moins cher qu’un nouveau tour de débat sur une case pare-feu.
- Ports bruts publics : bruit élevé, histoire faible pour la conformité, configuration erronée facile sous pression.
- Répertoires personnels partagés : pistes d’audit faibles pour identifiants, plugins et racines de workspace.
- URLs d’entrée ambiguës : modèles mentaux divergents entre loopback, DNS intranet et sauts bastion.
- SSH sans keepalive : coupures silencieuses ressemblant à des pannes.
- Partage logs et cache : gros téléchargements entrent en collision avec les écritures Gateway sur un seul volume.
- Opérateurs multi-régions : RTT élevée étire la validation interactive quand le Mac est loin des personnes qui cliquent.
L’accès équipe ne consiste pas à ouvrir un port. Il s’agit de nommer chaque chemin, de l’auditer et de le retirer quand le contrat se termine.
[ SECTION_02 ] // EXPOSURE_MATRIX Loopback, forwarding SSH local et reverse proxy TLS comme matrice de décision
Raisonnez en rayons de confiance plutôt qu’en noms de marque. Le palier L0 garde l’administration sur la machine elle-même ou dans une seule session de partage d’écran. L1 exige que chaque ingénieur amène le port 18789 vers le loopback de son portable via SSH. L2 termine le TLS sur un bord que vous contrôlez, en amont uniquement vers loopback ou adresses privées RFC1918. L3 expose un nom d’hôte public stable avec certificats, listes d’autorisation et fenêtres de changement explicites. La plupart des petites équipes doivent rester sur L1 ou L2 par défaut et ne promouvoir L3 que pour des démos ou des Webhooks déjà couverts par des contrôles supplémentaires.
| Dimension | A · Loopback et partage d’écran seulement | B · Forwarding de port local SSH | C · Reverse proxy TLS plus contrôle d’accès |
|---|---|---|---|
| Meilleur cas | Maintenance solo, incidents courts, pas de prestataires | Ingénieurs déjà équipés de clés SSH et d’un bastion | Direction exige cadenas navigateur, portail SSO ou démos fournisseur |
| Exposition | La plus faible, collaboration pauvre | Moyenne, dépend de l’hygiène des clés et de la politique bastion | Charge opérationnelle plus élevée pour certificats et correctifs amont |
| Auditabilité | Faible pour flux GUI seuls | Forte quand les logs bastion corrèlent aux identités | Forte quand les logs proxy mappent hôtes et IP clients |
| Six régions | Choisir le nœud le plus proche des données métier et du modèle | Choisir le nœud à RTT minimale pour la majorité des répondeurs | Garder la terminaison TLS proche du Mac pour éviter double saut TLS transfrontalier |
Si vous avez déjà séparé plusieurs workspaces et ports gateway comme dans l’article multi-workspace, le niveau d’accès doit respecter ces frontières. Les prestataires doivent atterrir sur un nom d’hôte ou un chemin sandbox qui ne peut pas atteindre accidentellement les contrôles de workspace de production, même lors d’erreurs de copier-coller pendant un incident en direct.
Par défaut, forwarding loopback SSH. Ne promouvez TLS que lorsque l’entreprise exige réellement un nom d’hôte digne de confiance pour le navigateur.
[ SECTION_03 ] // TUNNEL_AND_PROXY Syntaxe de forwarding SSH, terminaison TLS et combinaisons moindre privilège
Le forwarding local conserve l’écoute sensible sur le Mac distant pendant que chaque coéquipier utilise http://127.0.0.1:18789 sur son propre portable. Ce schéma se documente facilement, se révoque en désactivant des clés, et se standardise avec des blocs de configuration SSH par projet pour éviter de retaper des drapeaux fragiles. Quand TLS est obligatoire, terminez les certificats sur un périmètre que vous opérez, pointez l’amont vers loopback ou une interface privée, et séparez les emplacements administratifs des emplacements démo afin que durées de certificat et listes d’autorisation diffèrent. Si l’entreprise impose un client zero-trust à la place du SSH brut, conservez une sortie documentée pour qu’une panne du plan de contrôle des tunnels n’isolement pas l’astreinte.
Les flux officiels pour install.sh, les installations npm globales, openclaw onboard --install-daemon, openclaw gateway status et openclaw dashboard appartiennent à la documentation amont. Les liens ci-dessous font autorité ; rouvrez-les après chaque version adoptée.
https://docs.openclaw.ai/getting-started
https://github.com/openclaw/openclaw
ssh -N \
-o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
-L 18789:127.0.0.1:18789 \
user@novakvm-remote-host.example
La disposition disque compte encore : répertoires de logs Gateway sur des volumes à marge prévisible, gros téléchargements humains isolés des logs structurés, contrôles hebdomadaires sur configurations 256 Go lorsqu’une semaine d’exports dense approche des lignes rouges. Quand les intervenants sont loin du Mac, répétez redémarrages et contrôles de statut pour que la mémoire musculaire ne dépende pas d’un retour UI subseconde.
Ajoutez une fiche d’une page pour chaque nouvelle habilitation : workspace cible, durée de session maximale, niveau MFA requis et un responsable production nommé qui signe. Notez aussi qui commande les certificats TLS, quelles IP clients sont autorisées au reverse proxy et combien de temps les journaux d’accès sont conservés, afin que l’audit interne et les contrôles externes voient les mêmes faits et que les exceptions informelles ne deviennent pas inexplicables après un trimestre.
[ SECTION_04 ] // RUNBOOK Douze étapes vers un accès Gateway et Control UI auditable
- Geler l’échelle : documenter L0 à L3, propriétaires, actions interdites et contacts de rollback sur une page.
- Vérifier la sortie CLI officielle : capturer
openclaw gateway statusdans une fenêtre de maintenance et l’attacher au dossier de changement. - Séparer utilisateurs ou workspaces : jamais de droits d’écriture partagés entre prestataires et identités de production.
- Publier la config SSH : standardiser
LocalForward,IdentityFileet keepalives ; interdire de lier les forwards à toutes les interfaces. - Uniformiser les étapes navigateur : le runbook commence par SSH puis liste explicitement
http://127.0.0.1:18789. - Ajouter TLS seulement si nécessaire : dédier un nom d’hôte, amont vers loopback, activer les journaux d’accès.
- Renforcer la couche applicative : listes IP, jetons statiques ou portail SSO plutôt qu’URL secrète seule.
- Simuler des déconnexions : tuer un tunnel local et vérifier la récupération en cinq minutes.
- Surveiller les seuils disque : alertes sur
~/.openclawet racines de logs ; les hôtes 256 Go méritent une revue humaine hebdomadaire. - Noter six régions : pondérer villes opérateurs, régions modèle et résidence des données puis choisir le total le plus bas.
- Évaluer la capacité parallèle : quand un débogage lourd entre en collision avec un Gateway toujours actif, comparer les ressources parallèles sur la page tarifs à la lutte pour un seul graphique CPU.
- Revue trimestrielle : échantillonner journaux proxy et SSH pour empreintes client inconnues.
[ SECTION_05 ] // DATA_FAQ Chiffres de référence, six régions, FAQ
Les éléments suivants sont des conventions de terrain pour planification et runbooks, pas des garanties sur votre build. Réconciliez ports et drapeaux avec la documentation OpenClaw après chaque mise à niveau.
- Port Gateway par défaut : le dépannage commun ancre souvent sur 18789 ; si vous changez l’adresse ou le port, mettez à jour favoris, sondes et captures partout.
- Keepalive SSH : coupler
ServerAliveInterval=30avecServerAliveCountMax=3réduit les coupures silencieuses sur chemins internationaux longs ; ajoutez toutefois des contrôles de santé au niveau processus. - Durée de vie TLS : des certificats plus courts sur noms d’hôte démo réduisent l’impact si une clé fuit et que l’automatisation échoue.
- RTT inter-régions : quand le Mac est en APAC mais que les répondeurs cliquent surtout depuis US Est, même des validations de redémarrage simples s’allongent ; colocalisez l’hôte de contrôle principal avec la majorité si possible.
FAQ :
- Q : Publier 18789 sur Internet avec seulement un mot de passe ?R : Traitez cela comme dernier recours ; empilez TLS, listes et identités auditables puis passez un examen sécurité explicite.
- Q : Prestataire ne jette qu’un coup d’œil, on saute SSH ?R : Préférez des identités bornées en lecture seule et tunnelisez encore via le tissu d’accès d’entreprise quand c’est possible.
- Q : Lien avec les canaux Webhook ?R : Les canaux répondent au trafic public entrant ; cet article répond aux consoles humaines ; fusionnez la politique certificats et proxy dans un même ticket.
- Q : M4 contre M4 Pro ?R : Les opérations légères passent souvent sur M4 ; multi-workspace stable plus debug bureau atterrit plutôt sur les configurations M4 Pro décrites sur la page tarifs.
Le partage d’écran seul peine avec bande passante, pistes d’audit structurées et opérateurs concurrents. Les ports publics bruts peinent avec conformité et bruit de scanners. Le matériel de bureau seul peine avec pics transfrontaliers courts et chemins réseau prévisibles. Pour les équipes qui combinent OpenClaw, CI iOS et automatisation d’agents IA sur Apple Silicon de production avec une histoire claire sur l’ouverture humaine de Gateway et Control UI, la location de Mac mini bare-metal NOVAKVM est en général le meilleur ajustement opérationnel : six régions, matériel exclusif, validation journalière ou hebdomadaire élastique avant état mensuel stable, M4 Pro haute mémoire et capacité parallèle optionnelle quand les incidents s’empilent. Lors du prochain point d’accès, écrivez la route par défaut SSH loopback d’abord et ne promouvez TLS qu’avec un propriétaire nommé. Cette phrase évite plus de surprises de minuit qu’une règle pare-feu supplémentaire.