Un locataire, une cellule

Vous faites déjà tourner OpenClaw pour vous, et un deuxième client en veut un. Le réflexe est de l’ajouter à la passerelle existante, de lui donner sa propre session, et de traiter cette session comme la limite entre les deux. La documentation d’OpenClaw ferme cette porte dès sa première phrase, puis décrit la forme qui tient : une instance complète par locataire, supervisée par openclaw fleet.

Pourquoi une session n’est pas une frontière entre locataires

• Un opérateur authentifié dans une passerelle occupe un rôle de plan de contrôle de confiance. Ce rôle n’est pas délimité par client : un deuxième opérateur sur la même passerelle est un deuxième opérateur sur tout ce que cette passerelle atteint, pas un deuxième locataire.
• Les identifiants de session servent au routage. Ils décident dans quel contexte atterrit un message, et ils n’autorisent pas un locataire face à un autre ; donner une clé de session à chaque client procure donc un adressage propre et aucune isolation.
• Le bac à sable des agents garde son intérêt, car il réduit l’effet des contenus non fiables et de l’exécution d’outils. Ce qu’il ne fait pas, c’est transformer une passerelle partagée en frontière d’autorisation entre locataires, et la documentation le dit franchement au lieu de le laisser découvrir.
• La forme prise en charge est une cellule par locataire : chaque domaine de confiance reçoit son propre processus de passerelle, son conteneur, son arborescence d’état persistant et son identifiant de passerelle. Cela suit la règle que le modèle de sécurité de la passerelle énonce déjà : ne pas réunir dans un même processus OpenClaw, ni sous un même utilisateur système, des personnes qui ne se font pas confiance.

Le modèle de sécurité par défaut d’OpenClaw repose sur une frontière d’opérateur de confiance par passerelle, et non sur l’isolation de locataires hostiles au sein d’une même passerelle partagée.

Une cellule est un OpenClaw entier, pas une ligne de locataire

openclaw fleet appelle cellule chaque instance isolée, et une cellule est une passerelle complète dans un conteneur renforcé, avec son propre état, ses identifiants, son espace de travail, ses comptes de canaux, son jeton et un port hôte limité à la boucle locale. La CLI est elle-même un superviseur de cycle de vie côté hôte : elle enregistre les cellules dans la base d’état d’OpenClaw et demande à un moteur Docker ou Podman local de créer, inspecter, démarrer, arrêter, remplacer et supprimer leurs conteneurs. Elle ne relaie aucun message de locataire et n’ajoute aucun chemin de données applicatif partagé entre cellules, donc rien dans une cellule ne peut en adresser une autre via Fleet. Les moteurs distants sont refusés d’emblée, car les chemins de montage et les URL de boucle locale de Fleet appartiennent à l’hôte local. Chaque cellule exécute l’image officielle ghcr.io/openclaw/openclaw sur son propre réseau bridge dédié et écoute sur le port 18789 dans le conteneur, pendant que le moteur ne publie ce port que sur 127.0.0.1 et un port hôte alloué.

Les quatre commandes, et ce qu’elles conservent

• openclaw fleet create acme construit la cellule et affiche une seule fois le jeton de passerelle généré : conservez-le avant que le terminal ne défile. L’URL de boucle locale indiquée est l’endroit où ce locataire s’authentifie, puis configure ses propres identifiants de fournisseur et ses comptes de canaux, dans sa propre instance.
• openclaw fleet status acme combine la ligne de registre, l’inspection du conteneur en direct et une courte requête vers le point de santé de la cellule. Un résultat sain prouve que la passerelle répond, pas que chaque canal ou greffon configuré est prêt.
• openclaw fleet upgrade acme conserve le port hôte, les données montées, le profil de ressources, l’environnement fourni par l’opérateur et le jeton de passerelle au travers du remplacement du conteneur. La suppression en est le miroir : openclaw fleet rm acme --force garde les données du locataire, et ajouter --purge-data les efface définitivement après une vérification de confinement des chemins résolus.

L’état persistant vient d’un répertoire par locataire sous le répertoire d’état d’OpenClaw, fleet/cells/acme, monté dans le conteneur sur /home/node/.openclaw, et les valeurs OAuth courantes d’accès, de rafraîchissement et de jeton d’identité y figurent en clair dans SQLite. La conséquence est brutale : une copie de l’arborescence d’état d’une cellule est une copie des identifiants vivants de ce locataire, soit exactement le cadre que Sauvegarde et restauration d’OpenClaw applique aux archives d’une instance. Un second chemin hôte, fleet/auth-profile-secrets/acme, est monté sur /home/node/.config/openclaw pour coller au modèle de persistance décrit dans OpenClaw dans Docker, mais il ne contient que la clé de récupération des anciens identifiants chiffrés en annexe et ne chiffre rien dans la base actuelle.

L’échelle d’isolation, et les surfaces que Fleet laisse vides

Le premier barreau est le conteneur renforcé de base : toutes les capacités Linux retirées, no-new-privileges activé, limites de processus, de mémoire, de processeur et, en option, de couche disque inscriptible, montages persistants et réseaux distincts par cellule, et publication uniquement sur la boucle locale de l’hôte. Le réseau bridge laisse malgré tout la sortie réseau libre, et c’est là que les deux moteurs divergent. Une cellule Podman peut tourner avec --network internal pour bloquer la sortie tout en gardant le port de passerelle publié sur la boucle locale, ce qui est une bonne raison de lire OpenClaw avec Podman avant de choisir un moteur, alors que Docker casse ce port publié sur un réseau interne : Fleet refuse donc la combinaison et attend des règles de pare-feu hôte telles que la chaîne DOCKER-USER. Le deuxième barreau est un moteur d’isolation plus fort comme gVisor ou Kata Containers, ou des cellules placées dans des micro-machines virtuelles, ce qui relève de la configuration d’infrastructure et non d’une option de Fleet, puisque le choix de moteur désigne la CLI de conteneur et pas le moteur d’isolation OCI. Le troisième barreau est la machine séparée, pour des locataires qui ne font pas confiance au même opérateur d’hôte. Aucun barreau ne change le modèle de confiance applicatif, et aucun ne protège un locataire de l’opérateur : un administrateur de l’hôte peut inspecter la configuration et l’environnement des conteneurs, lire les données montées d’une cellule, remplacer les images ou entrer dans les conteneurs, et résister à un hôte compromis est un non-objectif assumé. Fleet s’arrête aussi bien avant le produit d’hébergement : pas de comptes de canaux partagés ni de routeur d’entrée partagé, pas de processus allégés par locataire, pas de cellules distantes sous un seul superviseur, et pas de portail en libre-service, de plan de facturation ou d’interface d’administration déléguée. Si les personnes que vous hébergez se font mutuellement confiance, la page qu’il vous faut est Le mode multi-utilisateurs d’OpenClaw, qui traite un autre problème avec d’autres valeurs par défaut.

Sur Diali

Diali héberge OpenClaw, si bien que la frontière entre locataires est tracée par la plateforme et non par vous. Chaque client fait tourner son propre assistant, avec son propre répertoire d’état plutôt qu’une part d’un répertoire commun, et la configuration d’exécution qui le pilote est générée depuis le tableau de bord et remplacée à chaque version. Cet état vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali expose ce que comprend cet assistant hébergé, et Tarifs Diali en détaille les offres.

• Une passerelle est un domaine d’opérateur de confiance, jamais une frontière entre locataires.
• Une cellule est une instance complète, avec conteneur, état, jeton et port de boucle locale.
• L’état d’une cellule contient de l’OAuth en clair : chaque copie est un identifiant.