OpenClaw on Knative

Scale-to-zero is straightforward for a stateless endpoint. An interactive gateway adds a more interesting question: what happens to its workspace and configuration when the pod disappears? This project explores that question by running OpenClaw as a Knative Service on a local Kubernetes cluster.

The build combines Knative Serving, Kourier ingress, Kubernetes configuration and secrets, and a persistent volume. It is a local development experiment with recorded startup and scale-down behavior, rather than a public agent-hosting platform.

Preparing the local cluster

The Linux/macOS and PowerShell scripts target Minikube or kind. They install Knative Serving and Kourier at knative-v1.22.0, wait for the control-plane deployments, select Kourier as ingress, and enable the Knative feature flags needed for persistent volumes.

They then configure a local domain, create the agents namespace, store the Gemini API key and gateway password in a Kubernetes Secret, and apply the service manifest. A Kourier port-forward supplies local access. The scripts wait for Knative readiness, but the background port-forward itself receives only a short sleep rather than an explicit connection check.

A request wakes the gateway

Traffic to openclaw.agents.localhost enters through the local Kourier forward and Knative routing. The service manifest sets minimum scale to zero, maximum scale to one, and container concurrency to one. It also sets a five-minute scale-to-zero retention period.

These values make the workload deliberately single-instance. This is an experiment in idle-resource reduction and activation, not horizontal throughput scaling. The README gives a cold-start estimate, but the repository does not provide a benchmark method or measured CI report, so there is no measured latency claim in this case study.

State across scale-to-zero

A 10 GiB ReadWriteOnce claim is mounted at /home/node/.openclaw. The pod can terminate while its workspace survives. That storage choice is part of the reason to examine the one-replica limit: shared persistent state and concurrent replicas would require a different design.

Persisting state also changes recovery behavior. Starting a fresh container does not necessarily mean starting from a clean workspace. Troubleshooting must distinguish an image problem, a configuration problem, and data already present on the volume.

Configuration versus persistence

The README says startup refreshes openclaw.json from the ConfigMap on every boot. The checked manifest behaves differently: it copies the seed configuration only when the file does not already exist on the PVC.

That means runtime edits can survive restarts, and a changed ConfigMap may not replace an existing file. This is an important implementation detail, because an operator could otherwise expect a restart to undo a bad configuration. The article follows the conditional copy in the manifest rather than repeating the stronger README claim.

Operational boundaries

The container configuration drops capabilities, disables service-account token mounting, and uses a runtime-default seccomp profile. At the same time, device-pairing protection is explicitly disabled for local development, and the application image uses the floating latest tag.

The scripts also modify cluster-wide Knative configuration, including the domain map. A disposable local cluster is the appropriate context for that behavior. Before adapting it for shared infrastructure, the next steps would include scoped configuration, restored device protection, an immutable image reference, and a documented policy for refreshing persisted configuration. Those improvements remain future work.

Source files

• Knative manifestAutoscaling, PVC, secrets, configuration copy, and security settings.
• Shell deployment scriptKnative installation and local routing setup.
• PowerShell deployment scriptThe corresponding Windows setup path.
• READMELocal walkthrough, screenshots, and documented assumptions.