Há duas semanas, o OpenClaw tinha 9.000 estrelas no GitHub. Hoje tem 183.000. Entretanto, surgiu toda uma indústria artesanal. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Um site de comparação conta 33 fornecedores e a lista continua a crescer. Os wrappers de OpenClaw estão a invadir o TrustMRR. A DigitalOcean lançou um deploy com um clique. A Cloudflare adaptou-o num runtime Workers. Pessoas compravam Mac Minis para executar agentes de IA pessoais em casa.

Se pretende fazer self-hosting na cloud, a configuração mais comum é um VPS Hetzner de 5 dólares com 2 vCPUs e 4 GB de RAM, Docker Compose e uma chave API. Execute o assistente de integração, ligue-o ao Anthropic ou OpenRouter, conecte o Telegram. Pronto em trinta minutos. Ou compre um Mac Mini, coloque-o debaixo da secretária e chame-lhe o seu JARVIS pessoal. O M4 consome sete watts em repouso e funciona como máquina de inferência local se optar pelo modelo Pro de 64 GB.

Ambas as opções funcionam para um único agente. Mas quando comecei a construir o OpenClaw.rocks, o objetivo era oferecer a forma mais fiável e segura de alojar o OpenClaw em escala, mantendo a experiência simples para o utilizador. Isso exigia uma base diferente.

Porque escolhi Kubernetes

Costumava gerir infraestrutura blockchain na Binance, incluindo a proteção dos nós de Bitcoin. Quando o seu trabalho é manter workloads de alto valor isolados, observáveis e recuperáveis em escala, desenvolvem-se opiniões fortes sobre como a infraestrutura deve funcionar. Kubernetes é aquilo em que confio para isso.

O OpenClaw é uma aplicação de utilizador único. É um assistente pessoal, não uma plataforma multi-tenant. Se quiser executar agentes para dez pessoas, precisa de dez instâncias. Para cem pessoas, cem instâncias. Cada uma com a sua própria configuração, os seus próprios segredos, o seu próprio armazenamento, as suas próprias fronteiras de rede. Os requisitos de isolamento por si só excluem qualquer coisa abaixo de uma orquestração de contentores adequada.

Não vou defender que o Kubernetes é simples. Não é. Para um único agente, é um exagero absurdo. Mas para executar muitos agentes para muitas pessoas, resolve problemas que mais nada resolve tão bem. E penso que qualquer empresa que acabe por executar agentes OpenClaw em escala chegará à mesma conclusão.

Isolamento que é realmente aplicado. Cada agente corre no seu próprio namespace com uma NetworkPolicy que nega tudo por defeito. O agente A não consegue comunicar com o agente B. O agente B não consegue aceder aos segredos do agente A. Isto não é uma convenção nem uma boa prática. É aplicado pelo runtime de contentores e pelo CNI. Num VPS partilhado com Docker Compose, o isolamento de rede entre contentores requer regras iptables manuais que ninguém mantém.

Limites de recursos que previnem falhas em cascata. Um agente OpenClaw com automação de browser pode consumir 3 cores de CPU e 6 GB de memória se o deixar. Num VPS com quatro agentes, um processo Chromium descontrolado mata os outros três. O Kubernetes aplica limites de CPU e memória por contentor. Um agente que atinge o seu limite não afeta os vizinhos.

Auto-reparação sem SSH. Quando um processo num VPS falha, algo precisa de o detetar e reiniciar. O systemd faz isto, mas apenas para o host. O Docker Compose tem políticas de reinício, mas não cobrem as outras dez coisas que podem correr mal: OOM kills, falhas de nós, problemas de armazenamento. O Kubernetes reinicia contentores falhados, reagenda pods quando os nós morrem e executa health probes que detetam problemas ao nível da aplicação, não apenas terminações de processos.

Escalamento sem adivinhação. Executamos os workloads dos agentes num pool de nós dedicado. Quando a procura aumenta, o cluster autoscaler adiciona nós. Quando diminui, os nós são drenados e removidos. Não mantemos uma frota de instâncias VPS pré-provisionadas na esperança de ter dimensionado corretamente. A infraestrutura adapta-se à carga real.

Estado declarativo sem desvio. Toda a configuração de um agente reside numa única custom resource: o modelo, os canais, os limites de recursos, as regras de rede, o armazenamento, o contexto de segurança. Sem histórico SSH para reconstruir, sem edições manuais para rastrear, sem desvio de configuração entre o que se pensa estar em execução e o que realmente está.

Nada disto importa para um agente numa máquina. Tudo importa quando se é responsável pelo funcionamento fiável dos agentes de outras pessoas.

O Operator

O Kubernetes fornece as primitivas. Um Operator é o que as torna utilizáveis.

Sem um Operator, fazer o deploy de uma instância OpenClaw no Kubernetes significa escrever onze recursos à mão: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Com um Operator, basta um:

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

O Operator vigia esta custom resource e cria tudo o resto. É um loop de controlo: a cada alteração em qualquer recurso gerido, e pelo menos a cada cinco minutos como rede de segurança, compara o estado desejado com o estado real e reconcilia a diferença. Se alguém apagar uma NetworkPolicy, ela volta. Se um Deployment se desviar, é corrigido. Apague a custom resource e as owner references propagam a limpeza em cascata. Sem Services órfãos, sem PVCs residuais.

