Twee weken geleden had OpenClaw 9.000 GitHub-sterren. Vandaag zijn het er 183.000. In de tussentijd is er een hele industrie ontstaan. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Een vergelijkingssite telt 33 aanbieders en de lijst blijft groeien. OpenClaw-wrappers overspoelen TrustMRR. DigitalOcean lanceerde een 1-Click Deploy. Cloudflare paste het aan tot een Workers-runtime. Mensen kochten Mac Minis om persoonlijke AI-agents thuis te draaien.

Als u zelf wilt hosten in de cloud, is de meest gangbare setup een Hetzner VPS van 5 dollar met 2 vCPU’s en 4 GB RAM, Docker Compose en een API-sleutel. Start de onboarding-wizard, verbind hem met Anthropic of OpenRouter, koppel Telegram. Klaar in dertig minuten. Of koop een Mac Mini, zet hem onder uw bureau en noem hem uw persoonlijke JARVIS. De M4 verbruikt zeven watt in rust en doet dienst als lokale inferentiemachine als u voor het 64GB Pro-model kiest.

Beide opties werken voor één agent. Maar toen ik begon met het bouwen van OpenClaw.rocks, was het doel om de meest betrouwbare en veilige manier te bieden om OpenClaw op schaal te hosten, terwijl het voor de gebruiker moeiteloos blijft. Dat vereiste een ander fundament.

Waarom ik voor Kubernetes koos

Ik beheerde voorheen blockchain-infrastructuur bij Binance, waaronder het beveiligen van de Bitcoin-nodes. Wanneer uw werk bestaat uit het geïsoleerd, observeerbaar en herstelbaar houden van waardevolle workloads op schaal, ontwikkelt u sterke opvattingen over hoe infrastructuur moet werken. Kubernetes is waar ik op vertrouw.

OpenClaw is een applicatie voor één gebruiker. Het is een persoonlijke assistent, geen multi-tenant platform. Als u agents wilt draaien voor tien mensen, hebt u tien instanties nodig. Voor honderd mensen, honderd instanties. Elk met een eigen configuratie, eigen geheimen, eigen opslag, eigen netwerkgrenzen. De isolatie-eisen alleen al sluiten alles uit dat minder is dan een volwaardige containerorkestratie.

Ik ga niet beweren dat Kubernetes eenvoudig is. Dat is het niet. Voor één agent is het absurde overkill. Maar voor het draaien van veel agents voor veel mensen lost het problemen op die niets anders net zo goed oplost. En ik denk dat elk bedrijf dat uiteindelijk OpenClaw-agents op schaal draait tot dezelfde conclusie zal komen.

Isolatie die daadwerkelijk wordt afgedwongen. Elke agent draait in zijn eigen namespace met een NetworkPolicy die standaard alles weigert. Agent A kan niet communiceren met Agent B. Agent B kan niet bij de geheimen van Agent A. Dit is geen conventie of best practice. Het wordt afgedwongen door de containerruntime en het CNI. Op een gedeelde VPS met Docker Compose vereist netwerkisolatie tussen containers handmatige iptables-regels die niemand onderhoudt.

Resourcelimieten die cascadefouten voorkomen. Een OpenClaw-agent met browserautomatisering kan 3 CPU-cores en 6 GB geheugen verbruiken als u het toelaat. Op een VPS met vier agents doodt één op hol geslagen Chromium-proces de andere drie. Kubernetes dwingt CPU- en geheugenlimieten per container af. Eén agent die zijn plafond bereikt, beïnvloedt zijn buren niet.

Zelfherstel zonder SSH. Wanneer een VPS-proces crasht, moet iets dat opmerken en het herstarten. systemd doet dit, maar alleen voor de host. Docker Compose heeft herstartbeleid, maar dat dekt de tien andere dingen niet die fout kunnen gaan: OOM-kills, node-uitval, opslagproblemen. Kubernetes herstart gefaalde containers, herplant pods wanneer nodes uitvallen en draait health probes die problemen op applicatieniveau detecteren, niet alleen procesbeëindigingen.

Schalen zonder gokken. We draaien agent-workloads op een dedicated nodepool. Wanneer de vraag toeneemt, voegt de cluster autoscaler nodes toe. Wanneer deze afneemt, worden nodes gedraineerd en verwijderd. We onderhouden geen vloot van vooraf ingerichte VPS-instanties in de hoop dat we de juiste omvang hebben gekozen. De infrastructuur volgt de werkelijke belasting.

Declaratieve status zonder afdrift. De volledige configuratie van een agent leeft in één custom resource: het model, de kanalen, de resourcelimieten, de netwerkregels, de opslag, de beveiligingscontext. Geen SSH-geschiedenis om te reconstrueren, geen handmatige bewerkingen om bij te houden, geen configuratiedrift tussen wat u denkt dat draait en wat er werkelijk draait.

Niets hiervan doet ertoe voor één agent op één machine. Alles doet ertoe wanneer u verantwoordelijk bent voor het betrouwbaar draaien van andermans agents.

De Operator

Kubernetes levert de bouwstenen. Een Operator is wat ze bruikbaar maakt.

Zonder Operator betekent het deployen van een OpenClaw-instantie op Kubernetes dat u elf resources met de hand schrijft: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Met een Operator is het er maar één:

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

De Operator bewaakt deze custom resource en maakt al het andere aan. Het is een control loop: bij elke wijziging aan een beheerde resource, en minstens elke vijf minuten als vangnet, vergelijkt hij de gewenste status met de werkelijke status en verzoent het verschil. Als iemand een NetworkPolicy verwijdert, komt deze terug. Als een Deployment afdrijft, wordt het gecorrigeerd. Verwijder de custom resource en owner references zorgen voor cascadeachtige opruiming. Geen verweesde Services, geen achtergebleven PVCs.

