Két héttel ezelőtt az OpenClaw-nak 9000 GitHub-csillaga volt. Ma 183 000. Közben egy egész iparág nőtt ki. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Egy összehasonlító oldal 33 szolgáltatót számol, és a lista tovább bővül. Az OpenClaw-wrapperek elárasztják a TrustMRR-t. A DigitalOcean kiadott egy egykattintásos telepítést. A Cloudflare Workers-futtatókörnyezetté alakította. Az emberek Mac Miniket vásároltak, hogy személyes AI-ügynököket futtassanak otthon.

Ha a felhőben szeretne saját hosztolást végezni, a leggyakoribb beállítás egy 5 dolláros Hetzner VPS 2 vCPU-val és 4 GB RAM-mal, Docker Compose és egy API-kulcs. Futtassa a beállítási varázslót, csatlakoztassa az Anthropic-hoz vagy OpenRouter-hez, kösse össze a Telegram-mal. Harminc perc alatt kész. Vagy vegyen egy Mac Minit, tegye az asztal alá, és nevezze el személyes JARVIS-ának. Az M4 hét wattot fogyaszt üresjáratban, és helyi inferencia-gépként is működik, ha a 64 GB-os Pro modellt választja.

Mindkét megoldás működik egyetlen ügynökhöz. De amikor elkezdtem építeni az OpenClaw.rocks-ot, a cél az volt, hogy a legmegbízhatóbb és legbiztonságosabb módot kínáljam az OpenClaw nagy léptékű hosztolásához, miközben a felhasználó számára egyszerű marad. Ehhez más alapokra volt szükség.

Miért választottam a Kubernetes-t

Korábban a Binance-nél kezeltem blockchain-infrastruktúrát, beleértve a Bitcoin-csomópontok védelmét. Ha az ember munkája az, hogy nagy értékű munkaterheléseket tartson izoláltan, megfigyelhetően és helyreállíthatóan nagy léptékben, akkor erős véleményt alakít ki arról, hogyan kellene működnie az infrastruktúrának. A Kubernetes az, amiben megbízom ehhez.

Az OpenClaw egyfelhasználós alkalmazás. Személyes asszisztens, nem multi-tenant platform. Ha tíz ember számára szeretne ügynököket futtatni, tíz példányra van szükség. Száz emberhez száz példány. Mindegyik saját konfigurációval, saját titkokkal, saját tárolóval, saját hálózati határokkal. Már az izolációs követelmények önmagukban kizárnak bármit, ami kevesebb, mint megfelelő konténer-orkesztráció.

Nem fogom azt állítani, hogy a Kubernetes egyszerű. Nem az. Egyetlen ügynökhöz abszurd túlzás. De sok ügynök sok ember számára történő futtatásához olyan problémákat old meg, amelyeket semmi más nem old meg ilyen jól. És úgy gondolom, hogy bármelyik vállalat, amely végül nagy léptékben futtat OpenClaw-ügynököket, ugyanerre a következtetésre jut.

Ténylegesen érvényesített izoláció. Minden ügynök a saját namespace-ében fut egy NetworkPolicy-vel, amely alapértelmezetten mindent megtagad. Az A ügynök nem tud kommunikálni a B ügynökkel. A B ügynök nem éri el az A ügynök titkait. Ez nem konvenció vagy bevált gyakorlat. A konténer-futtatókörnyezet és a CNI kényszeríti ki. Megosztott VPS-en Docker Compose-zal a konténerek közötti hálózati izoláció kézi iptables-szabályokat igényel, amelyeket senki nem tart karban.

Erőforrás-korlátok, amelyek megakadályozzák a kaszkádhibákat. Egy OpenClaw-ügynök böngésző-automatizálással 3 CPU-magot és 6 GB memóriát fogyaszthat, ha hagyják. Egy VPS-en négy ügynökkel egyetlen elszabadult Chromium-folyamat megöli a másik hármat. A Kubernetes konténerenként kényszeríti ki a CPU- és memóriakorlátokat. Az a ügynök, amelyik eléri a plafonját, nem befolyásolja a szomszédait.

