Acum două săptămâni, OpenClaw avea 9.000 de stele pe GitHub. Astăzi are 183.000. Între timp, a apărut o întreagă industrie. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Un site de comparație numără 33 de furnizori și lista continuă să crească. Wrapper-ele OpenClaw invadează TrustMRR. DigitalOcean a lansat un deploy cu un singur clic. Cloudflare l-a adaptat ca runtime Workers. Oamenii cumpărau Mac Mini-uri pentru a rula agenți AI personali acasă.

Dacă doriți să faceți self-hosting în cloud, cea mai comună configurație este un VPS Hetzner de 5 dolari cu 2 vCPU-uri și 4 GB RAM, Docker Compose și o cheie API. Rulați asistentul de configurare, conectați-l la Anthropic sau OpenRouter, legați Telegram. Gata în treizeci de minute. Sau cumpărați un Mac Mini, puneți-l sub birou și numiți-l JARVIS-ul dumneavoastră personal. M4 consumă șapte wați în repaus și funcționează ca mașină de inferență locală dacă optați pentru modelul Pro cu 64 GB.

Ambele variante funcționează pentru un singur agent. Dar când am început să construiesc OpenClaw.rocks, obiectivul era să ofer cel mai fiabil și sigur mod de a găzdui OpenClaw la scară largă, păstrând totul simplu pentru utilizator. Acest lucru necesita o fundație diferită.

De ce am ales Kubernetes

Am gestionat anterior infrastructură blockchain la Binance, inclusiv securizarea nodurilor Bitcoin. Când treaba ta este să menții workload-uri de mare valoare izolate, observabile și recuperabile la scară largă, dezvolți opinii puternice despre cum ar trebui să funcționeze infrastructura. Kubernetes este ceea ce am încredere pentru asta.

OpenClaw este o aplicație pentru un singur utilizator. Este un asistent personal, nu o platformă multi-tenant. Dacă doriți să rulați agenți pentru zece persoane, aveți nevoie de zece instanțe. Pentru o sută de persoane, o sută de instanțe. Fiecare cu propria configurație, propriile secrete, propriul spațiu de stocare, propriile limite de rețea. Cerințele de izolare singure exclud orice soluție sub o orchestrare de containere adecvată.

Nu voi argumenta că Kubernetes este simplu. Nu este. Pentru un singur agent, este o exagerare absurdă. Dar pentru a rula mulți agenți pentru mulți oameni, rezolvă probleme pe care nimic altceva nu le rezolvă la fel de bine. Și cred că orice companie care va ajunge să ruleze agenți OpenClaw la scară largă va ajunge la aceeași concluzie.

Izolare care este efectiv aplicată. Fiecare agent rulează în propriul namespace cu o NetworkPolicy care blochează totul implicit. Agentul A nu poate comunica cu Agentul B. Agentul B nu poate accesa secretele Agentului A. Aceasta nu este o convenție sau o bună practică. Este aplicată de runtime-ul containerelor și CNI. Pe un VPS partajat cu Docker Compose, izolarea rețelei între containere necesită reguli iptables manuale pe care nimeni nu le întreține.

Limite de resurse care previn defecțiunile în cascadă. Un agent OpenClaw cu automatizare de browser poate consuma 3 nuclee CPU și 6 GB de memorie dacă îl lași. Pe un VPS cu patru agenți, un proces Chromium scăpat de sub control ucide celelalte trei. Kubernetes aplică limite de CPU și memorie per container. Un agent care atinge plafonul nu afectează vecinii.

Auto-reparare fără SSH. Când un proces pe un VPS se blochează, ceva trebuie să observe și să-l repornească. systemd face asta, dar doar pentru host. Docker Compose are politici de repornire, dar nu acoperă celelalte zece lucruri care pot merge prost: OOM kills, defecțiuni de noduri, probleme de stocare. Kubernetes repornește containerele eșuate, reprogramează pod-urile când nodurile cad și execută health probe-uri care detectează probleme la nivel de aplicație, nu doar terminări de procese.

Scalare fără ghicit. Rulăm workload-urile agenților pe un pool de noduri dedicat. Când cererea crește, cluster autoscaler-ul adaugă noduri. Când scade, nodurile sunt golite și eliminate. Nu menținem o flotă de instanțe VPS pre-provizionate sperând că am dimensionat corect. Infrastructura se potrivește cu încărcarea reală.

Stare declarativă fără derivă. Întreaga configurație a unui agent trăiește într-o singură custom resource: modelul, canalele, limitele de resurse, regulile de rețea, stocarea, contextul de securitate. Fără istoric SSH de reconstruit, fără editări manuale de urmărit, fără derivă de configurație între ceea ce credeți că rulează și ceea ce rulează efectiv.

Nimic din toate acestea nu contează pentru un agent pe o singură mașină. Toate contează când sunteți responsabil pentru funcționarea fiabilă a agenților altor persoane.

Operator-ul

Kubernetes oferă primitivele. Un Operator este ceea ce le face utilizabile.

Fără un Operator, deploy-ul unei instanțe OpenClaw pe Kubernetes înseamnă scrierea manuală a unsprezece resurse: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Cu un Operator, este nevoie de una singură:

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

Operator-ul monitorizează această custom resource și creează tot restul. Este o buclă de control: la fiecare modificare a oricărei resurse gestionate, și cel puțin o dată la cinci minute ca plasă de siguranță, compară starea dorită cu starea reală și reconciliază diferența. Dacă cineva șterge o NetworkPolicy, aceasta revine. Dacă un Deployment deviază, este corectat. Ștergeți custom resource-ul, iar owner reference-urile propagă curățarea în cascadă. Fără Service-uri orfane, fără PVC-uri rămase.

