Dwa tygodnie temu OpenClaw miał 9 000 gwiazdek na GitHub. Dziś ma 183 000. W międzyczasie wyrosła cała branża. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Jedna strona porównawcza wymienia 33 dostawców, a lista wciąż rośnie. Wrappery OpenClaw zalewają TrustMRR. DigitalOcean udostępnił wdrożenie jednym kliknięciem. Cloudflare zaadaptowało go jako środowisko Workers. Ludzie kupowali Mac Mini, żeby uruchomić osobistych agentów AI w domu.

Jeśli chce Pan/Pani hostować samodzielnie w chmurze, najczęstszą konfiguracją jest VPS na Hetzner za 5 dolarów z 2 vCPU i 4 GB RAM, Docker Compose i klucz API. Uruchom kreator konfiguracji, podłącz go do Anthropic lub OpenRouter, połącz z Telegram. Gotowe w trzydzieści minut. Albo kup Mac Mini, postaw go pod biurkiem i nazwij swoim osobistym JARVIS-em. M4 zużywa siedem watów w stanie spoczynku i sprawdza się jako lokalna maszyna inferencji, jeśli zdecydujesz się na model Pro z 64 GB.

Obie opcje działają dla pojedynczego agenta. Ale kiedy zacząłem budować OpenClaw.rocks, celem było zaoferowanie najbardziej niezawodnego i bezpiecznego sposobu hostowania OpenClaw na dużą skalę, zachowując prostotę dla użytkownika. To wymagało innych fundamentów.

Dlaczego wybrałem Kubernetes

Wcześniej zarządzałem infrastrukturą blockchain w Binance, w tym zabezpieczaniem węzłów Bitcoin. Kiedy Twoim zadaniem jest utrzymywanie cennych obciążeń w izolacji, z możliwością obserwacji i odtwarzania na dużą skalę, wykształcasz silne poglądy na to, jak powinna działać infrastruktura. Kubernetes to narzędzie, któremu w tym zakresie ufam.

OpenClaw to aplikacja jednoosobowa. To osobisty asystent, a nie platforma multi-tenant. Jeśli chcesz uruchomić agentów dla dziesięciu osób, potrzebujesz dziesięciu instancji. Dla stu osób, stu instancji. Każda z własną konfiguracją, własnymi sekretami, własnym magazynem danych, własnymi granicami sieciowymi. Same wymagania izolacji wykluczają wszystko poniżej pełnoprawnej orkiestracji kontenerów.

Nie zamierzam twierdzić, że Kubernetes jest prosty. Nie jest. Dla pojedynczego agenta to absurdalny nadmiar. Ale do uruchamiania wielu agentów dla wielu ludzi rozwiązuje problemy, których nic innego nie rozwiązuje równie dobrze. I uważam, że każda firma, która w końcu będzie uruchamiać agentów OpenClaw na dużą skalę, dojdzie do tego samego wniosku.

Izolacja, która jest naprawdę egzekwowana. Każdy agent działa we własnym namespace z NetworkPolicy, która domyślnie blokuje wszystko. Agent A nie może komunikować się z Agentem B. Agent B nie może uzyskać dostępu do sekretów Agenta A. To nie jest konwencja ani najlepsza praktyka. Jest to egzekwowane przez runtime kontenerów i CNI. Na współdzielonym VPS z Docker Compose izolacja sieciowa między kontenerami wymaga ręcznych reguł iptables, których nikt nie utrzymuje.

Limity zasobów, które zapobiegają awariom kaskadowym. Agent OpenClaw z automatyzacją przeglądarki może zużyć 3 rdzenie CPU i 6 GB pamięci, jeśli mu na to pozwolisz. Na VPS z czterema agentami jeden wymknięty proces Chromium zabija pozostałe trzy. Kubernetes egzekwuje limity CPU i pamięci na kontener. Jeden agent osiągający swój sufit nie wpływa na sąsiadów.

