För två veckor sedan hade OpenClaw 9 000 GitHub-stjärnor. Idag har det 183 000. Däremellan uppstod en hel bransch. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. En jämförelsesajt räknar 33 leverantörer och listan fortsätter att växa. OpenClaw-wrappers invaderar TrustMRR. DigitalOcean lanserade en 1-Click Deploy. Cloudflare anpassade det till en Workers-runtime. Folk köpte Mac Minis för att köra personliga AI-agenter hemma.

Om du vill självhosta i molnet är det vanligaste upplägget en Hetzner VPS för 5 dollar med 2 vCPU:er och 4 GB RAM, Docker Compose och en API-nyckel. Kör introduktionsguiden, peka den mot Anthropic eller OpenRouter, anslut Telegram. Klart på trettio minuter. Eller köp en Mac Mini, ställ den under skrivbordet och kalla den din personliga JARVIS. M4:an drar sju watt i viloläge och fungerar som en lokal inferensmaskin om du väljer 64 GB Pro-modellen.

Båda dessa alternativ fungerar för en enskild agent. Men när jag började bygga OpenClaw.rocks var målet att erbjuda det mest tillförlitliga och säkra sättet att hosta OpenClaw i stor skala, samtidigt som det förblir enkelt för användaren. Det krävde en annan grund.

Varför jag valde Kubernetes

Jag brukade driva blockkedjeinfrastruktur på Binance, inklusive att säkra Bitcoin-noderna. När ditt jobb är att hålla högvärdiga arbetsbelastningar isolerade, observerbara och återställningsbara i stor skala, utvecklar du starka åsikter om hur infrastruktur bör fungera. Kubernetes är det jag litar på för det.

OpenClaw är en enanvändarapplikation. Det är en personlig assistent, inte en multi-tenant-plattform. Om du vill köra agenter för tio personer behöver du tio instanser. För hundra personer, hundra instanser. Var och en med sin egen konfiguration, sina egna hemligheter, sin egen lagring, sina egna nätverksgränser. Enbart isoleringskraven utesluter allt som inte är fullständig containerorkestrering.

Jag tänker inte hävda att Kubernetes är enkelt. Det är det inte. För en enskild agent är det absurt överdrivet. Men för att driva många agenter för många människor löser det problem som inget annat löser lika bra. Och jag tror att alla företag som hamnar i att köra OpenClaw-agenter i stor skala kommer att nå samma slutsats.

Isolering som faktiskt upprätthålls. Varje agent körs i sitt eget namespace med en NetworkPolicy som som standard nekar allt. Agent A kan inte kommunicera med Agent B. Agent B kan inte nå Agent A:s hemligheter. Detta är ingen konvention eller bästa praxis. Det upprätthålls av container-runtime och CNI. På en delad VPS med Docker Compose kräver nätverksisolering mellan containrar manuella iptables-regler som ingen underhåller.

Resursbegränsningar som förhindrar kaskadfel. En OpenClaw-agent med webbläsarautomatisering kan förbruka 3 CPU-kärnor och 6 GB minne om du tillåter det. På en VPS med fyra agenter slår en skenande Chromium-process ut de andra tre. Kubernetes upprätthåller CPU- och minnesbegränsningar per container. En agent som når sitt tak påverkar inte sina grannar.

Självläkning utan SSH. När en VPS-process kraschar måste något upptäcka det och starta om den. systemd gör detta, men bara för värden. Docker Compose har omstartsregler, men de täcker inte de tio andra saker som kan gå fel: OOM-kills, nodfel, lagringsproblem. Kubernetes startar om misslyckade containrar, omplanerar poddar när noder dör och kör hälsokontroller som upptäcker problem på applikationsnivå, inte bara processavslut.

Skalering utan gissningar. Vi kör agentarbetsbelastningar på en dedikerad nodpool. När efterfrågan ökar lägger cluster autoscaler till noder. När den minskar dräneras och tas noder bort. Vi underhåller inte en flotta av förprovisionerade VPS-instanser och hoppas att vi dimensionerade rätt. Infrastrukturen matchar den faktiska belastningen.

Deklarativt tillstånd utan drift. En agents hela konfiguration lever i en enda custom resource: modellen, kanalerna, resursbegränsningarna, nätverksreglerna, lagringen, säkerhetskontexten. Ingen SSH-historik att rekonstruera, inga manuella ändringar att spåra, ingen konfigurationsdrift mellan vad du tror körs och vad som faktiskt körs.

Inget av detta spelar roll för en agent på en maskin. Allt spelar roll när du ansvarar för att andra människors agenter körs tillförlitligt.

Operatorn

Kubernetes ger dig byggstenarna. En operator är det som gör dem användbara.

Utan en operator innebär driftsättning av en OpenClaw-instans på Kubernetes att du skriver elva resurser för hand: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Med en operator är 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

Operatorn bevakar denna custom resource och skapar allt annat. Det är en kontrollslinga: vid varje förändring av en ägd resurs, och minst var femte minut som säkerhetsnät, jämför den önskat tillstånd med faktiskt tillstånd och reconcilierar skillnaden. Om någon raderar en NetworkPolicy kommer den tillbaka. Om ett Deployment avviker korrigeras det. Radera custom resourcen, och owner references kaskaderar rensningen. Inga övergivna Services, inga kvarglömda PVCs.

