Vor zwei Wochen hatte OpenClaw 9.000 GitHub-Sterne. Heute sind es 183.000. In der Zwischenzeit ist eine ganze Branche entstanden. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Eine Vergleichsseite zählt 33 Anbieter und die Liste wächst weiter. OpenClaw-Wrapper erobern TrustMRR. DigitalOcean hat ein 1-Click Deploy herausgebracht. Cloudflare hat es in eine Workers-Laufzeitumgebung umgewandelt. Leute kauften Mac Minis, um persönliche KI-Agenten zu Hause zu betreiben.

Wenn Sie in der Cloud selbst hosten möchten, ist das gängigste Setup ein 5-Dollar-VPS bei Hetzner mit 2 vCPUs und 4 GB RAM, Docker Compose und ein API-Schlüssel. Starten Sie den Onboarding-Assistenten, verbinden Sie ihn mit Anthropic oder OpenRouter, schalten Sie Telegram an. In dreißig Minuten erledigt. Oder kaufen Sie einen Mac Mini, stellen Sie ihn unter Ihren Schreibtisch und nennen Sie ihn Ihren persönlichen JARVIS. Der M4 verbraucht sieben Watt im Leerlauf und dient als lokale Inferenz-Maschine, wenn Sie sich für das 64-GB-Pro-Modell entscheiden.

Beide Varianten funktionieren für einen einzelnen Agenten. Aber als ich begann, OpenClaw.rocks zu entwickeln, war das Ziel, die zuverlässigste und sicherste Möglichkeit zu bieten, OpenClaw im großen Stil zu hosten, und das Ganze für den Nutzer mühelos zu gestalten. Dafür brauchte es ein anderes Fundament.

Warum ich Kubernetes gewählt habe

Ich habe früher bei Binance Blockchain-Infrastruktur betrieben, einschließlich der Absicherung der Bitcoin-Nodes. Wenn Ihr Job darin besteht, hochwertige Workloads isoliert, beobachtbar und wiederherstellbar im großen Maßstab zu betreiben, entwickeln Sie eine klare Meinung darüber, wie Infrastruktur funktionieren sollte. Kubernetes ist das, dem ich dafür vertraue.

OpenClaw ist eine Einzelbenutzer-Anwendung. Es ist ein persönlicher Assistent, keine Multi-Tenant-Plattform. Wenn Sie Agenten für zehn Personen betreiben möchten, brauchen Sie zehn Instanzen. Für hundert Personen hundert Instanzen. Jede mit eigener Konfiguration, eigenen Geheimnissen, eigenem Speicher, eigenen Netzwerkgrenzen. Allein die Isolationsanforderungen schließen alles unterhalb einer ordentlichen Container-Orchestrierung aus.

Ich werde nicht behaupten, dass Kubernetes einfach ist. Das ist es nicht. Für einen einzelnen Agenten ist es absurder Overkill. Aber für den Betrieb vieler Agenten für viele Menschen löst es Probleme, die nichts anderes ebenso gut löst. Und ich denke, jedes Unternehmen, das am Ende OpenClaw-Agenten im großen Maßstab betreibt, wird zum selben Schluss kommen.

Isolation, die tatsächlich durchgesetzt wird. Jeder Agent läuft in seinem eigenen Namespace mit einer NetworkPolicy, die standardmäßig alles verweigert. Agent A kann nicht mit Agent B kommunizieren. Agent B kann nicht auf die Geheimnisse von Agent A zugreifen. Das ist keine Konvention oder Best Practice. Es wird durch die Container-Runtime und den CNI durchgesetzt. Auf einem geteilten VPS mit Docker Compose erfordert Netzwerkisolierung zwischen Containern manuelle iptables-Regeln, die niemand pflegt.

Ressourcenlimits, die kaskadierende Ausfälle verhindern. Ein OpenClaw-Agent mit Browser-Automatisierung kann 3 CPU-Kerne und 6 GB Arbeitsspeicher verbrauchen, wenn man ihn lässt. Auf einem VPS mit vier Agenten bringt ein durchgehender Chromium-Prozess die anderen drei zum Absturz. Kubernetes setzt CPU- und Arbeitsspeicherlimits pro Container durch. Ein Agent, der sein Limit erreicht, beeinträchtigt seine Nachbarn nicht.