Samonaprawa bez SSH. Kiedy proces na VPS się wywraca, coś musi to zauważyć i go zrestartować. systemd to robi, ale tylko dla hosta. Docker Compose ma polityki restartu, ale nie obejmują one dziesięciu innych rzeczy, które mogą pójść źle: OOM kills, awarie węzłów, problemy z pamięcią masową. Kubernetes restartuje wadliwe kontenery, przenosi pody na inne węzły, gdy te upadają, i uruchamia health probes, które wykrywają problemy na poziomie aplikacji, a nie tylko zakończenia procesów.

Skalowanie bez zgadywania. Uruchamiamy obciążenia agentów na dedykowanej puli węzłów. Kiedy zapotrzebowanie rośnie, cluster autoscaler dodaje węzły. Kiedy maleje, węzły są opróżniane i usuwane. Nie utrzymujemy floty wstępnie skonfigurowanych instancji VPS, licząc, że trafiliśmy z rozmiarem. Infrastruktura dopasowuje się do rzeczywistego obciążenia.

Stan deklaratywny bez dryfu. Cała konfiguracja agenta żyje w jednym custom resource: model, kanały, limity zasobów, reguły sieciowe, pamięć masowa, kontekst bezpieczeństwa. Brak historii SSH do odtworzenia, brak ręcznych edycji do śledzenia, brak dryfu konfiguracji między tym, co myślisz, że działa, a tym, co naprawdę działa.

Żadna z tych rzeczy nie ma znaczenia dla jednego agenta na jednej maszynie. Wszystkie mają znaczenie, gdy ponosisz odpowiedzialność za niezawodne działanie agentów innych ludzi.

Operator

Kubernetes dostarcza prymitywy. Operator sprawia, że stają się użyteczne.

Bez Operatora wdrożenie instancji OpenClaw na Kubernetes oznacza ręczne napisanie jedenastu zasobów: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Z Operatorem wystarczy jeden:

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

Operator obserwuje ten custom resource i tworzy wszystko inne. To pętla sterowania: przy każdej zmianie dowolnego zarządzanego zasobu i co najmniej raz na pięć minut jako siatka bezpieczeństwa, porównuje stan pożądany ze stanem rzeczywistym i uzgadnia różnice. Jeśli ktoś usunie NetworkPolicy, wraca ona. Jeśli Deployment odbiega od normy, jest korygowany. Usunięcie custom resource powoduje kaskadowe czyszczenie przez owner references. Żadnych osieroconych Services, żadnych pozostawionych PVCs.

Dziś udostępniamy go jako open source: github.com/OpenClaw-rocks/k8s-operator.

Bezpieczeństwo domyślnie, nie z checklisty

SecurityScorecard znalazł w zeszłym tygodniu 135 000 instancji OpenClaw wystawionych na publiczny Internet. CVE-2026-25253 zademonstrował zdalne wykonanie kodu jednym kliknięciem poprzez eksfiltrację tokenów gateway. Gartner zalecił organizacjom całkowite zablokowanie. W rejestrze ClawHub znaleziono 341 złośliwych skilli.

Taka jest rzeczywistość uruchamiania agentów AI w 2026 roku. Domyślna konfiguracja OpenClaw nasłuchuje na 0.0.0.0 bez uwierzytelniania. Na VPS bez prawidłowo skonfigurowanej zapory ogniowej jesteś o jeden skan portów od dania nieznajomemu dostępu do powłoki Twojego serwera. Opisaliśmy pełny zakres kryzysu bezpieczeństwa i wyjaśniliśmy, dlaczego nawet token gateway nie wystarczy.

Operator przyjmuje odwrotne podejście. Bezpieczeństwo jest strukturalne, nie opcjonalne:

  • Non-root domyślnie. UID 1000, wszystkie capability Linuksa usunięte, seccomp RuntimeDefault. Webhook walidacyjny odrzuca każdą specyfikację ustawiającą runAsUser: 0. Trzeba by usunąć webhook, żeby uruchomić jako root.
  • Izolacja sieciowa domyślnie. Domyślna NetworkPolicy deny-all na każdej instancji. Ruch przychodzący: tylko ten sam namespace. Ruch wychodzący: tylko DNS i HTTPS. Wszystko inne jest zablokowane, chyba że jawnie je otworzysz.
  • RBAC z zasadą minimalnych uprawnień. Każda instancja otrzymuje własny ServiceAccount z Role, który przyznaje tylko get i watch na własnej ConfigMap. Agent nie może czytać sekretów, konfiguracji ani stanu innego agenta.
  • Sam Operator działa jako UID 65532 (distroless nonroot), system plików root tylko do odczytu, wszystkie capability usunięte, HTTP/2 wyłączony w celu łagodzenia CVE-2023-44487.

