2026 : isolation OpenClaw dev, staging et prod sur un Mac mini loué (LaunchAgents, ports, secrets)
Les équipes livrent des automatisations OpenClaw sur des hôtes Mac mini M4 loués à Hong Kong, au Japon, en Corée, à Singapour et aux États-Unis pour garder le même macOS que sur laptop—mais rien ne corrompt la confiance plus vite qu’un prompt staging qui réécrit les skills MCP de prod. Ce guide couvre (1) pourquoi un seul mini mérite trois cloisons dures, (2) une matrice blast-radius qui quantifie les effets de bord, (3) un contrat de dossiers et ports grep-friendly, (4) un motif LaunchAgent répétable sous launchd, (5) comment séparer secrets et logs JSONL sans dupliquer les GPU, et (6) une checklist preflight avant fusion. Liens : concurrence d’agents, secrets et trousseau, diagnostic JSONL.
Pourquoi trois environnements sur un mini Apple Silicon battent le « dossier unique YOLO »
Les finances voient les environnements comme des lignes de facture ; la plateforme voit des domaines de défaillance. Un LaunchAgent qui touche à la fois aux webhooks Slack et à l’état Terraform prod est à un merge du désastre. Couper dev / staging / prod sur une boîte coûte peu car la marge CPU sur M4 est large—ce qui coûte cher, c’est le partage de fichiers négligent. L’isolation offre des rollbacks indépendants, des soak tests réalistes sans toucher aux webhooks clients et des pistes d’audit qui séparent « Sarah essaie un skill » de « le bot facturation a tiré ».
À mesure que l’équipe grandit, affichez la RACI à côté du tableau—personne ne doit déduire les IAM des noms de dossiers. Violation : figer les déploiements et revenir au playbook upgrade/rollback avant de debugger le code.
- Garde-fou numérique : garder au moins 20 Go d’espace APFS libre par racine d’environnement pour que les pics JSONL pendant les tests de charge ne bloquent pas les autres agents.
- Garde-fou humain : ne réutilisez pas le même canal Slack pour alertes staging et incidents prod—le bruit entraîne l’ignorance des astreintes.
- Garde-fou automatisation : plafonner staging
maxConcurrentTasksà la moitié de prod jusqu’à ce que les quotas API tiennent une semaine.
Matrice blast-radius : ce que chaque environnement peut toucher
| Environnement | Effets de bord autorisés | Interdit sans ticket | Périmètre typique des clés API |
|---|---|---|---|
| Dev | Branches git locales, projets SaaS bac à sable | Export PII clients | Miroirs lecture seule ou PAT courts |
| Staging | Graphe de skills complet sur données clonées | Changements DNS prod | Stripe testmode séparé + rôle AWS non-prod |
| Prod | Workflows clients, webhooks billing | Compilateurs expérimentaux | Rôles moindre privilège + rotation trimestrielle |
Publiez cette matrice à côté du diagramme d’architecture pour que les nouvelles recrues ne déduisent pas les permissions des seuls noms de dossiers.
Contrat dossiers et ports qu’on peut taper sans réfléchir
Créez trois dossiers frères comme ~/openclaw-dev, ~/openclaw-staging, ~/openclaw-prod—ne imbriquez pas staging dans prod. Répliquez les mêmes sous-dossiers (config, skills, logs, tmp) pour garder les scripts support identiques. Liez les passerelles à 127.0.0.1 sur des ports espacés : par exemple dev 18789, staging 18799, prod 18809—les intervalles absorbent les forwards de debug en binôme.
Documentez sur le wiki interne cinq colonnes : nom d’environnement, chemin absolu, port TCP, label LaunchAgent, utilisateur Unix propriétaire. La réponse à « quel plist est coincé ? » doit être un seul grep.
Motif LaunchAgent : un plist par environnement, pas un plist géant
Trois fichiers distincts du type com.yourorg.openclaw.dev.plist, ...staging.plist, ...prod.plist. Chaque plist définit WorkingDirectory, EnvironmentVariables pour un PATH non standard, StandardOutPath/StandardErrorPath vers l’arborescence logs de cet env. Gardez ThrottleInterval à 10 secondes au début pour éviter que les boucles de crash martèlent les fournisseurs.
Squelette d’exemple (raccourcissez les chemins d’installation) :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>Label</key><string>com.example.openclaw.staging</string>
<key>WorkingDirectory</key><string>/Users/automation/openclaw-staging</string>
<key>ProgramArguments</key><array>
<string>/opt/homebrew/bin/openclaw</string>
<string>gateway</string>
<string>--port</string><string>18799</string>
</array>
<key>RunAtLoad</key><true/>
<key>KeepAlive</key><true/>
</dict></plist>
127.0.0.1 et placez l’accès distant derrière tunnel SSH ou proxy de périmètre revu—n’exposez jamais les ports passerelle bruts sur Internet public.
Secrets, logs et rotation sans contamination croisée
Stockez les clés API dans des entrées trousseau séparées ou des fichiers .env en 0400, un par environnement. Quand vous faites tourner les clés prod, staging ne doit pas lire le même chemin « temporairement »—ce raccourci devient permanent. Pour les logs, préfixez chaque événement JSONL avec env=staging (ou équivalent) et séparez les noms de fichier pour que les jobs de rotation ne tronquent pas l’historique prod en chassant le bruit dev.
Câblez des health checks par environnement vers http://127.0.0.1:<port>/healthz (ou équivalent passerelle) comme dans les motifs de probes. Les seuils diffèrent : dev peut fluctuer ~5 % pendant les expériences ; prod page après deux échecs consécutifs.
Checklist preflight avant promotion des skills en prod
- Diff configs : le staging
openclaw.json(ou équivalent) égale prod sauf clés explicitement listées. - Replay à sec : rejouer les 50 derniers événements de type prod via staging avec charges anonymisées.
- Vérifier ports :
lsof -nP -iTCP -sTCP:LISTENmontre uniquement les listeners loopback prévus. - Disque :
df -haffiche au moins 20 Go libres sur le volume APFS qui héberge les logs prod. - Serveurs MCP : chaque manifeste d’outil pointe vers des répertoires de travail distincts.
- Répétition rollback : pratiquer
launchctl unload/ load sur le plist prod pendant une fenêtre de maintenance. - Validation : initiales du reviewer sur le ticket—l’automatisation mérite la même rigueur qu’un déploiement applicatif.
FAQ
Prod doit-il tourner en root ? Non—comptes de service dédiés avec ACL fichiers battent root à chaque fois ; root complique TCC et l’audit.
Partager un runtime Node ? Les versions peuvent coïncider, mais NODE_OPTIONS et préfixes npm globaux restent par environnement pour éviter les pièges PATH de l’article Homebrew.
Et GitOps ? Miroiter les branches (main, staging, dev) et mapper vers des dossiers avec clones en lecture seule si possible—voir versionnement config.
Pourquoi l’empreinte Mac mini ProxyMac reste adaptée au multi-env OpenClaw isolé
Une fois les environnements cloisonnés, un seul Mac mini M4 offre encore la mémoire unifiée pour des passerelles concurrentes, un macOS natif identique aux laptops et une facturation prévisible sur HK / JP / KR / SG / US sans pics CapEx. Utile quand staging compile des paquets Swift pendant que prod répond aux webhooks. Comparez les niveaux sur la page tarifs, lisez le centre d’aide pour les motifs d’accès distant et gardez VNC sous la main quand launchctl refuse de s’expliquer dans les logs texte.
Isoler les agents, puis monter la concurrence
OpenClaw sur Apple Silicon M4 · HK / JP / KR / SG / US