Selbstheilung ohne SSH. Wenn ein VPS-Prozess abstürzt, muss etwas dies bemerken und ihn neu starten. systemd macht das, aber nur für den Host. Docker Compose hat Neustart-Regeln, aber diese decken nicht die zehn anderen Dinge ab, die schiefgehen können: OOM-Kills, Node-Ausfälle, Speicherprobleme. Kubernetes startet fehlgeschlagene Container neu, plant Pods auf andere Nodes um, wenn Nodes ausfallen, und führt Health Probes durch, die Probleme auf Anwendungsebene erkennen, nicht nur Prozessabbrüche.

Skalierung ohne Raten. Wir betreiben Agent-Workloads auf einem dedizierten Node Pool. Wenn die Nachfrage steigt, fügt der Cluster Autoscaler Nodes hinzu. Wenn sie sinkt, werden Nodes entleert und entfernt. Wir unterhalten keine Flotte vorprovisionierter VPS-Instanzen in der Hoffnung, die richtige Größe gewählt zu haben. Die Infrastruktur passt sich der tatsächlichen Last an.

Deklarativer Zustand ohne Drift. Die gesamte Konfiguration eines Agenten lebt in einer einzigen Custom Resource: das Modell, die Kanäle, die Ressourcenlimits, die Netzwerkregeln, der Speicher, der Security Context. Keine SSH-Historie zum Rekonstruieren, keine manuellen Änderungen zum Nachverfolgen, kein Konfigurationsdrift zwischen dem, was Sie glauben, dass läuft, und dem, was tatsächlich läuft.

Nichts davon ist relevant für einen Agenten auf einer Maschine. Alles davon ist relevant, wenn Sie die Verantwortung dafür tragen, dass die Agenten anderer Menschen zuverlässig laufen.

Der Operator

Kubernetes liefert die Grundbausteine. Ein Operator macht sie nutzbar.

Ohne Operator bedeutet das Deployment einer OpenClaw-Instanz auf Kubernetes, elf Ressourcen von Hand zu schreiben: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Mit einem Operator ist es eine einzige:

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

Der Operator überwacht diese Custom Resource und erstellt alles andere. Es ist eine Kontrollschleife: Bei jeder Änderung an einer zugehörigen Ressource und mindestens alle fünf Minuten als Sicherheitsnetz vergleicht er den Soll-Zustand mit dem Ist-Zustand und gleicht die Differenz ab. Wenn jemand eine NetworkPolicy löscht, kommt sie zurück. Wenn ein Deployment abweicht, wird es korrigiert. Löscht man die Custom Resource, kaskadiert die Bereinigung über Owner References. Keine verwaisten Services, keine übriggebliebenen PVCs.

Heute veröffentlichen wir ihn als Open Source: github.com/OpenClaw-rocks/k8s-operator.

Sicherheit als Standard, nicht als Checkliste

SecurityScorecard fand letzte Woche 135.000 OpenClaw-Instanzen, die öffentlich im Internet erreichbar waren. CVE-2026-25253 demonstrierte die Ausführung von beliebigem Code mit einem Klick durch das Abgreifen von Gateway-Tokens. Gartner empfahl Organisationen, es komplett zu blockieren. 341 bösartige Skills wurden in der ClawHub-Registry gefunden.

Das ist die Realität des Betriebs von KI-Agenten im Jahr 2026. Die Standardkonfiguration von OpenClaw bindet an 0.0.0.0 ohne Authentifizierung. Auf einem VPS ohne korrekt konfigurierte Firewall sind Sie nur einen Port-Scan davon entfernt, einem Fremden Shell-Zugriff auf Ihren Server zu geben. Wir haben den vollen Umfang der Sicherheitskrise behandelt und erklärt, warum selbst ein Gateway-Token nicht ausreicht.

Der Operator verfolgt den gegenteiligen Ansatz. Sicherheit ist strukturell, nicht optional:

  • Nicht-Root als Standard. UID 1000, alle Linux-Capabilities entfernt, seccomp RuntimeDefault. Ein validierender Webhook lehnt jede Spec ab, die runAsUser: 0 setzt. Sie müssten den Webhook entfernen, um als Root zu laufen.
  • Netzwerkisolierung als Standard. Default-Deny-NetworkPolicy auf jeder Instanz. Eingehend: nur gleicher Namespace. Ausgehend: nur DNS und HTTPS. Alles andere ist blockiert, es sei denn, Sie öffnen es explizit.
  • Minimale RBAC-Berechtigungen. Jede Instanz bekommt ihren eigenen ServiceAccount mit einer Role, die nur get und watch auf die eigene ConfigMap gewährt. Ein Agent kann die Geheimnisse, die Konfiguration oder den Zustand eines anderen Agenten nicht lesen.
  • Der Operator selbst läuft als UID 65532 (distroless nonroot), mit schreibgeschütztem Root-Dateisystem, allen Capabilities entfernt und deaktiviertem HTTP/2 zur Absicherung gegen CVE-2023-44487.

