openclaw reproductible, un daemon utilisateur qui survit à la coupure SSH, la visibilité du port 18789 avec la bonne adresse d’écoute, et un fumée test channels dont les horodatages concordent avec les journaux. Ce guide propose une séquence de portes à copier-coller pour Singapour, Tokyo, Séoul, Hong Kong, US Est ou US Ouest sans filet GUI.
Cinq malentendus qui coûtent la première heure sur Mac cloud headless
Sans interface graphique, les incidents se compressent dans un terminal unique. L’erreur coûteuse est de confondre joignabilité réseau, survie du processus et autorisation de canal sous un seul feu vert. Les cinq signatures ci-dessous associent chaque classe d’échec à une reproduction minimale afin de figer les faits avant de poursuivre modèles ou plugins.
Installation réussie équivaut à Gateway toujours actif : un code retour nul signifie fichiers posés sur disque, pas forcément un daemon utilisateur installé. Sans onboard --install-daemon, la fin de session SSH peut terminer la session au premier plan qui tenait Gateway.
curl local réussi équivaut à canal public réussi : le loopback sur 127.0.0.1:18789 ne prouve ni l’entrée webhook, ni les groupes de sécurité, ni l’adresse d’écoute, ni l’upgrade WebSocket derrière un reverse proxy.
Canaux connectés impliquent réponse obligatoire : pairing, règles de mention, listes blanches et politiques requireMention créent de faux positifs. Archivez channels status plus la sonde avec horodatage avant les boucles de réinstallation.
CPU bas signifie machine inactive : l’automatisation headless attend souvent l’IO disque, le DNS ou la latence du premier jeton. Sous 16 Go, la pression swap peut coexister avec un CPU calme et des timeouts de canal.
Changer de région répare tout : si membres, région d’API modèle, distant Git et emplacement du Mac divergent, passer de Tokyo à Singapour ne change souvent que le RTT, pas la latence des outils ni la dérive du daemon.
Découpez l’heure en 0–15 minutes chaîne d’outils, 15–45 minutes daemon et Gateway, 45–60 minutes fumée canal. Chaque tranche se termine par des instantanés texte horodatés pour que le prochain ingénieur reprenne sans mémoire fragile. Si Docker contre bare metal reste ouvert, lisez l’article comparatif interne en parallèle car le mappage de volumes redéfinit la persistance des répertoires d’état.
Dans les contextes réglementés, notez quels comptes stockent les jetons et combien de temps les journaux avec métadonnées personnelles sont conservés, afin d’aligner traitement et conservation avec le RGPD. Cela ne remplace pas un pare-feu, mais impose des rôles d’accès propres dès la première heure.
Si plusieurs squads partagent une machine, convenez de répertoires home séparés, labels launchd distincts et chemins de logs séparés avant le premier canal productif. Sinon le trafic de sondes et les expériences manuelles se mélangent dans un journal inexploitable en post-mortem.
Documentez si les commandes d’administration ne passent que par des comptes break-glass. Le sudo ad hoc dans des shells interactifs crée une dérive que doctor signale en symptôme sans attribuer automatiquement la cause racine.
Enfin, un ticket par classe d’erreur plutôt qu’un ticket fourre-tout avec dix hypothèses parallèles : cela paraît bureaucratique mais évite en semaine deux la question coûteuse de quelle configuration était valide lorsque le premier canal était vert.
Mac cloud headless contre Mac bureau contre VPS Linux : matrice de rayon d’explosion
La documentation OpenClaw couvre macOS, Linux et Windows via WSL2, mais les questions de production commencent par la proximité avec les chaînes Apple. Un Mac cloud bare metal headless achète du Apple Silicon dédié et une montée réseau plus propre pour des sockets Gateway longues durées. Un Mac bureau est pratique jusqu’au sommeil, au Wi-Fi itinérant et aux interruptions humaines. Un VPS Linux est économique jusqu’à ce que des étapes macOS-only imposent une seconde machine. Le tableau est volontairement grossier pour aligner les parties prenantes en quelques minutes.
| Dimension | Mac cloud bare metal headless | Mac bureau | VPS Linux |
|---|---|---|---|
| 24/7 et veille | always-on fournisseur | veille et capot | always-on solide |
| Proximité toolchain Apple | même hôte pour tâches type Xcode | haut mais bruyant en partage | faible sans plan de données Mac |
| Réseau et ports | groupes de sécurité et IP publique familiers | NAT et uplink grand public | groupes matures, WebSocket à soigner |
| Habitudes headless | chemins launchd standardisables | mélange GUI et CLI gêne la passation | systemd mature, sémantique différente |
| Adéquation première heure | meilleure pour boucle install-daemon-canal | ok pour expériences solo | ok sans charge données macOS |
La première heure tient en trois faits : qui écoute, qui atteint depuis l’extérieur, que reste-t-il après la coupure SSH.
En location jour sur six régions, la matrice évite d’optimiser la latence en ignorant le placement de la toolchain. Les équipes qui notarisent ou automatisent lourdement le navigateur regrettent souvent d’avoir séparé Gateway du plan de données. Louer jour ou semaine puis verrouiller le mois après check-list aligne trésorerie et risque.
La propriété opérationnelle diffère : un Mac bureau vit souvent sous un seul compte développeur avec historique sudo ad hoc, un Mac cloud se traite comme du bétail avec un playbook de reconstruction. Cela impacte OpenClaw car configuration Gateway, jetons et rétention de logs dépendent de la disposition du home. Un utilisateur d’automatisation dédié réduit les mises à niveau interactives accidentelles et facilite les audits.
Consignez les régions des fournisseurs d’API : des appels majoritairement US avec un Mac à Tokyo peut rester acceptable pour la plan de contrôle sans confondre avec le RTT membre-vers-Mac. Prouvez d’abord la boucle locale, mesurez ensuite de bout en bout après stabilisation des canaux.
Pour la finance, la location jour est un instrument de mesure : choisissez la région du premier dialogue utilisateur réel, exécutez la check-list, répétez optionnellement si conformité ou métriques l’exigent. Documentez les démarrages à froid du daemon après reboot car certains fournisseurs recyclent agressivement.
Les équipes conformité peuvent attacher captures des règles de groupe de sécurité et chemins proxy au même ticket que la sortie doctor pour que des auditeurs externes retracent la causalité sans shell interactif.
Quand vous branchez plus tard la CI, précisez quelles étapes restent sur le Mac cloud et lesquelles sur des runners Linux afin d’éviter une double vérité pour les jetons. Chaque machine supplémentaire double coût et surface d’incohérence PATH, proxy et magasin TLS.
Notez enfin quels rôles peuvent faire tourner les clés SSH et combien de temps les journaux de session subsistent pour les post-mortems, afin que l’incident ne parte pas d’artefacts déjà effacés.
Précisez aussi si l’administration ne transite que par des jump hosts et quelles listes d’IP s’y rattachent, pour que les durcissements ultérieurs ne déplacent pas furtivement l’accès aux canaux.
Portes de la chaîne d’outils : chaque étape copiable et comparable
Les chemins courants combinent installeur officiel ou paquet npm global avec onboarding. Sur hôte headless, évitez tutoriels copiés à moitié : capturez node -v, which openclaw, openclaw --version et gateway status sur un seul écran. Si mélange sudo et utilisateur, vérifiez PATH et préfixes npm globaux sur volumes persistants. Quand doctor signale une dérive, corrigez une classe de problème à la fois pour garder des journaux attribuables.
node -v curl -fsSL https://openclaw.ai/install.sh | bash openclaw onboard --install-daemon openclaw doctor openclaw gateway status openclaw channels status --probe
Après le squelette, validez 18789 par couches : loopback hôte, sonde intra-VPC si utile, puis entrée publique via reverse proxy avec upgrade WebSocket. Chaque échec reçoit son propre ticket plutôt qu’une étiquette réseau vague. Pour limites reload chaud contre redémarrage, relisez l’article Gateway reload avant de modifier remote dans la même heure.
Les variables d’environnement injectées seulement dans le profil shell interactif ne se propagent pas automatiquement aux jobs launchd ; exportez un jeu minimal dans la plist ou un script wrapper explicite. Même discipline pour les proxys HTTP d’entreprise : curl peut réussir pendant que les clients WebSocket longue durée échouent sans listes NO_PROXY correctes. Conservez des traces curl verbeuses en rédigeant les jetons avant ticket.
Quand des outils lourds navigateur arrivent plus tard, surveillez l’IO disque et la marge libre de base pour éviter un resize d’urgence le lendemain. Après Gateway stable, croisez l’article outils lourds.
Remarque : des archives horodatées doctor et channels valent mieux que deviner des rotations de jetons.
Runbook en six étapes des versions figées à la fumée canal
Figez les versions sur le ticket : majeur Node, version paquet OpenClaw et liste des canaux, pas de montée silencieuse.
Installez la chaîne et vérifiez le chemin global : juste après installation, contrôlez which et openclaw --version hors chemins temporaires.
Installez le daemon et figez l’état : après onboard, archivez gateway status et le nom d’unité launchd.
Contrôles 18789 en couches : loopback d’abord, puis groupes fournisseur, puis upgrade externe via reverse proxy.
Poussez doctor au vert : rattachez les correctifs doctor au même ticket que les diffs de configuration pour éviter la dérive multiple.
Fumée minimale des canaux : status et sonde, puis un vrai message test et alignement des horodatages de logs.
Trois garde-fous d’astreinte et cadrage six régions en location jour
Boîte temporelle installation : si node -v et un chemin openclaw répétable ne se stabilisent pas en environ vingt minutes, stoppez le travail canal parallèle et revenez à l’image de base et aux permissions.
Ligne d’eau disque : dépendances et journaux mangent vite les disques d’entrée ; gardez environ trente pour cent libres pour l’état Gateway, évitez d’empiler des jobs lourds navigateur sous environ dix pour cent libre.
Cadence de reconnexion : limitez à environ six tempêtes de reconnexion complètes par canal la première heure pour réduire les refroidissements côté fournisseur ; sauvegardez un diff de configuration avant chaque essai.
Attention : les seuils numériques sont des repères de communication d’ingénierie, pas des SLA matériels.
Les hotspots bureau et uplinks grand public combattent les sockets longue durée. Le VPS Linux évite la veille mais déplace le travail lourd macOS. Le Mac cloud bare metal headless permet de valider installation, daemon et canaux sur Apple Silicon réel avec montée stable, puis d’étendre la durée de location après check-list. La location cloud Mac mini MESHLAUNCH reste souvent le meilleur compromis opérationnel pour les équipes qui couplent plan de contrôle d’automatisation et charges natives Apple sans parier sur un portable fragile unique.
Traitez la location jour comme instrument de mesure : choisissez la région du premier dialogue réel, exécutez la check-list, répétez si conformité ou latence l’exigent, documentez le démarrage à froid après reboot ; si dérive, ajoutez un reboot contrôlé dans la fenêtre de location avant engagement mensuel.
Les revues sécurité demandent si SSH headless affaiblit la posture face à un VDI géré : durcissez les clés, désactivez mot de passe, limitez sudo, traitez les jetons OpenClaw comme secrets de production avec notes de rotation. Cela ne remplace pas l’argument économique : le bare metal prévisible bat la variance matérielle grand public quand les canaux doivent tenir la nuit.
Quand les journaux portent des données personnelles, définissez finalité, rôles d’accès et durées de conservation compatibles RGPD ; ce n’est pas un substitut aux règles pare-feu mais impose une minimisation dès la fumée initiale.
Nouvelle session, openclaw gateway status, lisez les journaux du daemon. Voir installation et dépannage Gateway et tarifs.
Exécutez status et sonde, puis lisez connecté sans réponse. Aide : centre d’aide.
Prouvez d’abord le bare metal. Pour les conteneurs suivez Docker contre install.sh pour l’acceptation volumes et ports.