OpenClaw on Kubernetes: The Good, The Bad, and The Stateful
My laptop is powerful, but it isn’t infinite. It sleeps. It travels. It disconnects. My Kubernetes cluster, however, is my 24-hour computational base—a silent, always-on engine in the homelab. When it comes to AI agents, availability is everything. If an agent is going to be a true “sidekick,” it needs to be ready to perform proactive tasks—like a morning digest or LinkedIn automation—while I’m still making coffee.
I recently spent some time moving OpenClaw into this environment. OpenClaw is an ambitious AI agent framework, designed as a highly capable Personal AI assistant. While it is clearly optimized for a local experience, its growth into a 24/7 service on Kubernetes opens up fascinating new use cases. Moving it from a transient laptop session to a permanent cluster home requires some careful technical bridging, but the result is a much more robust “always-on” assistant.
The “How-To”: Deployment on Kubernetes
Integrating a new service into a cluster is a rewarding exercise in infrastructure-as-code. I utilized Kustomize via ArgoCD for this deployment, leveraging the official scripts as a resource base.
1. The Resource Base
Use https://github.com/openclaw/openclaw//scripts/k8s/manifests as your starting point. This provides a
solid foundation. You’ll want to patch the namespace, define your Ingress for external access, and ensure
your PVC is correctly mapped to your cluster’s storage class to ensure persistent state across Pod restarts.
2. Secrets Management
Secrets are cleanly handled via a secretGenerator named openclaw-secrets. At a minimum, you’ll need:
OPENCLAW_GATEWAY_TOKEN: Your root administrator token.<provider>_API_KEY: The API key for your chosen LLM provider (e.g., OpenRouter or Anthropic).
3. The Configuration Layer
To make OpenClaw accessible outside the cluster without relying on kubectl port-forward, you’ll need a custom
configuration file. This bridges the gap between the pod’s internal networking and your ingress:
{
"gateway": {
"bind": "lan",
"auth": { "mode": "token" },
"controlUi": {
"enabled": true,
"allowedOrigins": ["https://your-domain.com"]
}
},
"agents": {
"defaults": {
"model": "openrouter/arcee-ai/trinity-mini:free"
}
}
}
Networking Note: One technical detail I discovered is that OpenClaw’s default mDNS discovery tends to
hang in a Kubernetes environment. This isn’t a fault of the software, but rather a characteristic of most
Kubernetes CNI (Container Network Interface) plugins, which typically drop or filter broadcast packets like
mDNS. Setting gateway.bind to lan helps, but the discovery timeouts can still add latency on startup
as the app searches for a network environment it doesn’t quite see.
4. Slack Integration
Slack remains the most effective interface for a 24/7 assistant. By using Socket Mode, you can avoid exposing a public webhook endpoint, keeping your cluster ingress simple. The official Slack guide is excellent, and I recommend using their provided app manifest to streamline the initial setup.
Pro-tip: You will still need to kubectl exec into the container for the initial user authorization flow.
The Good: Proactive Potential
Once established, the “always-on” nature of the deployment is fantastic. OpenClaw handles Slack Socket Mode gracefully, and having a persistent assistant that can monitor channels or prepare reports overnight is a major productivity boost. It moves the AI from a “chat window” to a background system that works for you.
The Bad: Single-User Context
The biggest challenge isn’t the code quality—which is high—but the architectural assumption of a single-user context. OpenClaw is built with the DNA of a local app. This manifests most clearly in how it handles sessions and agent routing. In a multi-user environment, you start to see that the system isn’t yet designed to route distinct user identities to isolated agent contexts. There is a lot to learn here, especially as the project grows toward more collaborative use cases.
The Stateful: A Context Mismatch
While the reliance on a stateful file system is a challenge for “standard” Kubernetes deployments, the deeper issue is the User Session Context. The app largely assumes it is running on the user’s personal device in the context of their active session. When you decouple it into a 24/7 cluster service, that session-to-identity link becomes a manual bridge you have to build. It’s a classic evolution of a personal tool becoming a shared service.
The CIO Perspective: Growth toward Enterprise Security
As a personal sidekick, OpenClaw is excellent. However, viewing it through a “CIO lens” reveals that multi-user collaboration is still an area of ambitious growth.
The Challenge: How do we transition this from a personal assistant to a team-capable system?
Currently, the ACL and capabilities system is in its early stages. Once a user is authorized (via Slack, for example), the boundary between that user’s intent and the broader system’s tools and API keys is quite thin. To be truly “enterprise-ready,” the system will need more granular identity-based routing—ensuring that User A can use the LinkedIn automation agent without accidentally gaining access to User B’s privileged database tools.
Conclusions
OpenClaw is a fascinating and ambitious project for anyone looking to build a “power user” AI sidekick. Running it on Kubernetes is a great way to ensure it’s always available to handle the proactive tasks that make AI truly useful.
While it is still growing into its multi-user and “service-oriented” shoes, the foundation is strong. I’m excited to continue using it for my morning digests and LinkedIn workflows. For now, it’s a highly capable personal assistant—and I’m looking forward to seeing how it evolves into a truly collaborative team member.