2026 OpenClaw sur Mac Mini loué RunMini : OPENCLAW_HOME en instances séparées versus modèles non interactifs — isoler prod et lab, puis fusionner la ronde d’inspection
« Sur un Mini loué partagé par plusieurs locataires logiques, la passerelle OpenClaw cesse d’être un jouet personnel : elle devient une ligne de production où chaque expérience Skills ou modèle doit rester reproductible et réversible, faute de quoi une équipe paie la dette d’une autre équipe le lundi matin. »
Qui : plusieurs locataires logiques sur un Mini loué. Problème : prod et lab dans le même OPENCLAW_HOME, ou secrets collés en SSH interactif. Livrable : matrice split versus gabarit, récit rechargement passerelle et secrets, ronde unique doctor + statut + CI, points A B C.
Voir multi-instance ports, prod/lab launchd, semver rollback, hub OpenClaw, installation.
Frictions typiques du multi-locataire longue durée
- État partagé : un home unique mélange verrous et jetons ; le lab nocturne bloque prod.
- TTY copié en prod : chemins utilisateur et secrets hors coffre dans l’historique.
- Bruit d’alertes : trois sondes séparées masquent le SLA réel.
Matrice décisionnelle : instances séparées ou gabarits non interactifs
| Critère | Deux OPENCLAW_HOME + deux ports |
Modèles plist / env rendus par CI |
|---|---|---|
| Isolation d’état | Maximale : fichiers et bases disjoints. | Forte si chaque voie garde son répertoire ; le gabarit évite surtout la dérive procédurale. |
| Coût opérationnel | Deux supervision launchd permanentes, ports documentés pare-feu. | Rendu idempotent depuis Git ; idéal quand le lab est souvent jeté. |
| Quand choisir | Passerelles prod et lab concurrentes plusieurs semaines. | Besoin d’aligner chaque déploiement sur un hash plist connu. |
Ces deux voies complètent l’isolation des ports et le digest CI : le split matérialise la frontière contractuelle entre trafic client et bac à sable ingénieur sur plusieurs semaines, tandis que le gabarit versionné garantit un bootstrap sans TTY où chaque déploiement rejoue exactement le hash plist validé en intégration.
Rechargement « chaud » de la passerelle et discipline des secrets (niveau récit)
En prod, « rechargement » signifie redémarrages bornés : vous modifiez la surface de configuration documentée pour la passerelle, vous validez avec openclaw doctor et des instantanés de statut, puis vous appliquez le plus petit rebond de processus que votre build tolère — souvent un seul LaunchAgent — afin que les sockets et le matériel TLS se recalent sans surprise. Toute modification de port d’écoute, de chemins de certificats ou d’identité amont mérite une fenêtre de changement explicitée, et non une simple surveillance de fichiers en arrière-plan.
Les secrets obéissent à une autre cadence : jetons, clés de signature et PAT étroits résident dans des fichiers compagnons chmod 600, le trousseau ou des variables injectées par plist, sur le modèle décrit pour repository_dispatch et pour les captures avant upgrade. Les rotations suivent un calendrier et les montées de version semver, car une rotation précipitée pendant un lot de webhooks peut mélanger deux flux locataires sur un même hôte RunMini.
Une note interne « passerelle plus secrets » gagne à lister trois colonnes : clé nécessitant redémarrage complet, clé remplaçable par simple swap de sidecar, cas exigeant un nouveau plist contrôlé par launchctl print sur le bloc EnvironmentVariables.
Ronde fusionnée : un seul message au lieu de trois sondeurs
Au lieu de trois minuteurs qui inondent Slack, installez un LaunchAgent unique avec un ThrottleInterval raisonnable — voir équité launchd — qui exécute openclaw doctor puis les contrôles de statut dans le home production, répète la séquence pour le laboratoire, agrège les échecs CI sur une fenêtre glissante, et n’envoie qu’un digest JSON par intervalle vers votre observabilité ou un webhook OpenClaw. C’est l’extension naturelle du guide multi-instance, enrichie des auto-contrôles passerelle.
Fixez des titres d’alerte stables, plafonnez la taille du corps JSON et appliquez un backoff lorsque l’observateur amont est indisponible : l’astreinte lit une carte à sections plutôt qu’un mur de sondes redondants.
Étapes minimales reproductibles et points de contrôle de retour arrière
Prérequis : Silicon, @openclaw/cli selon installation, deux labels launchd.
- A (prévol). Fichier daté :
node -v, semver CLI,which openclaw,ProgramArguments, ports — cf. rollback gateway. - Arbres + ports. Répertoires prod/lab, ports documentés catalogue pare-feu.
- Lab non interactif.
OPENCLAW_HOMElab, onboard/init par fichiers ou flags, pas de secrets dans l’historique. - launchd. Labels distincts, PATH npm global, logs séparés ;
lsofsur LISTEN. - B (lab seul).
bootoutlabel lab, restore ou wipe arbre lab, rejouer 3–4 depuis A. - Ronde. Un agent, un digest quand prod+lab+CI sont verts.
- C (CLI globale). Si
npm install -g @openclaw/cli@latestcasse tout, repin semver A, reload les deux plists, rediffopenclaw status.
Repères citables
- A B C : prévol, lab seul, CLI globale.
- Deux passerelles : deux paires home+port documentées.
- Un digest / fenêtre pour la fatigue d’alerte.
Synthèse
Les instances OPENCLAW_HOME séparées donnent l’isolation la plus nette lorsque prod et lab tournent en parallèle pendant des semaines ; les modèles non interactifs réduisent la dérive quand le lab est recréé souvent mais que la prod doit rester calée sur un plist connu. Dans les deux cas, associez rechargement prudent, discipline des secrets, ronde fusionnée et points A B C pour garder un Mac Mini loué RunMini exploitable par plusieurs équipes sans chaos nocturne.
Capacité Apple Silicon pour doubles passerelles OpenClaw
Pour héberger deux homes, des plists rendues par CI et une ronde d’inspection unique, comparez les forfaits puis ouvrez Achat : le tunnel public démarre sans connexion obligatoire pour une location longue durée. SSH, capacité et bonnes pratiques : Centre d’aide et Blog.
Achat public : démarrage sans compte jusqu’aux options console.