OpenClaw Staging vs Production : isolation de profil launchd sur Mac mini loué pour 2026

Ingénieurs plateforme qui livrent OpenClaw sur un seul Mac mini Apple Silicon loué finissent par affronter une crise qui sonne banal : les expériences staging empoisonnent les passerelles de production parce que les deux mondes lisent le même répertoire d’état, partagent le même préfixe de label LaunchAgent ou lient le même port localhost. Ce runbook 2026 montre comment donner à l’hôte deux personnalités auditables—préfixes d’accueil OpenClaw distincts, labels plist non conflictuels, choix explicites de LimitLoadToSessionType et une matrice numérique de précédence des variables d’environnement que votre astreinte peut grep dans un incident. Lisez-le avec secrets et sécurité plist, headless vs session GUI et récupération de passerelle pour que les redémarrages ne deviennent pas des boucles d’autodécimation.

VmMac fournit des nœuds à Hong Kong, Japon, Corée, Singapour et États-Unis avec SSH et VNC optionnel ; l’isolation de profil reste votre contrat.

Deux personnalités sur un hôte sans mémoire partagée

Traitez staging et production comme deux flottes qui partagent par hasard l’alimentation et le NVMe. Cela signifie des racines de configuration séparées, des chemins de log séparés et des clés API séparées—jamais « la même clé mais un autre modèle ». Quand les équipes trichent avec des symlinks staging vers prod, vous recréez le pire des agents de build partagés : files d’attente instables, limites de débit inexpliquées et diffs de minuit non fiables. Encodez un schéma de nommage qui survit aux humains fatigués : OPENCLAW_HOME_STG et OPENCLAW_HOME_PRD exportés uniquement dans le dictionnaire EnvironmentVariables du plist LaunchAgent, pas dans les profils shell que les sessions SSH interactives pourraient muter.

• Garde-fou chiffré : conservez au moins 40 Go de NVMe libre lorsque les deux passerelles tournent ; les files SQLite locales et les caches de modèles se disputent le même budget disque.
• Garde-fou chiffré : plafonnez le fan-out HTTP sortant combiné à 30 clients en vol sauf mesure de marge—le trafic en rafale est la façon polie de faire tomber la prod depuis le staging.
• Garde-fou chiffré : faites tourner les jetons staging tous les 14 jours même si les fournisseurs ne l’exigent pas ; les anciens identifiants staging deviennent des pièges de copier-coller.

Disposition des répertoires : état, logs et discipline « ne jamais synchroniser ça »

Placez les deux racines sous /usr/local/var/openclaw-* ou un autre préfixe opéré—pas le Bureau, pas les chemins proches d’iCloud. Répliquez la même disposition sur Hong Kong, Japon, Corée, Singapour, États-Unis pour que vos scripts de diagnostic rsync se comportent pareil. Couplez cette section avec logs structurés et rotation afin que le staging ne remplisse pas le disque et n’expulse pas les logs prod pendant les longs week-ends.

Labels LaunchAgent, ThrottleInterval et LimitLoadToSessionType

Utilisez des labels DNS inversé distincts tels que com.yourorg.openclaw.gateway.stg vs com.yourorg.openclaw.gateway.prd ; ne différenciez jamais seulement par la casse. Alignez ThrottleInterval sur le pire temps de redémarrage issu de la récupération de passerelle afin que launchd ne relance pas une plist staging cassée pendant que la prod vide encore les sockets. Quand le staging nécessite du débogage assisté par GUI, fixez LimitLoadToSessionType pour inclure Aqua sur ce plist seulement ; gardez la production headless pour réduire la surface TCC.

Ports, liaisons loopback et hygiène StandardOutPath

Liez le staging à 127.0.0.1:18789 et la production à 127.0.0.1:18790 comme paire par défaut documentée—ajustez si votre standard interne réutilise déjà ces ports, mais gardez la répartition impair/pair mémorable pour l’astreinte. Assurez-vous que StandardOutPath et StandardErrorPath ne pointent jamais vers le même fichier pour les deux agents ; les logs entrelacés détruisent la causalité lors des enquêtes de déduplication webhook.

