Running OpenClaw on Kubernetes

How to deploy, monitor and maintain OpenClaw on Kubernetes

By Chris Battarbee
Published:
4 min read

Like the rest of the world, I've been experimenting with OpenClaw over the weekend. Initially I had a fresh linux install on an old laptop with OpenClaw installed but as my workflows and integrations grew, things started to become a little unwieldy.

I wanted to manage OpenClaw declaratively, take snapshots of state periodically and monitor exactly what it was doing. My home lab Kubernetes cluster seemed like a good fit for this.

I couldn't see any other helm charts so I decided to build my own at chrisbattarbee/openclaw-helm.

Installation

The Helm chart makes deployment straightforward. Three commands get you running:

helm repo add openclaw https://chrisbattarbee.github.io/openclaw-helm
helm repo update
helm install openclaw openclaw/openclaw --set credentials.anthropicApiKey=sk-ant-xxx

You can set various configurations declaratively by overriding the values in values.yaml.

Once helm has deployed OpenClaw, it will give you a command to shell into the pod and run the onboarding workflow which will look something like this:

kubectl exec -it --namespace default deploy/openclaw -c openclaw -- node dist/index.js onboard

After you run through onboarding, you're off to the races.

My personal workflow is to add integrations, skills etc as I normally would, then inspect the openclaw.json file and extract out the config and set it declaratively in the helm chart. This way I can recreate the exact same environment in the future without losing the flexibility of installing integrations and skills on the fly as I go.

Monitoring

My main requirement with monitoring OpenClaw is to understand what APIs and endpoints it's calling and how often. OpenClaw is essentially allowed to do pretty much anything it wants so seeing exactly what it did is important to me to ensure I can catch rogue actions.

One problem we have is that OpenClaw itself doesn't have native telemetry capabilities right now and even if it did, it's able to call other programs and APIs that may not be instrumented.

I'll be using Metoro to monitor OpenClaw as the instrumentation is done at the kernel level with eBPF. This means that we can see exactly what OpenClaw is doing without needing to do any instrumentation of OpenClaw or the programs it calls.

I have OpenClaw do a number of different tasks including:

  • Checking emails
  • Getting todos from notion
  • Checking the weather

We can see the network calls in Metoro even though OpenClaw is calling them via running a curl command.

Metoro service map showing OpenClaw making HTTP requests to external services including wttr.in, discord.com, gmail.com, and api.notion.com
Service map showing OpenClaw's external API calls

The service map shows OpenClaw reaching out to various external services. We can drill down into individual requests to see exactly what's happening.

Metoro trace search showing OpenClaw requests to wttr.in with timestamps, status codes, and latencies
Trace search showing requests to the weather API

Clicking into a specific trace shows the full span attributes including container ID, namespace, and the exact URL being called.

Metoro trace detail view showing span attributes for an OpenClaw request to wttr.in including container ID, namespace, and HTTP details
Trace detail with full request attributes

Based on the traces I then set up an alert to tell me if OpenClaw ever makes a request to something that is not in this list of expected APIs.

What's Next

Next on my list is setting up VolumeSnapshots to periodically backup OpenClaw's state. Scheduled snapshots would let me restore to a known good state if something goes wrong.

I'm also planning to experiment with giving OpenClaw access to other services in the cluster. Perhaps a local LLM for less sensitive tasks or a vector database for longer-term memory. Running it on Kubernetes makes this kind of integration much easier since everything is already on the same network.