Astăzi îl publicăm ca open source: github.com/OpenClaw-rocks/k8s-operator.

Securitate implicită, nu din checklist

SecurityScorecard a găsit 135.000 de instanțe OpenClaw expuse pe internetul public săptămâna trecută. CVE-2026-25253 a demonstrat execuția de cod la distanță cu un clic prin exfiltrarea token-urilor de gateway. Gartner a recomandat organizațiilor să-l blocheze complet. Au fost găsite 341 de skill-uri malițioase în registrul ClawHub.

Aceasta este realitatea rulării agenților AI în 2026. Configurația implicită a OpenClaw ascultă pe 0.0.0.0 fără autentificare. Pe un VPS fără un firewall configurat corect, sunteți la un scan de porturi distanță de a oferi unui necunoscut acces shell la serverul dumneavoastră. Am acoperit amploarea completă a crizei de securitate și de ce chiar și un token de gateway nu este suficient.

Operator-ul adoptă abordarea opusă. Securitatea este structurală, nu opțională:

  • Non-root implicit. UID 1000, toate capability-urile Linux eliminate, seccomp RuntimeDefault. Un webhook de validare respinge orice spec care setează runAsUser: 0. Ar trebui să eliminați webhook-ul pentru a rula ca root.
  • Izolare de rețea implicită. NetworkPolicy deny-all implicită pe fiecare instanță. Intrare: doar același namespace. Ieșire: doar DNS și HTTPS. Tot restul este blocat dacă nu îl deschideți explicit.
  • RBAC cu privilegii minime. Fiecare instanță primește propriul ServiceAccount cu un Role care acordă doar get și watch pe propria ConfigMap. Un agent nu poate citi secretele, configurația sau starea altui agent.
  • Operator-ul însuși rulează ca UID 65532 (distroless nonroot), sistem de fișiere root doar-citire, toate capability-urile eliminate, HTTP/2 dezactivat pentru a atenua CVE-2023-44487.

Toate acestea sunt active implicit. Le primiți fără să vă gândiți la ele.

Automatizarea browser-ului ca sidecar

Agenții OpenClaw pot naviga pe web. Pe un VPS, asta înseamnă rularea unui proces Chromium lângă agent și speranța că nu se vor lupta pentru resurse. Operator-ul gestionează asta ca un sidecar adecvat:

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

Operator-ul adaugă un container Browserless Chromium la pod, conectează Chrome DevTools Protocol pe portul 9222, injectează CHROMIUM_URL=ws://localhost:9222 în containerul principal și oferă Chromium propriul context de securitate (UID 999, capability-uri eliminate), propriile limite de resurse și un /dev/shm susținut de memorie. Cele două containere comunică prin localhost în interiorul pod-ului. Fără salt de rețea, fără Service suplimentar, fără expunere de securitate. Pe OpenClaw.rocks, activăm sidecar-ul Chromium implicit pentru fiecare instanță.

Ce conține repository-ul

Scris în Go 1.24 cu controller-runtime (pattern Kubebuilder). Licențiat sub Apache 2.0.

  • CRD complet cu schemă de validare OpenAPI de 127 KB
  • Helm Chart (și ca artefact OCI pe GHCR)
  • Overlay-uri Kustomize pentru cei care le preferă
  • Dashboard Grafana și alerte Prometheus în docs/monitoring/
  • Teste E2E pe Kind în CI
  • Build-uri multi-arhitectură (amd64/arm64)

Operator-ul este de asemenea listat pe OperatorHub și Artifact Hub, astfel încât îl puteți descoperi și instala prin registrele pe care le utilizați deja.

Instalare:

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

Deploy-ul unui 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

Automatizare de browser, stocare persistentă, izolare de rețea, monitorizare a stării, deploy-uri automate de configurație. O singură resursă. kubectl apply.

De ce open source

Am construit acest Operator pentru a-mi rezolva propria problemă. Administrez o platformă de hosting pentru agenți OpenClaw și aveam nevoie de instrumente Kubernetes de nivel producție. Operator-ul este rezultatul acestei munci.

Dar cred și că orice companie care rulează agenți OpenClaw la scară largă va ajunge pe Kubernetes și se va confrunta cu aceleași probleme ca mine: setările de securitate implicite, configurarea NetworkPolicy, sidecar-ul Chromium, deploy-urile de configurație. Ecosistemul are două săptămâni și este deja fragmentat. Fiecare rezolvă aceste probleme independent.

Costul construirii de software se apropie de zero. Și cum am argumentat în OpenClaw este noul Linux, deschiderea previne fragmentarea. Operator-ul nu este avantajul meu competitiv. Dacă ceva este, este brandul și încrederea pe care o construiesc împărtășind muncă ca aceasta. Și dacă nici măcar asta nu rezistă, mă distrez construind, scriind și împărtășind. Asta e suficient. Menținerea Operator-ului ca proprietar ar însemna că fiecare echipă de infrastructură redescoperă aceleași capcane pe care le-am descoperit eu. Asta este risipă, nu avantaj competitiv.

Rulăm acest Operator în producție. Fiecare agent de pe OpenClaw.rocks trece prin el.

Codul este pe github.com/OpenClaw-rocks/k8s-operator. Issues și PR-uri sunt binevenite.

Dacă preferați să nu îl administrați singur, exact pentru asta există OpenClaw.rocks.