All das ist standardmäßig aktiv. Sie bekommen es, ohne darüber nachdenken zu müssen.

Browser-Automatisierung als Sidecar

OpenClaw-Agenten können im Web surfen. Auf einem VPS bedeutet das, einen Chromium-Prozess neben dem Agenten zu betreiben und zu hoffen, dass sie nicht um Ressourcen kämpfen. Der Operator löst das als echten Sidecar:

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

Der Operator fügt einen Browserless Chromium-Container zum Pod hinzu, verbindet das Chrome DevTools Protocol auf Port 9222, injiziert CHROMIUM_URL=ws://localhost:9222 in den Hauptcontainer und gibt Chromium seinen eigenen Security Context (UID 999, Capabilities entfernt), eigene Ressourcenlimits und ein speichergestütztes /dev/shm. Die beiden Container kommunizieren über localhost innerhalb des Pods. Kein Netzwerk-Hop, kein zusätzlicher Service, keine Sicherheitslücke. Auf OpenClaw.rocks aktivieren wir den Chromium-Sidecar standardmäßig für jede Instanz.

Was im Repository enthalten ist

Geschrieben in Go 1.24 mit controller-runtime (Kubebuilder-Pattern). Lizenziert unter Apache 2.0.

  • Vollständige CRD mit 127 KB OpenAPI-Validierungsschema
  • Helm Chart (auch als OCI-Artefakt auf GHCR)
  • Kustomize Overlays für alle, die das bevorzugen
  • Grafana Dashboard und Prometheus Alerts in docs/monitoring/
  • E2E-Tests auf Kind in CI
  • Multi-Architektur-Builds (amd64/arm64)

Der Operator ist auch auf OperatorHub und Artifact Hub gelistet, sodass Sie ihn über die Registries entdecken und installieren können, die Sie bereits nutzen.

Installation:

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

Einen Agenten 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

Browser-Automatisierung, persistenter Speicher, Netzwerkisolierung, Health Monitoring, automatische Config-Rollouts. Eine Ressource. kubectl apply.

Warum Open Source

Ich habe diesen Operator gebaut, um mein eigenes Problem zu lösen. Ich betreibe eine Hosting-Plattform für OpenClaw-Agenten und brauchte produktionsreifes Kubernetes-Tooling dafür. Der Operator ist das Ergebnis dieser Arbeit.

Aber ich glaube auch, dass jedes Unternehmen, das OpenClaw-Agenten im großen Maßstab betreibt, irgendwann bei Kubernetes landen wird und vor denselben Problemen stehen wird wie ich: die Sicherheits-Defaults, die NetworkPolicy-Verkabelung, der Chromium-Sidecar, die Config-Rollouts. Das Ökosystem ist zwei Wochen alt und bereits fragmentiert. Jeder löst diese Probleme unabhängig voneinander.

Die Kosten für die Entwicklung von Software nähern sich null. Und wie ich in OpenClaw ist das neue Linux argumentiert habe, verhindert Offenheit Fragmentierung. Der Operator ist nicht mein Burggraben. Wenn überhaupt, dann ist es die Marke und das Vertrauen, das ich aufbaue, indem ich solche Arbeit teile. Und falls nicht einmal das Bestand hat, habe ich Spaß am Bauen, Schreiben und Teilen. Das reicht. Den Operator proprietär zu halten, würde bedeuten, dass jedes Infrastruktur-Team dieselben Fallstricke wiederentdeckt, die ich entdeckt habe. Das ist Verschwendung, kein Wettbewerbsvorteil.

Wir betreiben diesen Operator in Produktion. Jeder Agent auf OpenClaw.rocks läuft darüber.

Der Code liegt auf github.com/OpenClaw-rocks/k8s-operator. Issues und PRs sind willkommen.

Wenn Sie es lieber nicht selbst betreiben möchten, dafür gibt es OpenClaw.rocks.