Due settimane fa, OpenClaw aveva 9.000 stelle su GitHub. Oggi ne ha 183.000. Nel frattempo, è nato un intero settore artigianale. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Un sito di confronto conta 33 provider e la lista continua a crescere. I wrapper di OpenClaw stanno invadendo TrustMRR. DigitalOcean ha rilasciato un deploy in un clic. Cloudflare lo ha adattato in un runtime Workers. Le persone compravano Mac Mini per eseguire agenti IA personali a casa.

Se desidera fare self-hosting nel cloud, la configurazione più comune è un VPS Hetzner da 5 dollari con 2 vCPU e 4 GB di RAM, Docker Compose e una chiave API. Avvii il wizard di onboarding, lo colleghi ad Anthropic o OpenRouter, connetta Telegram. Fatto in trenta minuti. Oppure compri un Mac Mini, lo metta sotto la scrivania e lo chiami il Suo JARVIS personale. L’M4 consuma sette watt a riposo e funziona anche come macchina di inferenza locale se sceglie il modello Pro da 64 GB.

Entrambe le soluzioni funzionano per un singolo agente. Ma quando ho iniziato a costruire OpenClaw.rocks, l’obiettivo era offrire il modo più affidabile e sicuro per ospitare OpenClaw su larga scala, mantenendo l’esperienza semplice per l’utente. Questo richiedeva fondamenta diverse.

Perché ho scelto Kubernetes

In passato gestivo l’infrastruttura blockchain presso Binance, inclusa la protezione dei nodi Bitcoin. Quando il proprio lavoro consiste nel mantenere carichi di lavoro ad alto valore isolati, osservabili e recuperabili su larga scala, si sviluppano opinioni forti su come l’infrastruttura debba funzionare. Kubernetes è ciò in cui ripongo la mia fiducia.

OpenClaw è un’applicazione per singolo utente. È un assistente personale, non una piattaforma multi-tenant. Se si vogliono eseguire agenti per dieci persone, servono dieci istanze. Per cento persone, cento istanze. Ciascuna con la propria configurazione, i propri segreti, il proprio storage, i propri confini di rete. I soli requisiti di isolamento escludono qualsiasi soluzione inferiore a un’orchestrazione di container adeguata.

Non sosterrò che Kubernetes sia semplice. Non lo è. Per un singolo agente, è un eccesso assurdo. Ma per gestire molti agenti per molte persone, risolve problemi che nient’altro risolve altrettanto bene. E credo che qualsiasi azienda che finirà per eseguire agenti OpenClaw su larga scala arriverà alla stessa conclusione.

Isolamento realmente applicato. Ogni agente gira nel proprio namespace con una NetworkPolicy che per default nega tutto. L’agente A non può comunicare con l’agente B. L’agente B non può raggiungere i segreti dell’agente A. Questa non è una convenzione o una best practice. È applicata dal runtime dei container e dal CNI. Su un VPS condiviso con Docker Compose, l’isolamento di rete tra container richiede regole iptables manuali che nessuno mantiene.

Limiti di risorse che prevengono guasti a cascata. Un agente OpenClaw con automazione del browser può consumare 3 core CPU e 6 GB di memoria se lo si lascia fare. Su un VPS con quattro agenti, un processo Chromium fuori controllo uccide gli altri tre. Kubernetes applica limiti di CPU e memoria per container. Un agente che raggiunge il suo tetto non influenza i vicini.

Auto-riparazione senza SSH. Quando un processo su un VPS si blocca, qualcosa deve accorgersene e riavviarlo. systemd lo fa, ma solo per l’host. Docker Compose ha policy di riavvio, ma non coprono le altre dieci cose che possono andare storte: OOM kill, guasti dei nodi, problemi di storage. Kubernetes riavvia i container falliti, ripianifica i pod quando i nodi muoiono ed esegue health probe che rilevano problemi a livello applicativo, non solo la terminazione dei processi.

Scalabilità senza tirare a indovinare. Eseguiamo i carichi di lavoro degli agenti su un pool di nodi dedicato. Quando la domanda aumenta, il cluster autoscaler aggiunge nodi. Quando diminuisce, i nodi vengono drenati e rimossi. Non manteniamo una flotta di istanze VPS pre-provisionate sperando di aver dimensionato correttamente. L’infrastruttura si adatta al carico reale.

Stato dichiarativo senza deriva. L’intera configurazione di un agente risiede in un’unica custom resource: il modello, i canali, i limiti di risorse, le regole di rete, lo storage, il contesto di sicurezza. Nessuna cronologia SSH da ricostruire, nessuna modifica manuale da tracciare, nessuna deriva di configurazione tra ciò che si pensa sia in esecuzione e ciò che realmente lo è.

Niente di tutto questo conta per un agente su una macchina. Tutto conta quando si è responsabili del funzionamento affidabile degli agenti di altre persone.

L’Operator

Kubernetes fornisce le primitive. Un Operator è ciò che le rende utilizzabili.

Senza un Operator, il deploy di un’istanza OpenClaw su Kubernetes significa scrivere undici risorse a mano: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Con un Operator, ne basta una:

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 monitora questa custom resource e crea tutto il resto. È un loop di controllo: a ogni modifica di qualsiasi risorsa gestita, e almeno ogni cinque minuti come rete di sicurezza, confronta lo stato desiderato con quello attuale e riconcilia la differenza. Se qualcuno elimina una NetworkPolicy, questa ritorna. Se un Deployment devia, viene corretto. Eliminando la custom resource, le owner reference propagano la pulizia a cascata. Nessun Service orfano, nessun PVC residuo.

