For to uker siden hadde OpenClaw 9 000 GitHub-stjerner. I dag har det 183 000. I mellomtiden dukket det opp en hel bransje. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. En sammenligningsside teller 33 leverandører, og listen fortsetter å vokse. OpenClaw-wrappers invaderer TrustMRR. DigitalOcean lanserte en 1-Click Deploy. Cloudflare tilpasset det til en Workers-runtime. Folk kjøpte Mac Minis for å kjøre personlige AI-agenter hjemme.

Hvis du vil selvhoste i skyen, er det vanligste oppsettet en Hetzner VPS til 5 dollar med 2 vCPUer og 4 GB RAM, Docker Compose og en API-nøkkel. Kjør introduksjonsveiviseren, pek den mot Anthropic eller OpenRouter, koble til Telegram. Ferdig på tretti minutter. Eller kjøp en Mac Mini, sett den under pulten, og kall den din personlige JARVIS. M4-en trekker syv watt i tomgang og fungerer som en lokal inferensmaskin hvis du velger 64 GB Pro-modellen.

Begge disse fungerer for en enkelt agent. Men da jeg begynte å bygge OpenClaw.rocks, var målet å tilby den mest pålitelige og sikre måten å hoste OpenClaw i stor skala, samtidig som det forblir enkelt for brukeren. Det krevde et annet fundament.

Hvorfor jeg valgte Kubernetes

Jeg drev blockchain-infrastruktur hos Binance, inkludert sikring av Bitcoin-nodene. Når jobben din er å holde høyverdige arbeidsbelastninger isolerte, observerbare og gjenopprettbare i stor skala, utvikler du sterke meninger om hvordan infrastruktur bør fungere. Kubernetes er det jeg stoler på for dette.

OpenClaw er en enkeltbrukerapplikasjon. Det er en personlig assistent, ikke en multi-tenant-plattform. Hvis du vil kjøre agenter for ti personer, trenger du ti instanser. For hundre personer, hundre instanser. Hver med sin egen konfigurasjon, sine egne hemmeligheter, sin egen lagring, sine egne nettverksgrenser. Isoleringskravene alene utelukker alt under skikkelig containerorkestrering.

Jeg kommer ikke til å argumentere for at Kubernetes er enkelt. Det er det ikke. For en enkelt agent er det absurd overdrevet. Men for å kjøre mange agenter for mange mennesker løser det problemer som ingenting annet løser like godt. Og jeg tror at ethvert selskap som ender opp med å kjøre OpenClaw-agenter i stor skala, vil komme til samme konklusjon.

Isolasjon som faktisk håndheves. Hver agent kjører i sitt eget namespace med en NetworkPolicy som som standard nekter alt. Agent A kan ikke snakke med Agent B. Agent B kan ikke nå Agent As hemmeligheter. Dette er ingen konvensjon eller beste praksis. Det håndheves av container-runtime og CNI. På en delt VPS med Docker Compose krever nettverksisolasjon mellom containere manuelle iptables-regler som ingen vedlikeholder.

Ressursgrenser som forhindrer kaskadefeil. En OpenClaw-agent med nettleserautomatisering kan bruke 3 CPU-kjerner og 6 GB minne hvis du lar den. På en VPS med fire agenter tar en løpsk Chromium-prosess ned de tre andre. Kubernetes håndhever CPU- og minnegrenser per container. En agent som treffer taket sitt, påvirker ikke naboene.

Selvhelbredelse uten SSH. Når en VPS-prosess krasjer, må noe oppdage det og starte den på nytt. systemd gjør dette, men bare for verten. Docker Compose har omstartspolicyer, men de dekker ikke de ti andre tingene som kan gå galt: OOM-kills, nodefeil, lagringsproblemer. Kubernetes starter feilede containere på nytt, omplanlegger pods når noder dør, og kjører helsesjekker som oppdager problemer på applikasjonsnivå, ikke bare prosessavslutninger.

Skalering uten gjetting. Vi kjører agentarbeidsbelastninger på en dedikert nodepool. Når etterspørselen øker, legger cluster autoscaler til noder. Når den avtar, dreneres og fjernes noder. Vi vedlikeholder ikke en flåte av forhåndsklargjorte VPS-instanser og håper at vi dimensjonerte riktig. Infrastrukturen matcher den faktiske belastningen.

Deklarativ tilstand uten drift. En agents hele konfigurasjon lever i en enkelt custom resource: modellen, kanalene, ressursgrensene, nettverksreglene, lagringen, sikkerhetskonteksten. Ingen SSH-historikk å rekonstruere, ingen manuelle endringer å spore, ingen konfigurasjonsdrift mellom det du tror kjører og det som faktisk kjører.

Ingenting av dette betyr noe for en agent på en maskin. Alt betyr noe når du er ansvarlig for at andre menneskers agenter kjører pålitelig.

Operatoren

Kubernetes gir deg byggesteinene. En operator er det som gjør dem brukbare.

Uten en operator betyr utrulling av en OpenClaw-instans på Kubernetes at du skriver elleve ressurser for hånd: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Med en operator er det en:

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

Operatoren overvåker denne custom resourcen og oppretter alt annet. Det er en kontrollsløyfe: ved hver endring i en eid ressurs, og minst hvert femte minutt som sikkerhetsnett, sammenligner den ønsket tilstand med faktisk tilstand og avstemmer forskjellen. Hvis noen sletter en NetworkPolicy, kommer den tilbake. Hvis et Deployment avviker, korrigeres det. Slett custom resourcen, og owner references kaskaderer oppryddingen. Ingen foreldreløse Services, ingen gjenværende PVCs.