Öngyógyulás SSH nélkül. Ha egy VPS-folyamat összeomlik, valaminek észre kell vennie és újra kell indítania. A systemd megteszi, de csak a hoszthoz. A Docker Compose-nak vannak újraindítási szabályai, de ezek nem fedik le a tíz másik dolgot, ami rosszul sülhet el: OOM-kiölések, csomópont-meghibásodások, tárolási problémák. A Kubernetes újraindítja a hibás konténereket, átütemezi a pod-okat, amikor csomópontok esnek ki, és health probe-okat futtat, amelyek alkalmazásszintű problémákat észlelnek, nem csak folyamat-leállásokat.

Skálázás találgatás nélkül. Az ügynök-munkaterheléseket dedikált csomópontkészleten futtatjuk. Amikor a kereslet nő, a cluster autoscaler csomópontokat ad hozzá. Amikor csökken, a csomópontok kiürülnek és eltávolításra kerülnek. Nem tartunk fenn előre provizionált VPS-példányokból álló flottát abban a reményben, hogy jól méreteztük. Az infrastruktúra a tényleges terheléshez igazodik.

Deklaratív állapot sodródás nélkül. Egy ügynök teljes konfigurációja egyetlen custom resource-ban él: a modell, a csatornák, az erőforráskorlátok, a hálózati szabályok, a tárolás, a biztonsági kontextus. Nincs SSH-előzmény, amit rekonstruálni kellene, nincs kézi szerkesztés, amit nyomon kellene követni, nincs konfigurációs sodródás aközött, amit futni gondol, és ami tényleg fut.

Ezek egyike sem számít egyetlen ügynökhöz egyetlen gépen. Mindegyik számít, amikor Ön felelős más emberek ügynökeinek megbízható működéséért.

Az Operator

A Kubernetes biztosítja az alapépítőköveket. Az Operator az, ami használhatóvá teszi őket.

Operator nélkül egy OpenClaw-példány telepítése Kubernetes-en tizenegy erőforrás kézi megírását jelenti: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Operatorral egyetlen egy kell:

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

Az Operator figyeli ezt a custom resource-ot, és mindent mást létrehoz. Ez egy vezérlőhurok: minden kezelt erőforrás minden módosításakor, és legalább ötpercenként biztonsági hálóként, összehasonlítja a kívánt állapotot a ténylegessel, és kiegyenlíti a különbséget. Ha valaki töröl egy NetworkPolicy-t, az visszatér. Ha egy Deployment eltér, javításra kerül. Törölje a custom resource-ot, és az owner reference-ek kaszkádszerűen végrehajtják a tisztítást. Nincsenek árva Service-ek, nincsenek maradvány PVC-k.

Ma nyílt forráskódúvá tesszük: github.com/OpenClaw-rocks/k8s-operator.

Alapértelmezett biztonság, nem ellenőrzőlista

A SecurityScorecard múlt héten 135 000 OpenClaw-példányt talált a nyilvános internetre kitéve. A CVE-2026-25253 egykattintásos távoli kódfuttatást demonstrált gateway-token kiszivárogtatással. A Gartner azt javasolta a szervezeteknek, hogy teljesen blokkolják. 341 rosszindulatú skill-t találtak a ClawHub-nyilvántartásban.

Ez a valóság az AI-ügynökök futtatásáról 2026-ban. Az OpenClaw alapértelmezett konfigurációja a 0.0.0.0 címen figyel hitelesítés nélkül. Egy VPS-en megfelelően konfigurált tűzfal nélkül egyetlen portszkennelés választja el attól, hogy egy idegen shell-hozzáférést kapjon a szerveréhez. Lefedtük a biztonsági válság teljes terjedelmét, és hogy miért nem elég még egy gateway-token sem.

Az Operator az ellenkező megközelítést alkalmazza. A biztonság strukturális, nem opcionális:

  • Alapértelmezetten nem root. UID 1000, minden Linux-capability eltávolítva, seccomp RuntimeDefault. Egy validáló webhook elutasít minden spec-et, amely runAsUser: 0-t állít be. El kellene távolítania a webhook-ot, hogy root-ként fusson.
  • Alapértelmezett hálózati izoláció. Alapértelmezett deny-all NetworkPolicy minden példányon. Bejövő: csak azonos namespace. Kimenő: csak DNS és HTTPS. Minden más blokkolva van, hacsak nem nyitja meg kifejezetten.
  • Legkisebb jogosultságú RBAC. Minden példány saját ServiceAccount-ot kap egy Role-lal, amely csak get és watch jogot ad a saját ConfigMap-jéhez. Egy ügynök nem olvashatja egy másik ügynök titkait, konfigurációját vagy állapotát.
  • Maga az Operator UID 65532-ként fut (distroless nonroot), csak olvasható root fájlrendszerrel, minden capability eltávolítva, HTTP/2 letiltva a CVE-2023-44487 mérséklése érdekében.