Oggi lo rilasciamo come open source: github.com/OpenClaw-rocks/k8s-operator.

Sicurezza di default, non da checklist

SecurityScorecard la scorsa settimana ha trovato 135.000 istanze OpenClaw esposte su Internet pubblico. CVE-2026-25253 ha dimostrato l’esecuzione di codice remoto con un clic tramite l’esfiltrazione di token gateway. Gartner ha raccomandato alle organizzazioni di bloccarlo completamente. 341 skill malevoli sono state trovate nel registro ClawHub.

Questa è la realtà dell’esecuzione di agenti IA nel 2026. La configurazione predefinita di OpenClaw si lega a 0.0.0.0 senza autenticazione. Su un VPS senza un firewall configurato correttamente, basta una scansione delle porte per dare a uno sconosciuto accesso shell al proprio server. Abbiamo trattato l’intera portata della crisi di sicurezza e spiegato perché anche un token gateway non è sufficiente.

L’Operator adotta l’approccio opposto. La sicurezza è strutturale, non opzionale:

  • Non-root di default. UID 1000, tutte le capability Linux rimosse, seccomp RuntimeDefault. Un webhook di validazione rifiuta qualsiasi spec che imposti runAsUser: 0. Si dovrebbe rimuovere il webhook per eseguire come root.
  • Isolamento di rete di default. NetworkPolicy deny-all di default su ogni istanza. In ingresso: solo lo stesso namespace. In uscita: solo DNS e HTTPS. Tutto il resto è bloccato a meno che non lo si apra esplicitamente.
  • RBAC a privilegio minimo. Ogni istanza ottiene il proprio ServiceAccount con un Role che concede solo get e watch sulla propria ConfigMap. Un agente non può leggere i segreti, la configurazione o lo stato di un altro agente.
  • L’Operator stesso gira come UID 65532 (distroless nonroot), filesystem root in sola lettura, tutte le capability rimosse, HTTP/2 disabilitato per mitigare CVE-2023-44487.

Tutto questo è attivo di default. Lo si ottiene senza doverci pensare.

Automazione del browser come sidecar

Gli agenti OpenClaw possono navigare il web. Su un VPS, questo significa eseguire un processo Chromium accanto all’agente e sperare che non si contendano le risorse. L’Operator gestisce tutto questo come un vero sidecar:

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

L’Operator aggiunge un container Browserless Chromium al pod, configura il Chrome DevTools Protocol sulla porta 9222, inietta CHROMIUM_URL=ws://localhost:9222 nel container principale e assegna a Chromium il proprio contesto di sicurezza (UID 999, capability rimosse), i propri limiti di risorse e un /dev/shm in memoria. I due container comunicano via localhost all’interno del pod. Nessun salto di rete, nessun Service aggiuntivo, nessuna esposizione di sicurezza. Su OpenClaw.rocks, abilitiamo il sidecar Chromium di default per ogni istanza.

Contenuto del repository

Scritto in Go 1.24 con controller-runtime (pattern Kubebuilder). Licenza Apache 2.0.

  • CRD completa con schema di validazione OpenAPI da 127 KB
  • Helm Chart (anche come artefatto OCI su GHCR)
  • Overlay Kustomize per chi li preferisce
  • Dashboard Grafana e alert Prometheus in docs/monitoring/
  • Test E2E su Kind nella CI
  • Build multi-architettura (amd64/arm64)

L’Operator è anche elencato su OperatorHub e Artifact Hub, per cui è possibile scoprirlo e installarlo tramite i registri che si utilizzano già.

Installazione:

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

Deploy di un agente:

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

Automazione del browser, storage persistente, isolamento di rete, monitoraggio della salute, rollout automatici della configurazione. Una risorsa. kubectl apply.

Perché open source

Ho costruito questo Operator per risolvere il mio problema. Gestisco una piattaforma di hosting per agenti OpenClaw e avevo bisogno di strumenti Kubernetes di livello produttivo. L’Operator è il risultato di quel lavoro.

Ma credo anche che qualsiasi azienda che esegua agenti OpenClaw su larga scala finirà su Kubernetes e dovrà affrontare gli stessi problemi che ho affrontato io: le impostazioni di sicurezza predefinite, il cablaggio delle NetworkPolicy, il sidecar Chromium, i rollout delle configurazioni. L’ecosistema ha due settimane di vita ed è già frammentato. Tutti risolvono questi problemi in modo indipendente.

Il costo di costruire software si avvicina allo zero. E come ho sostenuto in OpenClaw è il nuovo Linux, l’apertura previene la frammentazione. L’Operator non è il mio vantaggio competitivo. Se qualcosa lo è, è il brand e la fiducia che costruisco condividendo lavori come questo. E se nemmeno questo regge, mi diverto a costruire, scrivere e condividere. Questo basta. Mantenere l’Operator proprietario significherebbe che ogni team infrastrutturale riscopra le stesse insidie che ho scoperto io. Questo è spreco, non vantaggio competitivo.

Utilizziamo questo Operator in produzione. Ogni agente su OpenClaw.rocks passa attraverso di esso.

Il codice è su github.com/OpenClaw-rocks/k8s-operator. Issue e PR sono benvenute.

Se preferisce non gestirlo personalmente, è esattamente a questo che serve OpenClaw.rocks.