For to uger siden havde OpenClaw 9.000 GitHub-stjerner. I dag har det 183.000. I mellemtiden opstod en hel branche. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. En sammenlignelsesside tæller 33 udbydere, og listen vokser fortsat. OpenClaw-wrappers invaderer TrustMRR. DigitalOcean lancerede en 1-Click Deploy. Cloudflare tilpassede det til en Workers-runtime. Folk købte Mac Minis for at køre personlige AI-agenter derhjemme.

Hvis du vil selvhoste i skyen, er det mest almindelige setup en Hetzner VPS til 5 dollar med 2 vCPU’er og 4 GB RAM, Docker Compose og en API-nøgle. Kør onboarding-guiden, peg den mod Anthropic eller OpenRouter, tilslut Telegram. Færdig på tredive minutter. Eller køb en Mac Mini, sæt den under skrivebordet, og kald den din personlige JARVIS. M4’eren trækker syv watt i tomgang og fungerer som en lokal inferensmaskin, hvis du vælger 64 GB Pro-modellen.

Begge dele fungerer for en enkelt agent. Men da jeg begyndte at bygge OpenClaw.rocks, var målet at tilbyde den mest pålidelige og sikre måde at hoste OpenClaw i stor skala, og samtidig holde det ubesværet for brugeren. Det krævede et andet fundament.

Hvorfor jeg valgte Kubernetes

Jeg plejede at drive blockchain-infrastruktur hos Binance, herunder sikring af Bitcoin-noderne. Når dit job er at holde højværdi-workloads isolerede, observerbare og gendannelige i stor skala, udvikler du stærke holdninger til, hvordan infrastruktur bør fungere. Kubernetes er det, jeg stoler på til det.

OpenClaw er en enkeltbrugerapplikation. Det er en personlig assistent, ikke en multi-tenant-platform. Hvis du vil køre agenter for ti personer, har du brug for ti instanser. For hundrede personer, hundrede instanser. Hver med sin egen konfiguration, sine egne hemmeligheder, sin egen lagring, sine egne netværksgrænser. Isoleringskravene alene udelukker alt under ordentlig containerorkestrering.

Jeg vil ikke påstå, at Kubernetes er simpelt. Det er det ikke. For en enkelt agent er det absurd overdrevet. Men til at køre mange agenter for mange mennesker løser det problemer, som intet andet løser lige så godt. Og jeg tror, at enhver virksomhed, der ender med at køre OpenClaw-agenter i stor skala, vil nå den samme konklusion.

Isolation der faktisk håndhæves. Hver agent kører i sit eget namespace med en NetworkPolicy, der som standard afviser alt. Agent A kan ikke tale med Agent B. Agent B kan ikke nå Agent A’s hemmeligheder. Dette er ikke en konvention eller en best practice. Det håndhæves af container-runtime og CNI. På en delt VPS med Docker Compose kræver netværksisolation mellem containere manuelle iptables-regler, som ingen vedligeholder.

Ressourcegrænser der forhindrer kaskadefejl. En OpenClaw-agent med browserautomatisering kan forbruge 3 CPU-kerner og 6 GB hukommelse, hvis du tillader det. På en VPS med fire agenter slår en løbsk Chromium-proces de andre tre ned. Kubernetes håndhæver CPU- og hukommelsesgrænser per container. En agent, der rammer sit loft, påvirker ikke sine naboer.

Selvhelbredelse uden SSH. Når en VPS-proces crasher, skal noget opdage det og genstarte den. systemd gør dette, men kun for værten. Docker Compose har genstartsregler, men de dækker ikke de ti andre ting, der kan gå galt: OOM-kills, nodefejl, lagringsproblemer. Kubernetes genstarter fejlede containere, omplacerer pods, når noder dør, og kører sundhedstjek, der opdager problemer på applikationsniveau, ikke kun procesafslutninger.

Skalering uden gætværk. Vi kører agent-workloads på en dedikeret nodepool. Når efterspørgslen stiger, tilføjer cluster autoscaler noder. Når den falder, drænes og fjernes noder. Vi vedligeholder ikke en flåde af forprovisionerede VPS-instanser og håber, at vi dimensionerede rigtigt. Infrastrukturen matcher den faktiske belastning.

Deklarativ tilstand uden drift. En agents hele konfiguration lever i en enkelt custom resource: modellen, kanalerne, ressourcegrænserne, netværksreglerne, lagringen, sikkerhedskonteksten. Ingen SSH-historik at rekonstruere, ingen manuelle ændringer at spore, ingen konfigurationsdrift mellem det, du tror kører, og det, der faktisk kører.

Intet af dette betyder noget for en agent på en maskine. Alt betyder noget, når du er ansvarlig for, at andre menneskers agenter kører pålideligt.

Operatoren

Kubernetes giver dig byggeklodserne. En operator er det, der gør dem brugbare.

Uden en operator betyder deployment af en OpenClaw-instans på Kubernetes, at du skriver elleve ressourcer i hånden: 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åger denne custom resource og opretter alt andet. Det er en kontrolsløjfe: ved enhver ændring af en ejet ressource, og mindst hvert femte minut som sikkerhedsnet, sammenligner den ønsket tilstand med faktisk tilstand og udligner forskellen. Hvis nogen sletter en NetworkPolicy, kommer den tilbage. Hvis et Deployment afviger, korrigeres det. Slet custom resourcen, og owner references kaskaderer oprydningen. Ingen forældreløse Services, ingen tilbageværende PVCs.

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

