Il y a deux semaines, OpenClaw avait 9 000 étoiles sur GitHub. Aujourd’hui, il en a 183 000. Entre-temps, toute une industrie artisanale est apparue. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Un site comparatif recense 33 fournisseurs et la liste continue de s’allonger. Les wrappers OpenClaw envahissent TrustMRR. DigitalOcean a lancé un déploiement en un clic. Cloudflare l’a adapté en environnement Workers. Des gens achetaient des Mac Minis pour faire tourner des agents IA personnels chez eux.

Si vous souhaitez auto-héberger dans le cloud, la configuration la plus courante est un VPS Hetzner à 5 dollars avec 2 vCPUs et 4 Go de RAM, Docker Compose et une clé API. Lancez l’assistant d’intégration, connectez-le à Anthropic ou OpenRouter, reliez Telegram. Terminé en trente minutes. Ou achetez un Mac Mini, posez-le sous votre bureau et appelez-le votre JARVIS personnel. Le M4 consomme sept watts au repos et fait aussi office de machine d’inférence locale si vous optez pour le modèle Pro 64 Go.

Ces deux approches fonctionnent pour un seul agent. Mais quand j’ai commencé à construire OpenClaw.rocks, l’objectif était d’offrir le moyen le plus fiable et le plus sécurisé d’héberger OpenClaw à grande échelle, tout en gardant l’expérience simple pour l’utilisateur. Cela nécessitait des fondations différentes.

Pourquoi j’ai choisi Kubernetes

J’ai auparavant géré l’infrastructure blockchain chez Binance, y compris la sécurisation des nœuds Bitcoin. Quand votre métier est de maintenir des charges de travail critiques isolées, observables et récupérables à grande échelle, vous développez des convictions fortes sur le fonctionnement de l’infrastructure. Kubernetes est ce en quoi j’ai confiance pour cela.

OpenClaw est une application mono-utilisateur. C’est un assistant personnel, pas une plateforme multi-tenant. Si vous voulez exécuter des agents pour dix personnes, il vous faut dix instances. Pour cent personnes, cent instances. Chacune avec sa propre configuration, ses propres secrets, son propre stockage, ses propres frontières réseau. Les exigences d’isolation à elles seules excluent toute solution inférieure à une véritable orchestration de conteneurs.

Je ne vais pas prétendre que Kubernetes est simple. Ce n’est pas le cas. Pour un seul agent, c’est un excès absurde. Mais pour gérer de nombreux agents pour de nombreuses personnes, il résout des problèmes qu’aucune autre solution ne résout aussi bien. Et je pense que toute entreprise qui finira par exécuter des agents OpenClaw à grande échelle arrivera à la même conclusion.

Un isolement réellement appliqué. Chaque agent s’exécute dans son propre namespace avec une NetworkPolicy qui refuse tout par défaut. L’agent A ne peut pas communiquer avec l’agent B. L’agent B ne peut pas accéder aux secrets de l’agent A. Ce n’est ni une convention ni une bonne pratique. C’est appliqué par le runtime de conteneurs et le CNI. Sur un VPS partagé avec Docker Compose, l’isolement réseau entre conteneurs nécessite des règles iptables manuelles que personne ne maintient.

Des limites de ressources qui empêchent les défaillances en cascade. Un agent OpenClaw avec automatisation du navigateur peut consommer 3 cœurs CPU et 6 Go de mémoire si on le laisse faire. Sur un VPS avec quatre agents, un processus Chromium incontrôlable tue les trois autres. Kubernetes applique des limites de CPU et de mémoire par conteneur. Un agent qui atteint son plafond n’affecte pas ses voisins.

Auto-réparation sans SSH. Quand un processus sur un VPS plante, quelque chose doit le détecter et le redémarrer. systemd le fait, mais uniquement pour l’hôte. Docker Compose a des politiques de redémarrage, mais elles ne couvrent pas les dix autres choses qui peuvent mal tourner : OOM kills, pannes de nœuds, problèmes de stockage. Kubernetes redémarre les conteneurs défaillants, replanifie les pods quand les nœuds tombent et exécute des health probes qui détectent les problèmes au niveau applicatif, pas seulement les arrêts de processus.