I dag gjør vi den til open source: github.com/OpenClaw-rocks/k8s-operator.

Sikkerhet som standard, ikke som sjekkliste

SecurityScorecard fant 135 000 OpenClaw-instanser eksponert mot det offentlige internettet forrige uke. CVE-2026-25253 demonstrerte fjernkjøring av kode med ett klikk gjennom eksfiltrering av gateway-token. Gartner anbefalte organisasjoner å blokkere det fullstendig. 341 ondsinnede skills ble funnet i ClawHub-registeret.

Dette er virkeligheten ved å kjøre AI-agenter i 2026. OpenClaws standardkonfigurasjon binder til 0.0.0.0 uten autentisering. På en VPS uten riktig konfigurert brannmur er du en portskanning unna å gi en fremmed shell-tilgang til serveren din. Vi dekket det fulle omfanget av sikkerhetskrisen og hvorfor selv et gateway-token ikke er nok.

Operatoren tar den motsatte tilnærmingen. Sikkerhet er strukturell, ikke valgfri:

  • Non-root som standard. UID 1000, alle Linux-capabilities fjernet, seccomp RuntimeDefault. En validerende webhook avviser enhver spec som setter runAsUser: 0. Du måtte fjerne webhooken for å kjøre som root.
  • Nettverksisolasjon som standard. Default-deny NetworkPolicy på hver instans. Innkommende: kun samme namespace. Utgående: kun DNS og HTTPS. Alt annet er blokkert med mindre du eksplisitt åpner det.
  • Minste privilegiums RBAC. Hver instans får sin egen ServiceAccount med en Role som bare tildeler get og watch på sin egen ConfigMap. En agent kan ikke lese en annen agents hemmeligheter, konfigurasjon eller tilstand.
  • Operatoren selv kjører som UID 65532 (distroless nonroot), skrivebeskyttet rotfilsystem, alle capabilities fjernet, HTTP/2 deaktivert for å motvirke CVE-2023-44487.

Alt dette er aktivert som standard. Du får det uten å tenke på det.

Nettleserautomatisering som sidecar

OpenClaw-agenter kan surfe på nettet. På en VPS betyr det å kjøre en Chromium-prosess ved siden av agenten og håpe at de ikke kjemper om ressurser. Operatoren håndterer dette som en skikkelig sidecar:

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

Operatoren legger til en Browserless Chromium-container i poden, kobler opp Chrome DevTools Protocol på port 9222, injiserer CHROMIUM_URL=ws://localhost:9222 i hovedcontaineren, og gir Chromium sin egen sikkerhetskontekst (UID 999, capabilities fjernet), sine egne ressursgrenser og et minnebasert /dev/shm. De to containerne kommuniserer via localhost inne i poden. Ingen nettverkshopp, ingen ekstra Service, ingen sikkerhetseksponering. På OpenClaw.rocks aktiverer vi Chromium-sidecaren som standard for hver instans.

Hva som er i repoet

Skrevet i Go 1.24 med controller-runtime (Kubebuilder-mønster). Lisensiert under Apache 2.0.

  • Fullstendig CRD med 127 KB OpenAPI-valideringsskjema
  • Helm chart (også som OCI-artefakt på GHCR)
  • Kustomize overlays for dem som foretrekker det
  • Grafana dashboard og Prometheus alerts i docs/monitoring/
  • E2E-tester på Kind i CI
  • Multi-arkitektur builds (amd64/arm64)

Operatoren er også listet på OperatorHub og Artifact Hub, slik at du kan oppdage og installere den gjennom registrene du allerede bruker.

Installasjon:

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

Rull ut en 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

Nettleserautomatisering, persistent lagring, nettverksisolasjon, helseovervåking, automatiske konfigurasjonsoppdateringer. En ressurs. kubectl apply.

Hvorfor open source

Jeg bygde denne operatoren for å løse mitt eget problem. Jeg driver en hostingplattform for OpenClaw-agenter og trengte produksjonsklare Kubernetes-verktøy for det. Operatoren er resultatet av det arbeidet.

Men jeg tror også at ethvert selskap som kjører OpenClaw-agenter i stor skala, vil ende opp på Kubernetes, og de vil stå overfor de samme problemene som jeg: sikkerhetsinnstillingene, NetworkPolicy-oppkoblingen, Chromium-sidecaren, konfigurasjonsoppdateringene. Økosystemet er to uker gammelt og allerede fragmentert. Alle løser disse problemene uavhengig av hverandre.

Kostnaden ved å bygge programvare nærmer seg null. Og som jeg argumenterte i OpenClaw er det nye Linux, forhindrer åpenhet fragmentering. Operatoren er ikke min vollgrav. Hvis noe er det, er det merkevaren og tilliten jeg bygger ved å dele arbeid som dette. Og hvis ikke engang det holder, har jeg det gøy med å bygge, skrive og dele. Det er nok. Å holde operatoren proprietær ville bety at hvert infrastrukturteam gjenoppdager de samme fellene jeg fant. Det er sløsing, ikke konkurransefortrinn.

Vi kjører denne operatoren i produksjon. Hver agent på OpenClaw.rocks går gjennom den.

Koden er på github.com/OpenClaw-rocks/k8s-operator. Issues og PRs er velkomne.

Hvis du heller ikke vil drifte den selv, er det det OpenClaw.rocks er til for.