Mindez alapértelmezetten aktív. Gondolkodás nélkül megkapja.

Böngésző-automatizálás sidecar-ként

Az OpenClaw-ügynökök böngészhetik a webet. VPS-en ez azt jelenti, hogy egy Chromium-folyamatot futtat az ügynök mellett, és reméli, hogy nem versenyeznek az erőforrásokért. Az Operator ezt megfelelő sidecar-ként kezeli:

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

Az Operator hozzáad egy Browserless Chromium konténert a pod-hoz, bekötözi a Chrome DevTools Protocol-t a 9222-es porton, beinjektálja a CHROMIUM_URL=ws://localhost:9222-t a fő konténerbe, és saját biztonsági kontextust (UID 999, capability-k eltávolítva), saját erőforráskorlátokat és memória-alapú /dev/shm-et ad a Chromiumnak. A két konténer localhost-on keresztül kommunikál a pod-on belül. Nincs hálózati ugrás, nincs extra Service, nincs biztonsági kitettség. Az OpenClaw.rocks-on alapértelmezetten engedélyezzük a Chromium sidecar-t minden példányhoz.

Mi van a repository-ban

Go 1.24-ben írva controller-runtime-mal (Kubebuilder-minta). Apache 2.0 licenc.

  • Teljes CRD 127 KB-os OpenAPI validációs sémával
  • Helm Chart (OCI-artefaktumként is elérhető a GHCR-en)
  • Kustomize overlay-ek azoknak, akik ezt preferálják
  • Grafana dashboard és Prometheus riasztások a docs/monitoring/ könyvtárban
  • E2E tesztek Kind-on CI-ban
  • Több architektúrás build-ek (amd64/arm64)

Az Operator az OperatorHub-on és az Artifact Hub-on is megtalálható, így felfedezheti és telepítheti a már használt regiszterekből.

Telepítés:

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

Ügynök telepítése:

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

Böngésző-automatizálás, perzisztens tárolás, hálózati izoláció, állapotfigyelés, automatikus konfigurációs kivezetések. Egyetlen erőforrás. kubectl apply.

Miért nyílt forráskódú

Azért építettem ezt az Operatort, hogy megoldjam a saját problémámat. Egy hosting platformot üzemeltetek OpenClaw-ügynökök számára, és produkciós szintű Kubernetes-eszközökre volt szükségem. Az Operator ennek a munkának az eredménye.

De azt is gondolom, hogy bármely vállalat, amely nagy léptékben futtat OpenClaw-ügynököket, végül a Kubernetes-en köt ki, és ugyanazokkal a problémákkal szembesül, mint én: a biztonsági alapértékek, a NetworkPolicy-bekötés, a Chromium sidecar, a konfigurációs kivezetések. Az ökoszisztéma két hetes, és már széttagolt. Mindenki önállóan oldja meg ezeket a problémákat.

A szoftverek építésének költsége közelít a nullához. És ahogy az OpenClaw az új Linux című cikkemben érveltem, a nyitottság megakadályozza a széttagolódást. Az Operator nem az én védőárkom. Ha valami az, akkor az a márka és a bizalom, amelyet az ilyen munkák megosztásával építek. És ha még ez sem állja meg a helyét, jól szórakozom az építéssel, írással és megosztással. Ez elég. Az Operator zárt forráskódú megtartása azt jelentené, hogy minden infrastruktúra-csapat újra felfedezi ugyanazokat a buktatókat, amelyeket én fedeztem fel. Ez pazarlás, nem versenyelőny.

Élesben használjuk ezt az Operatort. Az OpenClaw.rocks minden ügynöke rajta keresztül fut.

A kód a github.com/OpenClaw-rocks/k8s-operator címen érhető el. Issue-k és PR-ek szívesen fogadva.

Ha inkább nem szeretné maga üzemeltetni, pontosan erre való az OpenClaw.rocks.