Vandaag maken we hem open source: github.com/OpenClaw-rocks/k8s-operator.

Beveiliging standaard, niet per checklist

SecurityScorecard vond vorige week 135.000 OpenClaw-instanties blootgesteld aan het publieke internet. CVE-2026-25253 demonstreerde remote code execution met één klik via gateway-tokenexfiltratie. Gartner adviseerde organisaties het volledig te blokkeren. Er werden 341 kwaadaardige skills gevonden in het ClawHub-register.

Dit is de realiteit van het draaien van AI-agents in 2026. De standaardconfiguratie van OpenClaw luistert op 0.0.0.0 zonder authenticatie. Op een VPS zonder correct geconfigureerde firewall bent u één poortscan verwijderd van het geven van shell-toegang aan een vreemde. We behandelden de volledige omvang van de beveiligingscrisis en waarom zelfs een gateway-token niet voldoende is.

De Operator hanteert de tegenovergestelde aanpak. Beveiliging is structureel, niet optioneel:

  • Non-root standaard. UID 1000, alle Linux-capabilities verwijderd, seccomp RuntimeDefault. Een validatiewebhook weigert elke spec die runAsUser: 0 instelt. U zou de webhook moeten verwijderen om als root te draaien.
  • Netwerkisolatie standaard. Standaard deny-all NetworkPolicy op elke instantie. Inkomend: alleen dezelfde namespace. Uitgaand: alleen DNS en HTTPS. Al het andere is geblokkeerd tenzij u het expliciet opent.
  • Least-privilege RBAC. Elke instantie krijgt zijn eigen ServiceAccount met een Role die alleen get en watch verleent op zijn eigen ConfigMap. Een agent kan de geheimen, configuratie of status van een andere agent niet lezen.
  • De Operator zelf draait als UID 65532 (distroless nonroot), alleen-lezen root-bestandssysteem, alle capabilities verwijderd, HTTP/2 uitgeschakeld om CVE-2023-44487 te mitigeren.

Dit alles is standaard actief. U krijgt het zonder erover na te denken.

Browserautomatisering als sidecar

OpenClaw-agents kunnen het web browsen. Op een VPS betekent dat een Chromium-proces naast de agent draaien en hopen dat ze niet om resources strijden. De Operator behandelt dit als een volwaardige sidecar:

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

De Operator voegt een Browserless Chromium-container toe aan de pod, verbindt het Chrome DevTools Protocol op poort 9222, injecteert CHROMIUM_URL=ws://localhost:9222 in de hoofdcontainer en geeft Chromium zijn eigen beveiligingscontext (UID 999, capabilities verwijderd), eigen resourcelimieten en een geheugenondersteund /dev/shm. De twee containers communiceren via localhost binnen de pod. Geen netwerkhop, geen extra Service, geen beveiligingsblootstelling. Op OpenClaw.rocks activeren we de Chromium-sidecar standaard voor elke instantie.

Wat er in de repository zit

Geschreven in Go 1.24 met controller-runtime (Kubebuilder-patroon). Gelicenseerd onder Apache 2.0.

  • Volledige CRD met 127KB OpenAPI-validatieschema
  • Helm Chart (ook als OCI-artifact op GHCR)
  • Kustomize-overlays voor wie dat prefereert
  • Grafana-dashboard en Prometheus-alerts in docs/monitoring/
  • E2E-tests op Kind in CI
  • Multi-arch builds (amd64/arm64)

De Operator staat ook op OperatorHub en Artifact Hub, zodat u hem kunt ontdekken en installeren via de registers die u al gebruikt.

Installatie:

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

Een agent deployen:

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, persistente opslag, netwerkisolatie, gezondheidsmonitoring, automatische configuratie-rollouts. Eén resource. kubectl apply.

Waarom open source

Ik heb deze Operator gebouwd om mijn eigen probleem op te lossen. Ik beheer een hostingplatform voor OpenClaw-agents en had productiewaardige Kubernetes-tooling nodig. De Operator is het resultaat van dat werk.

Maar ik denk ook dat elk bedrijf dat OpenClaw-agents op schaal draait uiteindelijk op Kubernetes terechtkomt en dezelfde problemen tegenkomt als ik: de beveiligingsstandaarden, de NetworkPolicy-bedrading, de Chromium-sidecar, de configuratie-rollouts. Het ecosysteem is twee weken oud en al gefragmenteerd. Iedereen lost deze problemen zelfstandig op.

De kosten van het bouwen van software naderen nul. En zoals ik betoogde in OpenClaw is het nieuwe Linux, voorkomt openheid fragmentatie. De Operator is niet mijn bescherming tegen concurrentie. Als iets dat is, dan is het het merk en het vertrouwen dat ik opbouw door werk als dit te delen. En als zelfs dat niet standhoudt, heb ik plezier in het bouwen, schrijven en delen. Dat is genoeg. De Operator propriëtair houden zou betekenen dat elk infrastructuurteam dezelfde valkuilen herontdekt die ik heb ontdekt. Dat is verspilling, geen concurrentievoordeel.

We draaien deze Operator in productie. Elke agent op OpenClaw.rocks gaat erdoorheen.

De code staat op github.com/OpenClaw-rocks/k8s-operator. Issues en PR’s zijn welkom.

Als u het liever niet zelf beheert, daarvoor is OpenClaw.rocks er.