Mise à l’échelle sans approximation. Nous exécutons les charges de travail des agents sur un pool de nœuds dédié. Quand la demande augmente, le cluster autoscaler ajoute des nœuds. Quand elle diminue, les nœuds sont drainés et retirés. Nous ne maintenons pas une flotte d’instances VPS pré-provisionnées en espérant avoir correctement dimensionné. L’infrastructure s’adapte à la charge réelle.

État déclaratif sans dérive. L’intégralité de la configuration d’un agent réside dans une seule custom resource : le modèle, les canaux, les limites de ressources, les règles réseau, le stockage, le contexte de sécurité. Pas d’historique SSH à reconstituer, pas de modifications manuelles à tracer, pas de dérive de configuration entre ce que vous pensez être en exécution et ce qui l’est réellement.

Rien de tout cela n’a d’importance pour un agent sur une seule machine. Tout cela compte quand vous êtes responsable de la fiabilité des agents d’autres personnes.

L’Operator

Kubernetes fournit les briques de base. Un Operator est ce qui les rend utilisables.

Sans Operator, déployer une instance OpenClaw sur Kubernetes signifie écrire onze ressources à la main : Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Avec un Operator, il n’en faut qu’une :

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent
spec:
  envFrom:
    - secretRef:
        name: my-api-keys
  storage:
    persistence:
      enabled: true
      size: 10Gi

L’Operator surveille cette custom resource et crée tout le reste. C’est une boucle de contrôle : à chaque modification d’une ressource associée, et au moins toutes les cinq minutes comme filet de sécurité, il compare l’état souhaité à l’état réel et réconcilie la différence. Si quelqu’un supprime une NetworkPolicy, elle revient. Si un Deployment dérive, il est corrigé. Supprimez la custom resource, et les owner references cascadent le nettoyage. Pas de Services orphelins, pas de PVCs résiduels.

Aujourd’hui, nous le publions en open source : github.com/OpenClaw-rocks/k8s-operator.

La sécurité par défaut, pas par checklist

SecurityScorecard a trouvé 135 000 instances OpenClaw exposées sur Internet public la semaine dernière. CVE-2026-25253 a démontré l’exécution de code à distance en un clic via l’exfiltration de tokens gateway. Gartner a recommandé aux organisations de le bloquer entièrement. 341 skills malveillants ont été trouvés dans le registre ClawHub.

C’est la réalité de l’exploitation d’agents IA en 2026. La configuration par défaut d’OpenClaw écoute sur 0.0.0.0 sans authentification. Sur un VPS sans pare-feu correctement configuré, vous êtes à un scan de ports de donner un accès shell à votre serveur à un inconnu. Nous avons couvert toute l’étendue de la crise de sécurité et expliqué pourquoi même un token gateway ne suffit pas.

L’Operator adopte l’approche inverse. La sécurité est structurelle, pas optionnelle :

  • Non-root par défaut. UID 1000, toutes les capabilities Linux supprimées, seccomp RuntimeDefault. Un webhook de validation rejette toute spec qui définit runAsUser: 0. Il faudrait supprimer le webhook pour exécuter en tant que root.
  • Isolement réseau par défaut. NetworkPolicy deny-all par défaut sur chaque instance. Entrée : même namespace uniquement. Sortie : DNS et HTTPS uniquement. Tout le reste est bloqué sauf ouverture explicite.
  • RBAC au moindre privilège. Chaque instance dispose de son propre ServiceAccount avec un Role qui n’accorde que get et watch sur sa propre ConfigMap. Un agent ne peut pas lire les secrets, la configuration ou l’état d’un autre agent.
  • L’Operator lui-même s’exécute en tant qu’UID 65532 (distroless nonroot), système de fichiers racine en lecture seule, toutes les capabilities supprimées, HTTP/2 désactivé pour atténuer CVE-2023-44487.

Tout cela est actif par défaut. Vous en bénéficiez sans y penser.

