Faire passer OpenClaw Gateway d'une démo shell à un service 24/7 sur un Mac mini M4 Pro distant échoue rarement faute de copier-coller. Les causes dominantes sont les limites Node 22, la croissance des workspaces et journaux, et les variables launchd qui divergent de votre zsh interactive. Ce guide livre une liste d'échecs, un tableau install.sh officiel contre tap Homebrew contre build manuel, un découpage disque, des snippets minimaux, six étapes et des liens primaires. Tarifs sur la page tarifs NOVAKVM, commande sur la page de commande, accès distant dans le centre d'aide. Articles liés via l'index du blog. Si des artefacts contiennent des données personnelles de test, alignez rétention et localisation avec vos obligations RGPD.
Après lecture vous classez disque, PATH launchd ou sous-dimensionnement matériel, vous savez quand figer un commit plutôt que le script, et comment combiner régions SSH avec une tête M4 Pro. Revalidez chaque commande contre le README figé.
Sans inventaire des méthodes d'installation, les équipes accumulent des CLI dupliquées. Versionnez les définitions de service avec le code applicatif pour des rollbacks lisibles. Planifiez des fenêtres de maintenance pour toute modification de plist launchd lorsque plusieurs ingénieurs SSH sur le même hôte.
Documentez aussi les destinations réseau externes : fournisseurs LLM, télémétrie et webhooks optionnels. Sans cette liste, les changements de pare-feu deviennent une loterie. Si plusieurs projets partagent l'hôte, fixez des plafonds budgétaires par équipe et des alertes sur longueur de file ou durée CPU pour éviter qu'un projet monopolise la surface.
[ SECTION_01 ] // PAIN_MAP Où OpenClaw casse sur Mac distant
- Dérive majeure Node : l'amont suppose Node 22+ ; d'anciens défauts nvm créent double contexte shell et démon.
- Journaux infinis : retries et traces remplissent le disque ; sans rotation le volume système tremble la deuxième semaine.
- Workspace mélangé aux artefacts CI : jitter IOPS ressemble à latence modèle.
- Trous PATH launchd : démarrage manuel OK, reboot KO.
- Secrets seulement en export : archéologie d'incident.
- Hôte trop petit pour l'always-on : M4 Pro et SSD généreux coûtent souvent moins que l'extinction d'incendies.
[ SECTION_02 ] // DECISION_MATRIX install.sh contre Homebrew contre manuel
Le tableau compare la répétabilité, pas la morale.
| Chemin | Quand | Notes ops |
|---|---|---|
| install.sh officiel | Baseline rapide sur hôte neuf | Archiver logs d'install et version du script |
| Tap Homebrew | Gouvernance brew mature | Churn du tap et doubles CLI |
| Clone manuel | Pin de commit ou patchs | Noter node, SHA et flags dans le runbook |
Pragmatique : boucle fermée avec le script officiel, migration vers brew ou git figé avec fenêtre parallèle.
Les architectures hybrides sont fréquentes : passerelles critiques sur bare metal dédié, expériences sur petits pools. Mesurez un SLA interne comme attente max par classe de job et revoyez les régressions chaque semaine. Sans discipline, l'économie de location disparaît dans les relances manuelles.
[ SECTION_03 ] // STORAGE_PLAN Workspace, logs, caches
Séparez caches régénérables, logs compressibles et workspaces non jetables avec frontières de secrets. Pour les démons, alertes d'espace libre minimum et propriétaires de rotation. Si CI cohabite, isolez les racines d'artefacts.
Rouvrez les liens avant chaque gel de release.
https://openclaw.ai/install.sh
https://github.com/openclaw/openclaw
Étendez la télémétrie au volume d'écriture par étape, pas seulement au temps mural. Les hôtes multi-dépôt exigent des chemins de cache explicites et des droits home propres. Les grandes organisations préfèrent un compte runner limité plutôt qu'un admin généralisé.
Les tâches médias ou Metal déplacent la courbe : M4 Pro devient gestion du risque.
Si Gateway et CI partagent la machine, anticipez collisions de fenêtres : régressions nocturnes et pics d'agent peuvent saturer CPU et mémoire ensemble. Séparez les hôtes ou décalez les créneaux. Prévoyez un nettoyage hebdomadaire documenté pour dumps temporaires et exports Canvas, sinon les gigabytes s'accumulent vite.
[ SECTION_04 ] // COMMAND_SNIPPET Snippets installation et démon
Exemples structurels seulement ; durcissez secrets et utilisateurs en production.
curl -fsSL https://openclaw.ai/install.sh | bash
node -v
openclaw onboard --install-daemon
openclaw doctor
Route brew : lisez les notes du tap et alignez Node plus CLI.
Après premier succès, snapshottez les répertoires de configuration hors secrets pour valider rapidement les nouveaux hôtes.
[ SECTION_05 ] // RUNBOOK Six étapes
- Geler le runtime : Node majeur, CLI openclaw, patch OS.
- Découper le disque : workspace, logs, cache paquets ; seuil libre et rotation.
- Préparer launchd : PATH et HOME figés ; tests cold boot et après logout.
- Stocker les secrets : flux rotatable ; interdire export seul.
- Checks santé :
openclaw doctorattaché au ticket. - Aligner matériel : finaliser sur la page de commande, vérifier page tarifs et centre d'aide.
[ SECTION_06 ] // HARD_FACTS Sources et conclusion
- install.sh : comportement = script + README au commit figé.
- Baseline Node : textes communautaires citent souvent Node 22+ ; tranchez via release notes.
- Onboarding démon : lire
--helplocal pour les flags. - NOVAKVM : Mac mini bare metal à Singapour, Japon, Corée, Hong Kong, US Est et US Ouest avec paliers M4 Pro. Sources : page tarifs, centre d'aide.
Laptop permanent et virtualisation partagée cassent le SLA via sommeil et voisins. Le bare metal Apple Silicon dédié stabilise la télémétrie.
Mesurez deux semaines de croissance des logs sur un nœud test avant d'accrocher les canaux clients. Lecture complémentaire : dépannage production et index. La location cloud bare metal Mac mini NOVAKVM convient aux passerelles multi-région avec upgrades clairs.
Gardez deux snapshots stables avant gros sauts Xcode ou Node, documentez dépendances sortantes par job pour les pare-feu, planifiez revue coûts-métriques bimensuelle avec la finance.
Répétez une panne contrôlée : arrêter le service, vérifier alertes, restaurer avec un second astreinte sans connaissance tacite.
Capturez des échantillons CPU et mémoire sous trafic agent de pointe pour ancrer les discussions capacité.
Alignez tôt noms de fichiers de logs et politiques de rotation avec votre fournisseur de logs central.
Notez les hypothèses de fuseau pour les fenêtres de maintenance afin que l'heure d'été ne brouille pas les créneaux.
Planifiez un trimestriel des extensions pour éviter plugins obsolètes et surprises d'audit.
Ajoutez une courte checklist d'offboarding pour retirer clés SSH et tokens personnels quand quelqu'un quitte l'équipe.
Liez le calendrier des changements aux cycles de soumission App Store pour éviter les upgrades gateway en pleine fenêtre critique.
Conservez l'historique des sorties de healthchecks pour repérer les dérives lentes.
Définissez des escalades si le service ne reste pas stable après deux redémarrages ratés.
Tenez des contacts fournisseur pour incidents nocturnes sans deviner.
Formez le support interne à reconnaître des chaînes de symptômes simples : CPU élevée avec faible débit suggère souvent une pression mémoire, des erreurs d'authentification soudaines pointent vers des jetons expirés, des timeouts répétés impliquent DNS ou routage. Ces garde-fous réduisent le MTTR de façon mesurable. Maintenez un schéma d'architecture à jour montrant le rôle de chaque région et l'emplacement logique des secrets sans exposer les secrets eux-mêmes.
Si vous utilisez des miroirs de paquets internes, documentez leur disponibilité et un repli vers les registres publics pour éviter qu'une panne de miroir bloque toute la chaîne. Pour les certificats TLS internes, planifiez une rotation ACME ou manuelle avec alerte avant expiration. Reliez ces pratiques aux six étapes ci-dessus pour obtenir un playbook lisible des mois plus tard.
Enfin, consignez les chemins d'escalade lorsque le service ne se stabilise pas après deux redémarrages infructueux, et programmez une revue trimestrielle des extensions installées afin d'éviter des composants obsolètes qui ouvriraient silencieusement des failles de conformité.
Ajoutez une mention explicite des locales dans les définitions de service si votre chaîne d'outils dépend du format des dates ou des chemins sensibles à la casse, afin d'éviter des divergences subtiles entre session interactive et démon.
Archivez les sorties répétées des contrôles de santé sous forme de série temporelle pour détecter tôt les dérives lentes qui ne sautent pas aux alertes binaires.
Rappelez-vous que les conditions de licence macOS et Xcode s'appliquent aussi aux hôtes loués pour CI et agents.