Hace dos semanas, OpenClaw tenía 9.000 estrellas en GitHub. Hoy tiene 183.000. En el ínterin, surgió toda una industria artesanal. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Un sitio de comparación cuenta 33 proveedores y la lista sigue creciendo. Los wrappers de OpenClaw están invadiendo TrustMRR. DigitalOcean lanzó un despliegue en un clic. Cloudflare lo adaptó como un entorno de ejecución Workers. La gente compraba Mac Minis para ejecutar agentes de IA personales en casa.

Si desea auto-alojar en la nube, la configuración más habitual es un VPS de Hetzner a 5 dólares con 2 vCPUs y 4 GB de RAM, Docker Compose y una clave API. Ejecute el asistente de incorporación, conéctelo a Anthropic o OpenRouter, active Telegram. Listo en treinta minutos. O compre un Mac Mini, colóquelo bajo su escritorio y llámelo su JARVIS personal. El M4 consume siete vatios en reposo y funciona como máquina de inferencia local si opta por el modelo Pro de 64 GB.

Ambas opciones funcionan para un solo agente. Pero cuando empecé a construir OpenClaw.rocks, el objetivo era ofrecer la forma más fiable y segura de alojar OpenClaw a gran escala, manteniendo la experiencia sencilla para el usuario. Eso requería una base diferente.

Por qué elegí Kubernetes

Solía gestionar infraestructura blockchain en Binance, incluyendo la protección de los nodos de Bitcoin. Cuando tu trabajo consiste en mantener cargas de trabajo de alto valor aisladas, observables y recuperables a gran escala, desarrollas opiniones firmes sobre cómo debe funcionar la infraestructura. Kubernetes es en lo que confío para ello.

OpenClaw es una aplicación de un solo usuario. Es un asistente personal, no una plataforma multi-tenant. Si desea ejecutar agentes para diez personas, necesita diez instancias. Para cien personas, cien instancias. Cada una con su propia configuración, sus propios secretos, su propio almacenamiento, sus propios límites de red. Solo los requisitos de aislamiento descartan cualquier cosa por debajo de una orquestación de contenedores adecuada.

No voy a defender que Kubernetes sea simple. No lo es. Para un solo agente, es una exageración absurda. Pero para ejecutar muchos agentes para muchas personas, resuelve problemas que nada más resuelve igual de bien. Y creo que cualquier empresa que termine ejecutando agentes OpenClaw a gran escala llegará a la misma conclusión.

Aislamiento que se aplica de verdad. Cada agente se ejecuta en su propio namespace con una NetworkPolicy que deniega todo por defecto. El agente A no puede comunicarse con el agente B. El agente B no puede acceder a los secretos del agente A. Esto no es una convención ni una buena práctica. Lo aplican el runtime de contenedores y el CNI. En un VPS compartido con Docker Compose, el aislamiento de red entre contenedores requiere reglas iptables manuales que nadie mantiene.

Límites de recursos que previenen fallos en cascada. Un agente OpenClaw con automatización del navegador puede consumir 3 núcleos de CPU y 6 GB de memoria si se lo permite. En un VPS con cuatro agentes, un proceso Chromium descontrolado mata a los otros tres. Kubernetes aplica límites de CPU y memoria por contenedor. Un agente que alcanza su techo no afecta a sus vecinos.

Auto-reparación sin SSH. Cuando un proceso en un VPS falla, algo necesita detectarlo y reiniciarlo. systemd lo hace, pero solo para el host. Docker Compose tiene políticas de reinicio, pero no cubren las otras diez cosas que pueden salir mal: OOM kills, fallos de nodo, problemas de almacenamiento. Kubernetes reinicia contenedores fallidos, reprograma pods cuando los nodos caen y ejecuta health probes que detectan problemas a nivel de aplicación, no solo terminaciones de procesos.

Escalado sin adivinar. Ejecutamos las cargas de trabajo de los agentes en un pool de nodos dedicado. Cuando la demanda aumenta, el cluster autoscaler añade nodos. Cuando disminuye, los nodos se drenan y eliminan. No mantenemos una flota de instancias VPS pre-provisionadas esperando haber acertado con el dimensionamiento. La infraestructura se adapta a la carga real.

Estado declarativo sin deriva. Toda la configuración de un agente reside en un único custom resource: el modelo, los canales, los límites de recursos, las reglas de red, el almacenamiento, el contexto de seguridad. No hay historial SSH que reconstruir, no hay ediciones manuales que rastrear, no hay deriva de configuración entre lo que cree que está ejecutándose y lo que realmente se ejecuta.

Nada de esto importa para un agente en una máquina. Todo importa cuando usted es responsable de que los agentes de otras personas funcionen de manera fiable.

El Operator

Kubernetes proporciona los primitivos. Un Operator es lo que los hace utilizables.

Sin un Operator, desplegar una instancia de OpenClaw en Kubernetes significa escribir once recursos a mano: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. Con un Operator, solo se necesita uno:

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

El Operator vigila este custom resource y crea todo lo demás. Es un bucle de control: ante cada cambio en cualquier recurso gestionado, y al menos cada cinco minutos como red de seguridad, compara el estado deseado con el estado real y reconcilia la diferencia. Si alguien elimina una NetworkPolicy, vuelve a aparecer. Si un Deployment se desvía, se corrige. Elimine el custom resource y las owner references propagan la limpieza en cascada. Sin Services huérfanos, sin PVCs residuales.