Sikkerhed som standard, ikke som tjekliste

SecurityScorecard fandt 135.000 OpenClaw-instanser eksponeret mod det offentlige internet i sidste uge. CVE-2026-25253 demonstrerede fjernudførelse af kode med et klik gennem exfiltrering af gateway-token. Gartner anbefalede organisationer at blokere det helt. 341 ondsindede skills blev fundet i ClawHub-registret.

Dette er virkeligheden ved at køre AI-agenter i 2026. OpenClaws standardkonfiguration binder til 0.0.0.0 uden autentificering. På en VPS uden korrekt konfigureret firewall er du en portscanning fra at give en fremmed shell-adgang til din server. Vi dækkede det fulde omfang af sikkerhedskrisen og hvorfor selv et gateway-token ikke er nok.

Operatoren tager den modsatte tilgang. Sikkerhed er strukturel, ikke valgfri:

  • Non-root som standard. UID 1000, alle Linux-capabilities droppet, seccomp RuntimeDefault. En validerende webhook afviser enhver spec, der sætter runAsUser: 0. Du ville være nødt til at fjerne webhooken for at køre som root.
  • Netværksisolation som standard. Default-deny NetworkPolicy på hver instans. Indgående: kun samme namespace. Udgående: kun DNS og HTTPS. Alt andet er blokeret, medmindre du eksplicit åbner det.
  • Mindst mulige RBAC-rettigheder. Hver instans får sin egen ServiceAccount med en Role, der kun tildeler get og watch på sin egen ConfigMap. En agent kan ikke læse en anden agents hemmeligheder, konfiguration eller tilstand.
  • Operatoren selv kører som UID 65532 (distroless nonroot), skrivebeskyttet rodfilsystem, alle capabilities droppet, HTTP/2 deaktiveret for at afbøde CVE-2023-44487.

Alt dette er aktiveret som standard. Du får det uden at tænke over det.

Browserautomatisering som sidecar

OpenClaw-agenter kan browse på nettet. På en VPS betyder det at køre en Chromium-proces ved siden af agenten og håbe, at de ikke kæmper om ressourcer. Operatoren håndterer dette som en rigtig sidecar:

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

Operatoren tilføjer en Browserless Chromium-container til poden, forbinder Chrome DevTools Protocol på port 9222, injicerer CHROMIUM_URL=ws://localhost:9222 i hovedcontaineren og giver Chromium sin egen sikkerhedskontekst (UID 999, capabilities droppet), sine egne ressourcegrænser og et hukommelsesbaseret /dev/shm. De to containere kommunikerer via localhost inde i poden. Intet netværkshop, ingen ekstra Service, ingen sikkerhedseksponering. På OpenClaw.rocks aktiverer vi Chromium-sidecaren som standard for hver instans.

Hvad der er i repoet

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

  • Fuld CRD med 127 KB OpenAPI-valideringsskema
  • Helm chart (også som OCI-artefakt på GHCR)
  • Kustomize overlays for dem, der foretrækker det
  • Grafana dashboard og Prometheus alerts i docs/monitoring/
  • E2E-tests på Kind i CI
  • Multi-arkitektur builds (amd64/arm64)

Operatoren er også listet på OperatorHub og Artifact Hub, så du kan finde og installere den gennem de registries, du allerede bruger.

Installation:

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

Deploy 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

Browserautomatisering, persistent lagring, netværksisolation, sundhedsovervågning, automatiske konfigurationsudrulninger. En ressource. kubectl apply.

Hvorfor open source

Jeg byggede denne operator for at løse mit eget problem. Jeg driver en hostingplatform for OpenClaw-agenter og havde brug for produktionsklar Kubernetes-værktøj til det. Operatoren er resultatet af det arbejde.

Men jeg tror også, at enhver virksomhed, der kører OpenClaw-agenter i stor skala, vil ende på Kubernetes, og de vil stå over for de samme problemer, som jeg gjorde: sikkerhedsstandarderne, NetworkPolicy-opsætningen, Chromium-sidecaren, konfigurationsudrulningerne. Økosystemet er to uger gammelt og allerede fragmenteret. Alle løser disse problemer uafhængigt af hinanden.

Omkostningerne ved at bygge software nærmer sig nul. Og som jeg argumenterede i OpenClaw er det nye Linux, forhindrer åbenhed fragmentering. Operatoren er ikke min voldgrav. Hvis noget er det, er det brandet og den tillid, jeg opbygger ved at dele arbejde som dette. Og hvis ikke engang det holder, har jeg det sjovt med at bygge, skrive og dele. Det er nok. At holde operatoren proprietær ville betyde, at hvert infrastrukturteam genopdager de samme faldgruber, som jeg gjorde. Det er spild, ikke konkurrencefordel.

Vi kører denne operator i produktion. Hver agent på OpenClaw.rocks går igennem den.

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

Hvis du hellere ikke vil drive den selv, er det det, OpenClaw.rocks er til for.