La passerelle OpenClaw fonctionne déjà sur un hôte, mais vous devez accueillir plusieurs dépôts métier sur la même machine : vous redoutez les collisions de répertoires, les jetons mélangés, une surface MCP trop large et des tâches cron qui dérivent silencieusement après une mise à niveau. Cet article donne aux responsables plateforme et automatisation une base de production signable : sept points révèlent les risques multi-projets réels, un tableau comparatif clarifie « une passerelle, plusieurs workspaces » contre « plusieurs instances », puis un runbook en six étapes. En le lisant avec les articles sur la triage auth production, la santé du cron et les listes blanches MCP, vous évitez de prendre des problèmes de configuration pour de la qualité de modèle.
OpenClaw excelle lorsque modèles, outils et canaux convergent vers une passerelle observable. Lorsque plusieurs lignes métier partagent une même frontière de processus, l'échec typique n'est pas « le modèle s'est dégradé » mais une explosion combinée permissions, cron et MCP. La liste suivante est une auto-vérification pré-lancement : plus vous cochez de cases, plus vous devez contractualiser répertoires, utilisateurs d'exécution et listes blanches d'outils au lieu de compter sur la seule discipline.
Traiter un workspace comme « un simple renommage de dossier » : sans aligner comptes de service, journaux et sauvegardes, les montées ou rollbacks livrent des pannes fantômes où seuls certains projets lisent une ancienne configuration.
Activer par défaut tout le catalogue MCP : plus il y a d'outils, plus les blocages et timeouts aval augmentent ; une jam bloque la boucle d'événements partagée et hausse la latence perçue sur tous les canaux.
Enregistrer le cron deux fois sous systemd et LaunchAgent : après upgrade, doubles déclenchements ou disparitions silencieuses sont souvent attribuées à « OpenClaw instable » alors que la frontière de service est floue.
Mélanger jetons passerelle et clés fournisseur dans une même colonne : le diagnostic écrase les champs et alterne Unauthorized avec « No API key » ; séparez les axes d'audit comme dans l'article auth.
Absence d'ordre d'acceptation fixe après upgrade : ne regarder que l'UI sans openclaw doctor laisse tourner des configurations semi-compatibles pendant des semaines après changement de schéma.
Rivaliser avec la CI sur ports et répertoires temporaires : sur Mac distants ou builders partagés, écoute par défaut du gateway et caches de build sans isolation provoquent occupations de ports sporadiques et famine I/O.
Ne pas formaliser « qui peut élargir la liste blanche » : ajouts ad hoc sans audit fracturent le principe de moindre exposition.
La cause commune est de prendre la passerelle pour un proxy inverse sans état : elle conserve credentials, sous-processus et planifications ; tout artefact semi-persistant exige un espace de noms. Les workspaces élèvent ces espaces des accords informels vers des chemins auditables et des tranches de configuration. Si des standards plateforme existent déjà, intégrez OpenClaw aux mêmes tickets de changement, fenêtres de rollback et runbooks d'astreinte au lieu d'une black-box réservée à l'équipe IA.
En vous alignant sur l'article listes blanches MCP, mappez outils et domaines métier et décidez si un même outil peut avoir des périmètres de paramètres différents par projet ; sinon scindez workspaces ou instances. L'idée « stdio MCP est plus léger » est piégeuse : sous forte concurrence, le cycle de vie des sous-processus et la courbe RSS deviennent sensibles—surveillez et plafonnez comme le prescrivent les guides ops.
Avant de placer un gateway multi-projets sur un Mac distant 24/7 ou un serveur Linux de production, demandez si la même machine porte compilations lourdes ou forte charge disque. Si oui, esquissez marge disque du gateway, fenêtres cron et pics CI sur une même frise grossière, sinon vous verrez durablement « CPU bas mais P99 épouvantable ». Le tableau suivant transforme les débats d'architecture en support de revue.
Pas de solution universelle : les petites équipes itèrent vite derrière une passerelle et des listes blanches strictes ; en croissance, les charges fortement isolées vont souvent sur des instances et les dépôts faiblement couplés sur des workspaces. Lors des revues, fixez trois SLA : traçabilité des changements, rayon d'explosion des pannes, durée de fenêtre de mise à niveau.
| Dimension | Une passerelle + plusieurs workspaces | Plusieurs instances (ports/services) | Découpage physique par machine |
|---|---|---|---|
| Force d'isolement | Frontières config et répertoires ; processus et rythme d'upgrade partagés | Isolation de processus ; rollback indépendant | Maximum ; coût et exploitation les plus élevés |
| Coût opérationnel | Faible à moyen ; listes blanches et discipline de changement obligatoires | Moyen ; surveillance et sauvegardes dupliquées | Élevé ; adapté forte conformité ou multi-locataire |
| Modes de défaillance typiques | Surface d'outils trop large bloque la boucle partagée | Confusion ports, jetons et unités systemd | Fragmentation machines et dérive de configuration |
| Facilité d'audit | Moyenne ; dépend des champs de logs pour séparer projets | Élevée ; grands livres par service naturels | Élevée ; clarté comptable aussi |
| Cohabitation CI | Décaler les pics et isoler les répertoires est obligatoire | On peut épingler le gateway sur des cœurs plus calmes | Hôtes dédiés, solution la plus simple |
« Le workspace n'est pas un mot-marketing de dossier : c'est écrire la surface de risque comme frontière auditable—listes blanches, cron et journaux pointent vers le même espace de noms. »
Si vous déployez un pool de builds entreprise, décalez la concurrence du gateway et les pics de signature. Les workspaces traitent les frontières de configuration, pas la contention du trousseau. Liez l'article auth : même avec plusieurs workspaces, gardez une fenêtre unifiée de rotation des jetons passerelle au lieu de secrets maison par projet.
Si vous retenez une passerelle unique multi-workspaces, mettez à jour sauvegarde et restauration : clichés réguliers des répertoires de configuration et du matériel de clés, répétition « restaurer config sans réinstaller les modèles » avant upgrade—beaucoup d'équipes ne restaurent sérieusement qu'en incident.
Si vous choisissez plusieurs instances, harmonisez sondes de santé et champs d'index des logs sinon l'astreinte saute entre hôtes et le temps de diagnostic explose. Enfin alignez-vous sur l'article cron : chaque instance aura des noms de tâches distincts pour éviter les copies de unit systemd sans WorkingDirectory adapté.
L'ordre privilégie d'abord les frontières, puis les outils, puis l'ordonnancement—aligné sur la baseline Node du guide de déploiement production pour empêcher les workspaces d'introduire un second runtime non documenté.
Fixer répertoire racine et utilisateur d'exécution par workspace : documenter chemins absolus ; interdire la dépendance au répertoire courant du shell.
Construire des familles minimales de listes blanches MCP : trois niveaux (lecture dominante/écriture faible, écriture forte, observabilité lecture seule) ; livrer le jeu le plus strict puis ouvrir par tickets.
Enregistrer le cron avec commandes d'acceptation : après chaque upgrade exécuter openclaw cron status et list et valider volumes et derniers horodatages.
Geler l'ordre de diagnostic : gateway status → channels status --probe → openclaw doctor ; ne pas rerouter les modèles en premier pour masquer la configuration.
Aligner les champs de logs sur la dimension projet : au minimum workspaceId, jobId, nom d'outil et latence pour attribuer les coûts sur hôte partagé.
Décaler les pics CI : cron lourd la nuit, sondes légères le jour pour réduire la contention disque avec xcodebuild.
#!/usr/bin/env bash set -euo pipefail openclaw gateway status || true openclaw channels status --probe || true openclaw cron status || true openclaw doctor
Rappel : si un runner auto-hébergé partage l'hôte, isolez répertoires de travail du gateway et racines runner par partitions pour que les scripts de nettoyage n'effacent pas les fichiers de session.
Pour détecter la dérive de configuration dans GitHub Actions ou GitLab CI, placez ce script dans un canari quotidien : échec ouvre ticket plutôt que d'attendre les utilisateurs. Sur Mac distant, documentez politiques veille et énergie avec la permanence du gateway sinon vous poursuivez des corrélations « stable le jour, fragile la nuit ».
Les pools multi-équipes doivent préciser qui peut ajouter des outils MCP et les seuils de revue sécurité préalables—sans cela davantage de workspaces ne résistent pas à une clé passe-partout. Le design s'achète ; les contrats organisationnels doivent précéder.
Les problèmes de permissions affichent souvent « un sudo et tout redevient vert » : utilisateur de service et propriétaires de répertoires divergent. Séparez comptes de service et comptes humains break-glass, documentez escalade temporaire et rollback dans le runbook. Plus il y a de workspaces, plus il faut éviter des UID divergents par projet qui rendent backups et collecte de journaux ingérables.
Pour le cron suivez l'article cron : après upgrade vérifiez d'abord que les anciennes tâches subsistent sans double inscription avant nouvelles fonctionnalités. L'échec « silencieux » du cron domine souvent le crash—journalisez codes de sortie et histogrammes de durée.
Attention : ne placez pas les clés fournisseur production en clair dans des chemins lisibles par plusieurs workspaces ; la moindre privilège va sur ACL système de fichiers et gestionnaires de secrets, pas sur convention verbale.
Pour MCP comme dans l'article liste blanche : timeouts et plafonds de concurrence par outil ; traitez les blocages aval comme incidents de premier rang. Les courbes ops diffèrent entre MCP stdio et HTTP—nuées de sous-processus courts contre microservices avec pools.
Comme l'article CI centrée SSH, la passerelle doit s'appuyer sur les journaux SSH et réserver VNC au break-glass. Si automatisation UI et gateway cohabitent sur Mac distant, surveillez aussi pics GPU et mémoire cumulant les P99.
Enfin inscrivez « moindre privilège + plus petite surface d'outils » dans le guide d'astreinte : quand les ajouts temporaires sont permis, qui approuve, quelle fenêtre, comment tracer la preuve. Sans cela l'équipe par défaut suit celui qui crie le plus—audit et stabilité souffrent.
Pour alignement interne ; calibrez les seuils selon nombre d'outils et trafic des canaux.
Les ordinateurs portables subissent veille, mises à jour et travail bureau qui cassent un gateway résident ; les machines purement scripts manquent souvent de diagnostic visuel Apple. En plaçant OpenClaw multi-workspaces sur un Mac distant dédié, toujours en ligne et joignable en SSH, vous contractualisez permissions, cron et frontières MCP au lieu de dépendre de qui n'a pas verrouillé l'écran. Face à environnements partagés instables ou machines empruntées, vous payez sur la durée en dérive de configuration, clés mélangées et contention des ressources : fenêtres incident plus longues, files d'automatisation qui dictent le planning, finance confrontée à effort machine inexplicable. Pour équipes qui veulent entrée SSH stable, paliers disque clairs et profils de nœuds reproductibles, la location cloud Mac Mini NodeMini s'intègre souvent mieux au platform engineering ; comparez niveaux et tarifs dans les tarifs Mac Mini location puis complétez avec le centre d'aide.
Reliez ce runbook aux niveaux d'automatisation internes : L1 un workspace ; L2 plusieurs workspaces avec baseline de liste blanche partagée ; L3 listes blanches par métier ; L4 plusieurs instances—chaque montée impose des garde-fous de surveillance plutôt que du périmètre oral. Seule cette lecture commune aligne coût locatif et expérience de file d'attente entre finance et développement.
Les workspaces conviennent pour séparer configuration et répertoires dans un même domaine de confiance ; plusieurs instances pour isolement fort ou rythmes d'upgrade indépendants. Si vous n'avez que plusieurs dépôts partagés par l'équipe, commencez par workspaces plus liste MCP minimale.
Lisez l'article cron du site et confrontez à openclaw cron status / list ; utilisez openclaw doctor pour les changements de schéma. Pour l'aide plateforme consultez le centre d'aide cloud Mac.
Comparez niveaux dédiés et bande passante sortante dans les tarifs Mac Mini location, puis ajoutez concurrence, cron et nombre d'outils MCP à votre liste d'acceptation avec ce runbook pour transmission à l'astreinte.