How to Deploy OpenClaw on Kubernetes with Helm Charts

You've got a Kubernetes cluster. You want to run OpenClaw on it. Sounds simple, right?

Here's the catch nobody mentions upfront: OpenClaw is a stateful, single-instance application. It maintains persistent WebSocket connections to Telegram, Discord, and other messaging platforms. You can't just scale it horizontally like a typical web service. Two pods running at the same time? You get duplicate bot messages and broken state. That's why every serious Helm chart uses a Recreate deployment strategy instead of RollingUpdate.

If that doesn't scare you off, keep reading. There are actually good reasons to run OpenClaw on Kubernetes, and probably three solid Helm chart options to get you there.

Which Helm Chart Should You Pick?

The community has built several charts, but these are the ones worth your time:

serhanekicii/openclaw-helm (v1.4.4, app v2026.3.2) is the most production-hardened option. It runs containers as non-root (UID 1000), enforces read-only root filesystems, drops all Linux capabilities, and ships with a default-deny NetworkPolicy that only allows DNS and HTTPS egress. Built on the bjw-s app-template. If you're deploying OpenClaw for anything serious, start here.

Chrisbattarbee/openclaw-helm (app v2026.2.23) keeps things simpler. One command to install. Good for getting started or testing.

openclaw-rocks/k8s-operator takes a different approach entirely. Instead of a Helm chart, it's a Kubernetes Operator that replaces 11 separate resources with a single OpenClawInstance custom resource. If you're running multiple OpenClaw instances (multi-tenant), this is probably where you want to end up.

Quick Start with the serhanekicii Chart

helm repo add openclaw https://serhanekicii.github.io/openclaw-helm
helm repo update
kubectl create namespace openclaw
kubectl create secret generic openclaw-env-secret -n openclaw \
  --from-literal=ANTHROPIC_API_KEY=sk-ant-xxx \
  --from-literal=OPENCLAW_GATEWAY_TOKEN=your-token
helm install openclaw openclaw/openclaw -n openclaw -f values.yaml

That's the basic install. Your values.yaml should at minimum specify resource limits (the chart defaults to 200m CPU / 512Mi RAM requests, with limits at 2000m / 2Gi) and Ingress configuration with proper WebSocket timeouts:

ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

Without those timeout annotations, NGINX will kill your WebSocket connections after 60 seconds. I've seen people debug this for hours.

The configMode Gotcha

One thing that surprised Daniel Hnyk and several other practitioners: the default configMode: merge behavior means Helm values get deep-merged with whatever config exists on the PersistentVolume. Settings you change through the OpenClaw UI survive pod restarts. But if your Helm values conflict with UI changes, Helm wins.

The practical recommendation? Use Helm for infrastructure settings (resource limits, Ingress, networking). Manage your agent configuration, model settings, and channel tokens through the UI.

Security Defaults That Actually Matter

The Clawkeeper security scanner found that 93.4% of exposed OpenClaw instances had authentication bypass conditions. That's a real number. Kubernetes helps here because proper Helm charts enforce sensible defaults:

• Non-root containers (UID 1000)

• Read-only root filesystem

• All Linux capabilities dropped, privilege escalation disabled

• Seccomp RuntimeDefault profile

• NetworkPolicy restricting egress to DNS and HTTPS only

You still need to handle Secrets properly. For production, look at External Secrets Operator or Sealed Secrets rather than storing API keys in plaintext.

What This Actually Costs

Here's where it gets honest. Running OpenClaw on Kubernetes isn't free, and the infrastructure costs add up:

Those cloud costs are infrastructure only, based on data from the OpenClaw Directory. LLM API costs come on top.

When Kubernetes Makes Sense (and When It Doesn't)

Kubernetes is the right call if you already have a cluster running, need multi-tenant isolation for separate OpenClaw instances, are building a hosting platform, want GitOps for agent configuration, or need deep integration with in-cluster services like local LLMs or vector databases.

It's probably overkill if you're running a single instance, have a small team of one to four people, don't already have a cluster, have a budget under $50 per month, or don't have dedicated DevOps capacity. For those cases, a managed service like ClawHosters or even a simple VPS with Docker Compose will get you running faster and cheaper.

As the Metoro engineering team noted, one real advantage of Kubernetes is that "everything is already on the same network," which simplifies integration with monitoring tools, local LLMs, and other services. But that advantage only matters if you have those services running already.

For a deeper look at self-hosting versus managed options, we've written a separate comparison. And if you're concerned about costs, our guide on OpenClaw token cost optimization covers the LLM API side of the equation.