Hoy lo publicamos como open source: github.com/OpenClaw-rocks/k8s-operator.

Seguridad por defecto, no por checklist

SecurityScorecard encontró 135.000 instancias de OpenClaw expuestas a Internet público la semana pasada. CVE-2026-25253 demostró la ejecución remota de código con un clic mediante la exfiltración de tokens de gateway. Gartner recomendó a las organizaciones bloquearlo por completo. Se encontraron 341 skills maliciosos en el registro de ClawHub.

Esta es la realidad de ejecutar agentes de IA en 2026. La configuración predeterminada de OpenClaw escucha en 0.0.0.0 sin autenticación. En un VPS sin un firewall correctamente configurado, está a un escaneo de puertos de dar acceso shell a su servidor a un desconocido. Cubrimos el alcance completo de la crisis de seguridad y por qué incluso un token de gateway no es suficiente.

El Operator adopta el enfoque opuesto. La seguridad es estructural, no opcional:

  • Non-root por defecto. UID 1000, todas las capabilities de Linux eliminadas, seccomp RuntimeDefault. Un webhook de validación rechaza cualquier spec que establezca runAsUser: 0. Tendría que eliminar el webhook para ejecutar como root.
  • Aislamiento de red por defecto. NetworkPolicy deny-all por defecto en cada instancia. Entrada: solo el mismo namespace. Salida: solo DNS y HTTPS. Todo lo demás está bloqueado a menos que lo abra explícitamente.
  • RBAC de mínimo privilegio. Cada instancia obtiene su propio ServiceAccount con un Role que solo concede get y watch sobre su propia ConfigMap. Un agente no puede leer los secretos, la configuración ni el estado de otro agente.
  • El propio Operator se ejecuta como UID 65532 (distroless nonroot), sistema de archivos raíz de solo lectura, todas las capabilities eliminadas, HTTP/2 deshabilitado para mitigar CVE-2023-44487.

Todo esto está activo por defecto. Lo obtiene sin pensar en ello.

Automatización del navegador como sidecar

Los agentes OpenClaw pueden navegar por la web. En un VPS, eso significa ejecutar un proceso Chromium junto al agente y esperar que no compitan por los recursos. El Operator gestiona esto como un sidecar adecuado:

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

El Operator añade un contenedor Browserless Chromium al pod, conecta el Chrome DevTools Protocol en el puerto 9222, inyecta CHROMIUM_URL=ws://localhost:9222 en el contenedor principal, y le da a Chromium su propio contexto de seguridad (UID 999, capabilities eliminadas), sus propios límites de recursos y un /dev/shm respaldado por memoria. Los dos contenedores se comunican por localhost dentro del pod. Sin salto de red, sin Service adicional, sin exposición de seguridad. En OpenClaw.rocks, habilitamos el sidecar Chromium por defecto para cada instancia.

Qué contiene el repositorio

Escrito en Go 1.24 con controller-runtime (patrón Kubebuilder). Licenciado bajo Apache 2.0.

  • CRD completa con un esquema de validación OpenAPI de 127 KB
  • Helm Chart (también como artefacto OCI en GHCR)
  • Overlays de Kustomize para quienes lo prefieran
  • Dashboard de Grafana y alertas de Prometheus en docs/monitoring/
  • Tests E2E en Kind en CI
  • Builds multi-arquitectura (amd64/arm64)

El Operator también está listado en OperatorHub y Artifact Hub, para que pueda descubrirlo e instalarlo a través de los registros que ya utiliza.

Instalación:

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

Desplegar un 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

Automatización del navegador, almacenamiento persistente, aislamiento de red, monitorización de salud, despliegues automáticos de configuración. Un recurso. kubectl apply.

Por qué open source

Construí este Operator para resolver mi propio problema. Gestiono una plataforma de alojamiento para agentes OpenClaw y necesitaba herramientas de Kubernetes de nivel productivo. El Operator es el resultado de ese trabajo.

Pero también creo que cualquier empresa que ejecute agentes OpenClaw a gran escala acabará en Kubernetes y se enfrentará a los mismos problemas que yo: los valores predeterminados de seguridad, el cableado de NetworkPolicy, el sidecar Chromium, los despliegues de configuración. El ecosistema tiene dos semanas de vida y ya está fragmentado. Cada uno resuelve estos problemas de forma independiente.

El coste de construir software se acerca a cero. Y como argumenté en OpenClaw es el nuevo Linux, la apertura previene la fragmentación. El Operator no es mi ventaja competitiva. Si algo lo es, es la marca y la confianza que construyo compartiendo trabajo como este. Y si ni siquiera eso se mantiene, disfruto construyendo, escribiendo y compartiéndolo. Con eso basta. Mantener el Operator como propietario significaría que cada equipo de infraestructura redescubra los mismos problemas que yo descubrí. Eso es desperdicio, no ventaja competitiva.

Ejecutamos este Operator en producción. Cada agente en OpenClaw.rocks pasa por él.

El código está en github.com/OpenClaw-rocks/k8s-operator. Issues y PRs son bienvenidos.

Si prefiere no gestionarlo usted mismo, para eso está OpenClaw.rocks.