Idag gör vi den till open source: github.com/OpenClaw-rocks/k8s-operator.

Säkerhet som standard, inte som checklista

SecurityScorecard hittade 135 000 OpenClaw-instanser exponerade mot det publika internet förra veckan. CVE-2026-25253 demonstrerade fjärrkörning av kod med ett klick genom exfiltrering av gateway-token. Gartner rekommenderade organisationer att blockera det helt. 341 skadliga skills hittades i ClawHub-registret.

Detta är verkligheten av att köra AI-agenter 2026. OpenClaws standardkonfiguration binder till 0.0.0.0 utan autentisering. På en VPS utan korrekt konfigurerad brandvägg är du en portskanning ifrån att ge en främling skalåtkomst till din server. Vi täckte hela omfattningen av säkerhetskrisen och varför inte ens ett gateway-token räcker.

Operatorn tar motsatt tillvägagångssätt. Säkerhet är strukturell, inte valfri:

  • Icke-root som standard. UID 1000, alla Linux-capabilities borttagna, seccomp RuntimeDefault. En validerande webhook avvisar varje spec som sätter runAsUser: 0. Du måste ta bort webhooken för att köra som root.
  • Nätverksisolering som standard. Default-deny NetworkPolicy på varje instans. Inkommande: bara samma namespace. Utgående: bara DNS och HTTPS. Allt annat är blockerat om du inte uttryckligen öppnar det.
  • Minsta möjliga RBAC-behörigheter. Varje instans får sitt eget ServiceAccount med en Role som bara beviljar get och watch på sin egen ConfigMap. En agent kan inte läsa en annan agents hemligheter, konfiguration eller tillstånd.
  • Operatorn själv körs som UID 65532 (distroless nonroot), skrivskyddat rotfilsystem, alla capabilities borttagna, HTTP/2 inaktiverat för att motverka CVE-2023-44487.

Allt detta är aktiverat som standard. Du får det utan att behöva tänka på det.

Webbläsarautomatisering som sidecar

OpenClaw-agenter kan surfa på webben. På en VPS innebär det att köra en Chromium-process bredvid agenten och hoppas att de inte slåss om resurser. Operatorn hanterar detta som en riktig sidecar:

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

Operatorn lägger till en Browserless Chromium-container i podden, kopplar upp Chrome DevTools Protocol på port 9222, injicerar CHROMIUM_URL=ws://localhost:9222 i huvudcontainern och ger Chromium sin egen säkerhetskontext (UID 999, capabilities borttagna), sina egna resursbegränsningar och ett minnesbaserat /dev/shm. De två containrarna kommunicerar via localhost inuti podden. Inget nätverkshopp, ingen extra Service, ingen säkerhetsexponering. På OpenClaw.rocks aktiverar vi Chromium-sidecaren som standard för varje instans.

Vad som finns i repot

Skrivet i Go 1.24 med controller-runtime (Kubebuilder-mönster). Licensierat under Apache 2.0.

  • Fullständig CRD med 127 KB OpenAPI-valideringsschema
  • Helm chart (även som OCI-artefakt på GHCR)
  • Kustomize overlays för den som föredrar det
  • Grafana dashboard och Prometheus alerts i docs/monitoring/
  • E2E-tester på Kind i CI
  • Multi-arkitekturbyggen (amd64/arm64)

Operatorn är även listad på OperatorHub och Artifact Hub, så du kan hitta och installera den genom de register du redan använder.

Installation:

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

Driftsätt 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

Webbläsarautomatisering, persistent lagring, nätverksisolering, hälsoövervakning, automatiska konfigurationsuppdateringar. En resurs. kubectl apply.

Varför open source

Jag byggde denna operator för att lösa mitt eget problem. Jag driver en hostingplattform för OpenClaw-agenter och behövde produktionsfärdig Kubernetes-verktyg för det. Operatorn är resultatet av det arbetet.

Men jag tror också att alla företag som kör OpenClaw-agenter i stor skala kommer att hamna på Kubernetes, och de kommer att möta samma problem som jag: säkerhetsstandarderna, NetworkPolicy-kopplingarna, Chromium-sidecaren, konfigurationsuppdateringarna. Ekosystemet är två veckor gammalt och redan fragmenterat. Alla löser dessa problem oberoende av varandra.

Kostnaden för att bygga mjukvara närmar sig noll. Och som jag argumenterade i OpenClaw är det nya Linux förhindrar öppenhet fragmentering. Operatorn är inte min vallgrav. Om något är det, så är det varumärket och det förtroende jag bygger genom att dela arbete som detta. Och om inte ens det håller, så har jag roligt med att bygga, skriva och dela. Det räcker. Att hålla operatorn proprietär skulle innebära att varje infrastrukturteam återupptäcker samma fallgropar som jag. Det är slöseri, inte konkurrensfördel.

Vi kör denna operator i produktion. Varje agent på OpenClaw.rocks går genom den.

Koden finns på github.com/OpenClaw-rocks/k8s-operator. Issues och PRs välkomnas.

Om du hellre inte vill driftsätta den själv, det är det OpenClaw.rocks finns till för.