Wszystko to jest domyślnie aktywne. Dostajesz to bez zastanawiania się.

Automatyzacja przeglądarki jako sidecar

Agenci OpenClaw mogą przeglądać internet. Na VPS oznacza to uruchomienie procesu Chromium obok agenta i nadzieję, że nie będą rywalizować o zasoby. Operator obsługuje to jako właściwy sidecar:

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

Operator dodaje kontener Browserless Chromium do poda, podłącza Chrome DevTools Protocol na porcie 9222, wstrzykuje CHROMIUM_URL=ws://localhost:9222 do głównego kontenera i nadaje Chromium własny kontekst bezpieczeństwa (UID 999, capability usunięte), własne limity zasobów i wspierany pamięcią /dev/shm. Dwa kontenery komunikują się przez localhost wewnątrz poda. Bez skoku sieciowego, bez dodatkowego Service, bez ekspozycji bezpieczeństwa. Na OpenClaw.rocks włączamy sidecar Chromium domyślnie dla każdej instancji.

Co jest w repozytorium

Napisany w Go 1.24 z controller-runtime (wzorzec Kubebuilder). Licencja Apache 2.0.

  • Pełna CRD z 127 KB schematu walidacji OpenAPI
  • Helm Chart (również jako artefakt OCI na GHCR)
  • Nakładki Kustomize dla tych, którzy je preferują
  • Dashboard Grafana i alerty Prometheus w docs/monitoring/
  • Testy E2E na Kind w CI
  • Buildy wieloarchitekturowe (amd64/arm64)

Operator jest również wymieniony na OperatorHub i Artifact Hub, więc można go odkryć i zainstalować przez rejestry, z których już korzystasz.

Instalacja:

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

Wdrożenie agenta:

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

Automatyzacja przeglądarki, trwałe przechowywanie danych, izolacja sieciowa, monitorowanie stanu, automatyczne wdrożenia konfiguracji. Jeden zasób. kubectl apply.

Dlaczego open source

Zbudowałem tego Operatora, żeby rozwiązać własny problem. Prowadzę platformę hostingową dla agentów OpenClaw i potrzebowałem narzędzi Kubernetes klasy produkcyjnej. Operator jest wynikiem tej pracy.

Ale uważam też, że każda firma uruchamiająca agentów OpenClaw na dużą skalę trafi w końcu na Kubernetes i stanie przed tymi samymi problemami co ja: domyślne ustawienia bezpieczeństwa, konfiguracja NetworkPolicy, sidecar Chromium, wdrożenia konfiguracji. Ekosystem ma dwa tygodnie i jest już sfragmentowany. Każdy rozwiązuje te problemy niezależnie.

Koszt tworzenia oprogramowania zbliża się do zera. I jak argumentowałem w OpenClaw to nowy Linux, otwartość zapobiega fragmentacji. Operator nie jest moją fosą obronną. Jeśli cokolwiek nią jest, to marka i zaufanie, które buduję, dzieląc się taką pracą. A jeśli nawet to się nie sprawdzi, bawię się dobrze, budując, pisząc i dzieląc się. To wystarczy. Utrzymywanie Operatora jako własnościowego oznaczałoby, że każdy zespół infrastrukturalny odkrywa na nowo te same pułapki, na które ja trafiłem. To marnotrawstwo, nie przewaga konkurencyjna.

Używamy tego Operatora na produkcji. Każdy agent na OpenClaw.rocks przechodzi przez niego.

Kod jest na github.com/OpenClaw-rocks/k8s-operator. Issues i PR-y mile widziane.

Jeśli wolisz nie zarządzać tym samodzielnie, właśnie do tego służy OpenClaw.rocks.