OpenClaw on Kubernetes

OpenClaw’s Kubernetes page is a starting point and says so: the core resources for running the Gateway in a cluster, meant to be adapted rather than shipped. It also explains why there is no Helm chart: OpenClaw is a single container with some config files, the interesting customization is agent content, Markdown, skills and config overrides, and Kustomize handles overlays without a chart’s overhead. Here is the quick start, what gets deployed, the probes, the seeding rule that trips people, and what to read next.

A minimal starting point for running OpenClaw on Kubernetes, not a production-ready deployment.

Quick start

• A cluster, managed or local, kubectl connected to it, and an API key for one model provider; export the key and run the deploy script, then port-forward the service to the Gateway port and open it on loopback.
• The script creates a Secret with the provider key and an auto-generated Gateway token, and preserves the existing token and untouched keys on later runs; read the token back from the Secret, or print it with the show-token flag for local debugging.
• No cluster: the Kind script creates one locally on Docker or Podman and tears it down again.

What gets deployed

A namespace, a single-pod Deployment with an init container and the Gateway, a ClusterIP Service on the Gateway port, a ten-gigabyte volume claim for state and config, a ConfigMap holding the config file and the agent instructions, and a Secret with the token and keys. The probes are the careful part: readiness and startup on the ready endpoint with a five-minute startup budget, liveness on the health endpoint, each asserting the JSON probe contract rather than the status code, because the Control UI answers unknown paths with a catch-all 200 and a status-only check would pass forever against an image without the route. The startup endpoint is the better admission probe because it ignores channel health, and needs an image from the 2026.8.1 release or newer.

Customization and the seeding rule

• Edit the agent instructions or the config file in the ConfigMap and redeploy.
• The init container seeds each file only when it is missing from the volume; after first boot the persisted copy is the source of truth, so changes made through onboarding, the channels command, the doctor or the Control UI survive restarts, and a ConfigMap edit does not overwrite them.
• To reseed on purpose, delete the persisted file in the pod and restart the rollout; the previous template applied ConfigMap edits on every start and discarded in-app changes, which is the behaviour this rule replaced.

OpenClaw on Docker is the single-host version of the same container, and The OpenClaw config file explains the file the ConfigMap seeds.

What it is for

Testing OpenClaw in a cluster and a base to adapt: the manifests carry no ingress, no TLS and no multi-tenant story, and the docs’ security and multi-tenant hosting pages are the next reading before anything public. OpenClaw Gateway security controls lists the Gateway settings those pages turn on.

On Diali

Diali runs each assistant as its own isolated workload on Kubernetes, which is the production version the docs say this starting point is not: isolation per assistant, no public ports, outbound access to the public web only, never to our internal network, the cloud metadata server or other tenants, and updates rolled out release by release. Hosted OpenClaw on Diali is the assistant and Security on Diali describes the boundary.

• One script, five resources, a token in a Secret.
• Probes assert the JSON contract, never the status code.
• The volume wins over the ConfigMap after first boot.