Matrice de précédence des variables d’environnement (antisèche opérateur)

Source	Priorité staging	Priorité production	Astuce incident
Plist LaunchAgent EnvironmentVariables	Gagne sur le shell pour les démons	Gagne sur le shell pour les démons	Toujours afficher avec launchctl print gui/$(id -u)/com...stg
~/.zshenv pour SSH	S’applique aux humains seulement	Ne doit pas écraser le plist	Retirer les secrets des shells
.env dans le répertoire d’état	Autorisé pour valeurs par défaut locales	Liste blanche stricte	Jamais de symlink entre stg/prd

Quand les ingénieurs veulent « réutiliser la plist prod avec une autre clé API », résistez avec une politique diff d’abord : chaque plist staging doit différer de la production d’au moins cinq clés visibles—ports, labels, chemins de log, racines d’état et molets de throttle—pour que les erreurs de cp accidentelles apparaissent immédiatement en revue de code.

Playbook fumée et retour arrière en sept étapes avant chaque promotion

1. Décharger la plist staging ; vérifier le port fermé via lsof.
2. Exporter une archive tar de l’état staging pour la forensic—pas pour réutilisation en prod.
3. Lancer un webhook synthétique contre l’écoute staging avec un jeton canary.
4. Comparer les fichiers plist entre régions ; zéro diff attendu sauf hostnames.
5. Charger la plist prod ; vérifier que l’endpoint de santé renvoie 200 sous 12 secondes.
6. Rejouer la profondeur de file connue de prod ; alerter si > baseline par 3×.
7. Documenter le rollback : décharger prd, restaurer la révision plist précédente depuis un tag git.

Liens croisés de récupération de passerelle et pièges d’automatisation connus

Les retours terrain soulignent que le redémarrage de passerelle invoqué depuis une session agent peut quitter sans relance propre sous certaines configurations launchd—concevez les promotions pour que les humains redémarrent d’abord les passerelles en heures ouvrées. Attachez votre runbook au guide d’installation et de déploiement afin que « réinstaller le service » soit épinglé par version, pas par folklore.

Contrôles de cohérence sur cinq régions pour profils doubles

Exécutez la même répétition de promotion en sept étapes chaque semaine dans chaque région VmMac. La divergence signifie souvent des fautes de chemin ou un encodage plist spécifique à la locale, pas un comportement cloud mystérieux. Gardez les exemples du centre d’aide alignés sur les clés plist réellement stockées dans votre dépôt.

FAQ : OpenClaw staging et production sur un Mac mini

Puis-je partager un binaire Node ? Oui—épinglez la version globalement ; ne partagez jamais les répertoires d’état.

Le staging doit-il appeler de vraies API fournisseurs ? Préférez les bac à sable ; si impossible, limitez le débit et étiquetez explicitement le trafic.

Qui possède le retour arrière ? Votre équipe plateforme ; VmMac ne restaure pas les plists.

Pourquoi le Mac mini M4 convient encore au métal double-passerelle en 2026

Le Mac mini Apple Silicon offre un débit mono-locataire prévisible pour deux processus passerelle, des files SQLite locales et des assistants modèle en arrière-plan sans voisins bruyants. Louer par région permet de garder le staging près des développeurs pendant que la production épouse la sortie SaaS amont—sans acheter deux bureaux physiques par ingénieur. Le flux SSH-first de VmMac vous permet d’appliquer les changements plist via les mêmes pipelines git que le code applicatif, puis de les valider identiquement à Hong Kong, Japon, Corée, Singapour et États-Unis. Traitez l’isolation launchd comme qualité produit, pas détail de plomberie—alors OpenClaw cesse d’être une démo et devient infrastructure.