ClawHosters
by Daniel Samer
6 min read
If you already run a Kubernetes cluster, deploying an AI agent via Helm makes sense. Your infrastructure team knows the tooling, you've got monitoring in place, and one more workload probably won't break the bank.
But if you're thinking about spinning up K8s just for OpenClaw, read the cost section at the bottom first.
This guide covers both community openclaw helm chart options, the install commands you'll actually run, and the gotchas nobody mentions until you hit them at 2 AM.
Which OpenClaw Helm Chart Should You Use?
There's no official OpenClaw Helm chart from the project itself. Two community-maintained charts fill that gap, and they take different approaches.
Chrisbattarbee/openclaw-helm is the simpler option. Three commands and you're running. It tracks the latest OpenClaw image (2026.3.2 as of this writing) and gives you a straightforward values file without too many opinions baked in.
serhanekicii/openclaw-helm builds on the bjw-s app-template. It ships with stricter security defaults, network policies, and a more opinionated structure. If your cluster already uses Calico or Cilium for network policy enforcement, this chart plugs in nicely.
Which one should you pick? Probably Chrisbattarbee's if you want the fastest path to a running instance. Serhanekicii's if your security team has opinions about pod-level network isolation.
Install the OpenClaw Helm Chart
Here's the actual openclaw kubernetes deployment using the Chrisbattarbee chart:
helm repo add openclaw https://chrisbattarbee.github.io/openclaw-helm
helm repo update
helm install openclaw openclaw/openclaw
That's it. Three commands. OpenClaw spins up with default settings on your cluster.
For a custom values file (which you'll want in production):
helm install openclaw openclaw/openclaw -f my-values.yaml
OpenClaw Helm Chart Values Configuration
The values.yaml file is where the real decisions happen. Here's what matters for your openclaw helm values configuration:
Resource Requests and Limits
resources:
requests:
cpu: 100m
memory: 512Mi
limits:
cpu: 2000m
memory: 2Gi
OpenClaw's memory usage depends heavily on your tool configuration and conversation history size. I'd start with 512Mi and watch your metrics. Some setups chew through 1.5Gi regularly.
Persistent Storage
persistence:
enabled: true
size: 10Gi
accessModes:
- ReadWriteOnce
This is where your agent configs, conversation logs, and SQLite database live. The ReadWriteOnce access mode is important. It means only one pod can mount this volume. That matters for the next section.
Config Mode
configMode: merge
Two options here. merge keeps UI-made changes during Helm upgrades. overwrite replaces everything with what's in your values file. For teams that manage config through GitOps, overwrite is cleaner. For everyone else, merge avoids surprises.
Three Gotchas You'll Hit
After running OpenClaw on K8s for a while, and from what we've seen users report on our self-hosted vs managed comparison, these are the problems that catch people off guard.
The configMode merge trap. You set configMode: merge, configure your agent through the UI, then run helm upgrade with slightly different values. Your UI config gets partially overwritten. The merge isn't a deep merge. If you define a key in values.yaml that also exists in the UI config, the Helm value wins. Keep track of which settings live where, or commit to managing everything through one path.
No horizontal scaling. OpenClaw uses SQLite and local file storage. The PVC has ReadWriteOnce access. The deployment strategy is Recreate, not RollingUpdate. You can't run two replicas. This is a single-instance application. If you need to handle more load, you need to deploy separate OpenClaw instances for different agents, not scale pods horizontally.
Upgrades cause downtime. Because the strategy is Recreate (the old pod stops before the new one starts), every Helm upgrade means 30 to 90 seconds of downtime. For an internal team tool, that's probably fine. For a customer-facing agent, plan your upgrade windows.
Security Checklist
If you're going to run a self-hosted AI agent on Kubernetes, at minimum:
Store your LLM API keys in Kubernetes Secrets, not ConfigMaps. But know that K8s Secrets are base64-encoded, not encrypted at rest (unless you've configured encryption at the API server level). As Daniel Hnyk explains in his self-hosting guide, this catches a lot of people by surprise.
Enable network policies if your CNI supports them. The serhanekicii chart includes these by default.
Restrict tool allowlists for your agent. An AI agent with unrestricted shell access on your cluster is... not ideal. Check our security hardening guide for the full checklist.
Is Kubernetes the Right Choice for You?
Honest answer? It depends on whether you already have a cluster.
Running OpenClaw on an existing K8s cluster adds maybe $5 to $20/month in resource costs, plus a few hours of initial setup. Totally reasonable if you've already invested in the infrastructure.
Setting up a new Kubernetes cluster just for OpenClaw? That's a different story. You're looking at $50 to $200/month for the cluster itself, 8 to 20 hours of initial setup (more if you're learning K8s simultaneously), and 2 to 4 hours of monthly maintenance for upgrades, certificate rotation, and debugging whatever broke this time.
Compare that with managed hosting on ClawHosters, where setup takes about 60 seconds and costs start at $19/month. No cluster management, no YAML debugging sessions, automatic updates.
For teams already on Kubernetes, the OpenClaw Helm chart is a solid option. For everyone else, the math probably favors managed.
