OpenClaw Helm Chart: One-Command Kubernetes Deployment

Key Takeaways

Official Helm chart at charts.openclaw.dev — installs OpenClaw on any Kubernetes cluster in one command.

Override defaults with -f values.yaml; never modify the chart source directly.

Pass API keys via existingSecret — never via --set flags to avoid shell history leaks.

Rolling upgrades: 'helm repo update' then 'helm upgrade'; rollback: 'helm rollback openclaw [rev]'.

Works with ArgoCD and Flux for GitOps deployment workflows.

The raw Kubernetes manifests guide shows you every YAML block you'd need. The Helm chart collapses all of that into a single command with sane defaults. If you're deploying OpenClaw to Kubernetes and don't need custom manifest control, start here.

Why Use the Helm Chart

The Helm chart bundles all OpenClaw Kubernetes resources — Deployment, Service, Ingress, ConfigMap, HPA, ServiceAccount — with tested default values and a clean upgrade path. Instead of maintaining a directory of YAML files, you maintain a single values.yaml file.

One-command installs — entire stack deployed and running in under 2 minutes
Versioned upgrades — helm upgrade with rollback if anything goes wrong
GitOps compatible — works natively with ArgoCD and Flux
Tested defaults — resource requests, liveness/readiness probes, and security contexts pre-configured

💡

Create the secret before helm install

Create your OpenClaw secrets Kubernetes Secret before running helm install. The chart references it via existingSecret in values.yaml. If you try to create the secret and install in one step, the ordering can cause failures on first run.

Installation

# Add the OpenClaw Helm repo
helm repo add openclaw https://charts.openclaw.dev
helm repo update

# Create namespace
kubectl create namespace openclaw

# Create secret for API keys FIRST
kubectl create secret generic openclaw-secrets   --from-literal=ANTHROPIC_API_KEY=sk-ant-...   --from-literal=TELEGRAM_BOT_TOKEN=...   -n openclaw

# Install OpenClaw
helm install openclaw openclaw/openclaw   --namespace openclaw   --values values.yaml

values.yaml Configuration

# values.yaml
replicaCount: 2

image:
  repository: openclaw/openclaw
  tag: "1.5.0"
  pullPolicy: IfNotPresent

existingSecret: openclaw-secrets

config:
  logLevel: info
  port: 8080

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 1Gi

ingress:
  enabled: true
  className: nginx
  host: openclaw.your-domain.com
  tls:
    enabled: true
    certManager: true

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

⚠

Pin the image tag — never use 'latest' in production

Using image tag 'latest' means a helm upgrade may silently pull a new major version with breaking changes. Always pin to a specific version tag in values.yaml and consciously upgrade by changing the tag value.

Upgrades & Rollbacks

# Update chart repo
helm repo update

# Upgrade (rolling update, zero downtime with 2+ replicas)
helm upgrade openclaw openclaw/openclaw   --namespace openclaw   --values values.yaml

# View release history
helm history openclaw -n openclaw

# Rollback to previous revision
helm rollback openclaw -n openclaw

# Rollback to specific revision
helm rollback openclaw 3 -n openclaw

With 2+ replicas and a readiness probe configured (the chart enables this by default), upgrades are rolling and zero-downtime. Old pods keep serving traffic until new pods are healthy.

Common Mistakes

Passing API keys via --set flags is the most common security mistake. These values end up in your shell history, your CI/CD logs, and Helm's release metadata (stored as a Kubernetes Secret but visible to anyone with the right RBAC). Always use existingSecret.

Not running 'helm repo update' before upgrade — the local chart cache goes stale. Always update the repo before checking for or applying chart upgrades.
Upgrading without checking the changelog — chart major versions can include breaking values.yaml changes. Check the release notes before upgrading across major versions.
Only one replica with HPA — setting minReplicas: 1 with HPA means scale-down can leave you with a single pod. Use minReplicas: 2 for any production deployment.
Missing Helm diff plugin — before applying upgrades, use the helm-diff plugin to preview what will change. This prevents surprise resource modifications.

Frequently Asked Questions

Where is the official OpenClaw Helm chart?
At charts.openclaw.dev. Add with 'helm repo add openclaw https://charts.openclaw.dev' then 'helm repo update'.

Can I customize the chart without forking?
Yes. Override any default with --set flags or a custom -f values.yaml. Never modify the chart source directly.

How do I pass API keys to the Helm chart?
Use existingSecret to reference a pre-created Kubernetes Secret. Never use --set flags for sensitive values.

How do I upgrade OpenClaw?
Run 'helm repo update' then 'helm upgrade openclaw openclaw/openclaw -n openclaw -f values.yaml'.

Can I use Helm with ArgoCD or Flux?
Yes. Both support Helm chart deployment natively via Application or HelmRelease CRDs.

How do I roll back a failed upgrade?
Run 'helm rollback openclaw [revision] -n openclaw'. Use 'helm history openclaw' to see available revisions.

T. Chen

DevOps Engineer · aiagentsguides.com

T. Chen manages GitOps Kubernetes deployments and covers Helm-based OpenClaw installations at aiagentsguides.com.