Hoje publicamo-lo como open source: github.com/OpenClaw-rocks/k8s-operator.

Segurança por defeito, não por checklist

A SecurityScorecard encontrou 135.000 instâncias OpenClaw expostas na Internet pública na semana passada. O CVE-2026-25253 demonstrou execução remota de código com um clique através da exfiltração de tokens de gateway. A Gartner recomendou às organizações que o bloqueassem completamente. Foram encontrados 341 skills maliciosos no registo do ClawHub.

Esta é a realidade de executar agentes de IA em 2026. A configuração predefinida do OpenClaw liga-se a 0.0.0.0 sem autenticação. Num VPS sem uma firewall corretamente configurada, está a um scan de portas de dar acesso shell ao seu servidor a um desconhecido. Cobrimos o alcance completo da crise de segurança e porque é que mesmo um token de gateway não é suficiente.

O Operator adota a abordagem oposta. A segurança é estrutural, não opcional:

  • Non-root por defeito. UID 1000, todas as capabilities Linux removidas, seccomp RuntimeDefault. Um webhook de validação rejeita qualquer spec que defina runAsUser: 0. Seria necessário remover o webhook para executar como root.
  • Isolamento de rede por defeito. NetworkPolicy deny-all por defeito em cada instância. Entrada: apenas o mesmo namespace. Saída: apenas DNS e HTTPS. Tudo o resto está bloqueado a menos que o abra explicitamente.
  • RBAC de privilégio mínimo. Cada instância recebe o seu próprio ServiceAccount com um Role que apenas concede get e watch na sua própria ConfigMap. Um agente não consegue ler os segredos, a configuração ou o estado de outro agente.
  • O próprio Operator corre como UID 65532 (distroless nonroot), sistema de ficheiros raiz em modo de leitura, todas as capabilities removidas, HTTP/2 desativado para mitigar CVE-2023-44487.

Tudo isto está ativo por defeito. Obtém-se sem ter de pensar nisso.

Automação de browser como sidecar

Os agentes OpenClaw conseguem navegar na web. Num VPS, isso significa executar um processo Chromium junto ao agente e esperar que não disputem recursos. O Operator trata isto como um sidecar adequado:

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

O Operator adiciona um contentor Browserless Chromium ao pod, configura o Chrome DevTools Protocol na porta 9222, injeta CHROMIUM_URL=ws://localhost:9222 no contentor principal e dá ao Chromium o seu próprio contexto de segurança (UID 999, capabilities removidas), os seus próprios limites de recursos e um /dev/shm em memória. Os dois contentores comunicam via localhost dentro do pod. Sem salto de rede, sem Service adicional, sem exposição de segurança. No OpenClaw.rocks, ativamos o sidecar Chromium por defeito para cada instância.

O que está no repositório

Escrito em Go 1.24 com controller-runtime (padrão Kubebuilder). Licenciado sob Apache 2.0.

  • CRD completa com esquema de validação OpenAPI de 127 KB
  • Helm Chart (também como artefacto OCI no GHCR)
  • Overlays Kustomize para quem preferir
  • Dashboard Grafana e alertas Prometheus em docs/monitoring/
  • Testes E2E em Kind na CI
  • Builds multi-arquitetura (amd64/arm64)

O Operator também está listado no OperatorHub e no Artifact Hub, para que o possa descobrir e instalar através dos registos que já utiliza.

Instalação:

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

Deploy de um agente:

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

Automação de browser, armazenamento persistente, isolamento de rede, monitorização de saúde, rollouts automáticos de configuração. Um recurso. kubectl apply.

Porquê open source

Construí este Operator para resolver o meu próprio problema. Giro uma plataforma de alojamento para agentes OpenClaw e precisava de ferramentas Kubernetes de nível produtivo. O Operator é o resultado desse trabalho.

Mas também acredito que qualquer empresa que execute agentes OpenClaw em escala acabará no Kubernetes e enfrentará os mesmos problemas que eu enfrentei: as predefinições de segurança, a configuração das NetworkPolicy, o sidecar Chromium, os rollouts de configuração. O ecossistema tem duas semanas de vida e já está fragmentado. Cada um resolve estes problemas de forma independente.

O custo de construir software está a aproximar-se de zero. E como argumentei em OpenClaw é o novo Linux, a abertura previne a fragmentação. O Operator não é a minha vantagem competitiva. Se algo o é, é a marca e a confiança que construo ao partilhar trabalho como este. E se nem isso se mantiver, estou a divertir-me a construir, escrever e partilhar. Isso é suficiente. Manter o Operator proprietário significaria que cada equipa de infraestrutura redescobriria os mesmos problemas que eu descobri. Isso é desperdício, não vantagem competitiva.

Utilizamos este Operator em produção. Cada agente no OpenClaw.rocks passa por ele.

O código está em github.com/OpenClaw-rocks/k8s-operator. Issues e PRs são bem-vindos.

Se preferir não o gerir pessoalmente, é para isso que existe o OpenClaw.rocks.