L’automatisation du navigateur en sidecar

Les agents OpenClaw peuvent naviguer sur le web. Sur un VPS, cela signifie exécuter un processus Chromium à côté de l’agent et espérer qu’ils ne se disputent pas les ressources. L’Operator gère cela comme un véritable sidecar :

spec:
  chromium:
    enabled: true
    resources:
      requests:
        cpu: "250m"
        memory: "512Mi"
      limits:
        cpu: "1000m"
        memory: "2Gi"

L’Operator ajoute un conteneur Browserless Chromium au pod, connecte le Chrome DevTools Protocol sur le port 9222, injecte CHROMIUM_URL=ws://localhost:9222 dans le conteneur principal et donne à Chromium son propre contexte de sécurité (UID 999, capabilities supprimées), ses propres limites de ressources et un /dev/shm en mémoire. Les deux conteneurs communiquent via localhost à l’intérieur du pod. Pas de saut réseau, pas de Service supplémentaire, pas d’exposition de sécurité. Sur OpenClaw.rocks, nous activons le sidecar Chromium par défaut pour chaque instance.

Contenu du dépôt

Écrit en Go 1.24 avec controller-runtime (pattern Kubebuilder). Sous licence Apache 2.0.

  • CRD complète avec un schéma de validation OpenAPI de 127 Ko
  • Helm Chart (également en tant qu’artefact OCI sur GHCR)
  • Overlays Kustomize pour ceux qui le préfèrent
  • Dashboard Grafana et alertes Prometheus dans docs/monitoring/
  • Tests E2E sur Kind dans la CI
  • Builds multi-architecture (amd64/arm64)

L’Operator est également référencé sur OperatorHub et Artifact Hub, vous pouvez donc le découvrir et l’installer via les registres que vous utilisez déjà.

Installation :

helm install openclaw-operator \
  oci://ghcr.io/openclaw-rocks/charts/openclaw-operator \
  --namespace openclaw-operator-system \
  --create-namespace

Déployer un agent :

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent
spec:
  config:
    raw:
      agents:
        defaults:
          model:
            primary: "anthropic/claude-sonnet-4-20250514"
  envFrom:
    - secretRef:
        name: my-api-keys
  chromium:
    enabled: true
  storage:
    persistence:
      enabled: true

Automatisation du navigateur, stockage persistant, isolement réseau, surveillance de santé, déploiements automatiques de configuration. Une seule ressource. kubectl apply.

Pourquoi l’open source

J’ai construit cet Operator pour résoudre mon propre problème. Je gère une plateforme d’hébergement pour les agents OpenClaw et j’avais besoin d’outils Kubernetes de niveau production. L’Operator est le résultat de ce travail.

Mais je pense aussi que toute entreprise exécutant des agents OpenClaw à grande échelle finira sur Kubernetes et sera confrontée aux mêmes problèmes que moi : les paramètres de sécurité par défaut, le câblage des NetworkPolicy, le sidecar Chromium, les déploiements de configuration. L’écosystème a deux semaines et est déjà fragmenté. Chacun résout ces problèmes indépendamment.

Le coût de la construction de logiciels tend vers zéro. Et comme je l’ai soutenu dans OpenClaw est le nouveau Linux, l’ouverture empêche la fragmentation. L’Operator n’est pas mon avantage concurrentiel. Si quelque chose l’est, c’est la marque et la confiance que je construis en partageant un travail comme celui-ci. Et si même cela ne tient pas, je prends plaisir à construire, écrire et partager. Cela me suffit. Garder l’Operator propriétaire signifierait que chaque équipe infrastructure redécouvre les mêmes écueils que moi. C’est du gaspillage, pas un avantage concurrentiel.

Nous utilisons cet Operator en production. Chaque agent sur OpenClaw.rocks passe par lui.

Le code est sur github.com/OpenClaw-rocks/k8s-operator. Issues et PRs bienvenues.

Si vous préférez ne pas le gérer vous-même, c’est exactement ce à quoi sert OpenClaw.rocks.