Paperclip.inc
Start hiring

Run OpenClaw on Kubernetes with a Helm operator

Self-host OpenClaw AI agents on Kubernetes with our open-source operator. One Helm install, one custom resource, a hardened self-healing stack.

By Paperclip Team 7 min read

You can self-host an OpenClaw AI agent on Kubernetes in minutes: one Helm install, one short YAML file, and the rest is handled for you. The tool that does it is the OpenClaw Kubernetes operator, and it is open source under Apache 2.0. The code is public, the chart is public, and it is published in the catalogs Kubernetes teams already trust: ArtifactHub and OperatorHub.

Paperclip.inc runs OpenClaw as a fully managed, EU-sovereign service. This is the other half of that promise: the same operator we run in production, given to you to run yourself, in the open.

Why an operator, not just a Deployment

OpenClaw is an AI agent that acts on your behalf across Telegram, Discord, WhatsApp, and Signal. It handles your inbox, calendar, smart home, and more. Running one in production takes more than a container. You need network isolation, secret handling, persistent storage, health checks, safe config rollouts, and a way to keep it all in sync. Wiring that by hand is where most self-hosting projects stall.

The operator turns all of it into one resource you can read at a glance. You describe what you want, and the operator builds and maintains the rest:

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent
spec:
  envFrom:
    - secretRef:
        name: openclaw-api-keys
  storage:
    persistence:
      enabled: true
      size: 10Gi

Apply that, and it reconciles into a full stack: a StatefulSet, Service, RBAC, a default-deny NetworkPolicy, a PersistentVolumeClaim, a PodDisruptionBudget, a ConfigMap, and a per-instance gateway token. Then it keeps that stack healthy, with health probes, drift detection, and automatic rollouts.

Install it with Helm

You need Kubernetes 1.28 or newer and Helm 3. The chart ships as an OCI artifact, so there is no repo to add:

Terminal window
helm install openclaw-operator \
  oci://ghcr.io/paperclipinc/charts/openclaw-operator \
  --namespace openclaw-operator-system \
  --create-namespace

Prefer OLM? Because the operator is in the OperatorHub community-operators catalog, it installs like any other catalog operator:

Terminal window
kubectl create -f https://operatorhub.io/install/openclaw-operator.yaml

Deploy your first agent

Create a Secret with your provider key, then a single OpenClawInstance. The operator is provider-agnostic, so point it at Anthropic, OpenAI, or any other provider through environment variables:

Terminal window
kubectl create secret generic openclaw-api-keys \
  --from-literal=ANTHROPIC_API_KEY=sk-ant-...


kubectl apply -f openclawinstance.yaml

Then check it is up:

Terminal window
kubectl get openclawinstances
# NAME       PHASE     AGE
# my-agent   Running   2m

That is the whole loop: one Secret, one resource, a running agent with storage behind it.

Secure by default

An AI agent reads your messages and acts on your behalf, so the blast radius matters. Security here is not a checklist you work through later. It is the starting state, and you would have to opt out of it.

  • Locked-down pods. Every instance runs non-root (UID 1000) with a read-only root filesystem, all Linux capabilities dropped, and the seccomp RuntimeDefault profile.
  • Network isolation. Each instance gets its own default-deny NetworkPolicy, so an agent can only reach what you explicitly allow.
  • Least-privilege access. Scoped RBAC per instance, a per-instance gateway-token Secret instead of shared credentials, and the option to restrict the operator itself to named namespaces.
  • Admission control. A validating webhook rejects bad or unsafe specs before they ever reach the cluster, and reserved internal fields cannot be overridden.
  • Guarded self-modification. Agents can adapt their own setup (install a skill, patch config) through the Kubernetes API, but every request is checked against an allowlist policy. Protected keys cannot be overwritten, and denied requests are logged with a reason.

Browser automation, built in

OpenClaw agents are most useful when they can actually use the web, so the operator makes that a one-line opt-in. Enable the Chromium sidecar and the agent gets a headless browser for web scraping, screenshots, and browser-based integrations:

spec:
  chromium:
    enabled: true

The operator wires it up end to end: it injects the browser endpoint into the agent, points the OpenClaw browser profiles at it so tool calls work out of the box, and sets the right shared memory, security context, and health probes. Turn on persistent profiles and cookies, sessions, and logins survive pod restarts, which is what makes authenticated and MFA-protected automation practical. Those profiles hold real session tokens, so the volume carries the same security posture as your other instance storage; use a StorageClass with encryption at rest for sensitive work.

For operations there is a second, separate browser surface: an optional web terminal (a ttyd sidecar) gives you shell access to a running instance from your browser, no kubectl exec needed, with basic auth and a read-only mode for production.

Built for production

  • Observable out of the box. Prometheus metrics, ServiceMonitor integration, structured JSON logs, and Kubernetes events for every reconcile.
  • GitOps-friendly. It uses Server-Side Apply, so it sits cleanly alongside Flux and Argo CD. Commit your manifests and let your pipeline own them.
  • Operationally complete. S3-backed backup and restore, opt-in auto-update with health-checked rollback, autoscaling, and scale-to-zero suspension.

Open source, and built to stay that way

We did not open-source this as a favor. We did it because it is what we believe.

What powers your work should be open. You should be able to see exactly how the thing running your agents behaves, change it if you need to, and take it with you if you ever want to leave. An operator you can read and fork is the opposite of lock-in. That is the same principle behind running everything in Europe: your work should answer to you and to one clear set of rules, not to a black box you cannot inspect.

So the operator is Apache 2.0, developed in the open, and listed on ArtifactHub and OperatorHub so anyone can find and install it without going through us. The generic improvements we make go back upstream. If you self-host and hit a rough edge, open an issue or send a pull request: the project is better when the people running it in the real world shape it.

Managed or self-hosted, your call

Both paths run the same operator, so the choice is about who keeps it running, not about giving anything up.

Run it yourself and you own the cluster, the upgrades, and the on-call. Let Paperclip.inc run it and you get the same agents fully managed and EU-sovereign, watched day and night, backed up daily, for a fixed monthly price. You can start on one and move to the other, because underneath it is the same open code.

Common questions

Is it really open source? Yes. Apache 2.0, full source on GitHub, the Helm chart and OLM bundle published publicly. No open-core bait, no paid tier hiding the parts that matter.

Is it production-ready? Yes. It is the operator we run our own managed service on, hardened by default and published in the OperatorHub community-operators catalog.

Why is the API group openclaw.rocks when the repo is under paperclipinc? That group is a stable API identifier, not a typo. Renaming it would break every deployed resource, so it stays as-is. Use openclaw.rocks/v1alpha1 in your manifests.

Get started

Self-hosting your AI agents on Kubernetes should take minutes, in the open, with no lock-in. Now it does.

Related