OpenClaw Control Plane on Kubernetes: installation, architecture and topologies

Introduction

Running an Artificial Intelligence agent on Kubernetes is relatively simple. A Deployment, a Service, a few credentials and persistent storage may be enough for a first lab.

The problem starts when an organization moves from one agent to dozens or hundreds of them.

At that point, questions come up that Kubernetes alone doesn't answer:

• who can create and manage each agent;
• which configuration belongs to each tenant;
• which model credential the agent may use;
• how to keep an immutable revision history;
• how to separate the gateway from the execution environment;
• how to reconcile configuration changes;
• how to prevent access between agents;
• how to store workspace and state;
• how to control the lifecycle of a revision;
• how to audit changes;
• how to provision all this infrastructure reproducibly.

OpenClaw Enterprise, through the OpenClaw Control Plane (OCC), adds exactly this control layer. The OCC keeps the desired state of Namespaces, Agents, Configurations, Secrets and AgentRevisions, while Drivers translate that state into concrete infrastructure resources.

The architecture is conceptually similar to a Kubernetes Operator:

Desired state
      ↓
Controller
      ↓
Reconciliation Loop
      ↓
Infrastructure
      ↓
Observed state

But there is an important distinction.

In the official OCC, Agent, AgentRevision, Configuration and the other platform objects are not Kubernetes Custom Resource Definitions (CRDs). These resources belong to the OpenClaw API and are persisted in PostgreSQL. The OCC worker reconciles that state through Drivers, mainly the KubernetesComputeDriver.

This avoids a common mistake when studying the architecture: imagining that the OCC works internally like:

apiVersion: openclaw.io/v1
kind: Agent

That is not the official Control Plane's model.

The CRDs directly relevant to the official Kubernetes path are mainly those of the Kubernetes Gateway API, used for resources such as Gateway and HTTPRoute. The cluster also needs Envoy Gateway and cert-manager for the recommended private routing topology.

What is the OpenClaw Control Plane

The OpenClaw Control Plane, or OCC, is the component responsible for managing the state of an OpenClaw Enterprise installation. It acts as the control layer between:

User / automation
        ↓
OpenClaw API
        ↓
IAM + PostgreSQL
        ↓
Controller Worker
        ↓
Drivers
        ↓
Kubernetes / runtime

The OCC controls the desired state, while Drivers perform the concrete operations needed to turn that state into workloads.

The official architecture has at least four central elements:

API
PostgreSQL
Controller Worker
Drivers

• the API receives administrative operations and handles authentication and authorization;
• PostgreSQL holds resources, IAM policies, the work queue and audit evidence;
• the Controller Worker processes pending operations;
• the Drivers translate those operations to external systems such as Kubernetes.

Key concepts

Installation

An installation represents one instance of OpenClaw Enterprise. The current architecture works with one Installation selected by the server per deployment. Inside it live the tenants, represented by the platform's Namespaces.

OpenClaw Namespace

Not to be confused directly with a Kubernetes Namespace. An OpenClaw Namespace represents a logical tenant boundary.

When the Kubernetes Compute Driver is used, that boundary may result in more than one physical Namespace in the cluster. In the dedicated topology we have, for example:

OpenClaw Namespace
│
├── Kubernetes data-plane namespace
│
│     └── Harness
│
└── Kubernetes gateway namespace
      └── Gateway

The Compute Driver creates isolation policies, quotas and specific resources in each destination.

Agent

Represents an agent managed by the Control Plane. Creating an Agent records its definition, but that doesn't mean a Kubernetes workload is ready. Deploying creates a revision that must be reconciled.

AgentRevision

An AgentRevision is an immutable snapshot of the configuration admitted for a given deployment. The flow looks like this:

Agent
  ↓
Configuration
  ↓
Deploy
  ↓
AgentRevision #1
  ↓
change
  ↓
AgentRevision #2

Editing the Agent's draft does not automatically modify the revision that is already running. This separation matters for traceability, auditing and operational rollback.

Configuration

Holds the configuration used by the Agent. When a revision is admitted, the corresponding configuration is frozen along with other important runtime decisions.

Controller Worker

The Worker performs the reconciliation itself. It runs separately from the HTTP API and polls durable work stored in PostgreSQL. Its responsibilities include:

provision Namespace
prepare AgentRevision
check readiness
activate revision
stop Agent
remove Agent
retire previous revision

Before performing any infrastructure effect, the Worker revalidates authorization and ownership of the resources involved.

Is the OCC a Kubernetes Operator?

Conceptually, the behavior is similar: desired state, reconciliation, observed state. However, the OCC does not use the platform's main objects as CRDs.

Instead of:

kubectl apply Agent
        ↓
Kubernetes API
        ↓
Operator

the official flow is:

OCC API
   ↓
PostgreSQL
   ↓
durable work queue
   ↓
Controller Worker
   ↓
ComputeDriver
   ↓
Kubernetes API

This difference is architecturally relevant. Kubernetes is the data plane and runtime provider, but not the Control Plane's primary source of truth.

What about CRDs?

In the official installation, the main set of CRDs that must exist beforehand comes from the Gateway API. OpenClaw uses resources such as Gateway and HTTPRoute to maintain private routes to the Agents' gateways.

The documentation requires, before installing the OCC:

Gateway API CRDs
Envoy Gateway
GatewayClass
cert-manager

The OCC Helm chart does not install these controllers automatically. When private gateway routing is enabled, the Kubernetes Compute Driver reconciles an HTTPRoute owned by the Agent and attaches it to the configured Gateway.

CRD-based OpenClaw operators

There is also a different approach, maintained outside the Enterprise Control Plane: Kubernetes operators that represent an OpenClaw instance through CRDs. One example uses kind: OpenClawInstance and reconciles it into a StatefulSet, Service, RBAC, NetworkPolicy, PVC, PDB and other Kubernetes objects.

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: support-agent
  namespace: openclaw-agents
spec:
  envFrom:
    - secretRef:
        name: openclaw-api-keys

  storage:
    persistence:
      enabled: true
      size: 10Gi

In this model:

OpenClawInstance CR
        ↓
Kubernetes Operator
        ↓
StatefulSet
Service
PVC
NetworkPolicy
RBAC
...

This approach is valid for those who want to manage OpenClaw instances directly through Kubernetes, but it should not be confused with the internal architecture of the OpenClaw Enterprise Control Plane. So there are two models:

For enterprise environments that need their own IAM, AgentRevision, auditing, tenant lifecycle and Drivers, the OCC offers a broader control layer.

Official Control Plane architecture

                 Users / Automation
                         │
                         ▼
                ┌─────────────────┐
                │    OCC API      │
                │ Console + Auth  │
                └────────┬────────┘
                         │
                 Authorization
                         │
                         ▼
                ┌─────────────────┐
                │       IAM       │
                └─────────────────┘

                         │
                         ▼

                ┌─────────────────┐
                │   PostgreSQL    │
                │                 │
                │ resources       │
                │ revisions       │
                │ work queue      │
                │ audit           │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Controller      │
                │ Worker          │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Compute Driver  │
                │ Kubernetes      │
                └────────┬────────┘
                         │
             ┌───────────┴──────────┐
             ▼                      ▼
       Agent Gateway             Harness

This split matters because HTTP requests don't need to stay open waiting for Kubernetes to finish the whole operation. The API records the intent; the Worker converges the environment afterwards.

Reconciliation flow

Imagine a deploy:

POST deploy Agent
       ↓
OCC authorizes
       ↓
creates AgentRevision
       ↓
writes work to PostgreSQL
       ↓
Worker claims work
       ↓
Worker reauthorizes the operation
       ↓
ComputeDriver.prepareRevision()
       ↓
Kubernetes resources
       ↓
readiness
       ↓
activateRevision()
       ↓
retires predecessor

The OCC uses durable work in PostgreSQL, including mechanisms to recover abandoned claims or interrupted workers.

Kubernetes prerequisites

For the current production installation, the documentation requires Kubernetes 1.35 or later, IPv4 connectivity and a CNI that actually enforces NetworkPolicy. In addition:

Kubernetes >= 1.35
Helm
kubectl
Envoy Gateway
Gateway API CRDs
GatewayClass
cert-manager
External PostgreSQL
Container Registry
RWO StorageClass

PostgreSQL must use verified TLS and separate roles for application and migration. The Control Plane should not receive administrative database credentials during normal operation.

Node pools

The documentation recommends separating the nodes meant for the Control Plane from the nodes used by Agents. One convention presented is oce-role=control and oce-role=agents:

Kubernetes Cluster
│
├── Control Plane Node Pool
│    label: oce-role=control
│
│    ├── OCC API
│    ├── Worker
│    └── control components
│
└── Agent Node Pool
     label: oce-role=agents

     ├── Agent Harness
     ├── Embedded OpenClaw
     └── runtimes

Separating only Namespaces is not the same as node isolation. The architecture itself recommends distinct pools for trusted gateways and less trusted Harnesses in production.

Storage

There are three important categories.

Gateway storage must be suitable for SQLite, including locking and fsync. NFS and SMB/CIFS are not recommended for this database, since SQLite WAL depends on semantics that shared network filesystems may not provide adequately.

Installing the Control Plane

The production installation uses Helm. The documentation's conventional namespace is openclaw-system. Start by checking the cluster:

kubectl version

kubectl get nodes -L oce-role

kubectl get storageclasses

Also validate the Gateway API and cert-manager:

kubectl get gatewayclass

kubectl api-resources | grep -E 'Gateway|HTTPRoute'

kubectl get pods -n cert-manager

Control Plane namespace

apiVersion: v1
kind: Namespace
metadata:
  name: openclaw-system
  labels:
    app.kubernetes.io/part-of: openclaw-enterprise

kubectl apply -f namespace.yaml

The namespace holds the installation's core components. In production, avoid mixing user workloads in this namespace.

Kubernetes Compute Driver configuration

installation.yaml selects and configures the Drivers. A representative Compute Driver fragment follows the documented format:

drivers:
  compute:
    id: compute-kubernetes

    configuration:
      authentication:
        mode: inCluster

      images:
        gateway: registry.example.com/openclaw/runtime@sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        agent: registry.example.com/openclaw/runtime@sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
        requireImmutableDigest: true

      resources:
        gateway:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: "4"
            memory: 256Mi

        agent:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: "4"
            memory: 256Mi

        namespace:
          quota:
            pods: "10"

      network:
        dns:
          namespace: kube-system
          podLabels:
            k8s-app: kube-dns

        gatewayPort: 8080

        gatewayTrustedProxyCidrs:
          - "10.20.0.0/24"

      servicePrincipalCredentials:
        mode: projectedServiceAccountToken
        audience: openclaw-enterprise
        expirationSeconds: 900

      runtime:
        gatewayStorageClassName: premium-rwo

        nodeSelector:
          oce-role: agents

        gatewayNodeSelector:
          oce-role: control

The example above must be adapted to your environment. The critical points are:

• `requireImmutableDigest`: in production, images must be referenced by digest (@sha256:...) rather than :latest. The official configuration requires immutable images on the production path;
• `nodeSelector`: determines where Harnesses and runtimes run;
• `gatewayNodeSelector`: keeps Gateways on different nodes from the executing workloads;
• `projectedServiceAccountToken`: uses ServiceAccount tokens with a defined audience and short lifetime.

Helm installation

After generating or preparing values.yaml and installation.yaml, the official procedure uses a Secret containing the startup configuration:

kubectl -n openclaw-system \
  create secret generic occ-installation-startup \
  --from-file=installation.yaml=installation.yaml

Separate Secrets are also created for the database, authentication and other credentials. The installation then follows the model:

helm upgrade --install oce \
  ./deploy/helm/openclaw-enterprise \
  --namespace openclaw-system \
  -f values.yaml \
  --wait \
  --timeout 5m

Published chart releases can also be consumed from the official OCI registry.

An important operational point: Helm Ready does not necessarily mean a working OCC. You need to validate API authentication and then run a real model call through an Agent.

Topology 1 — Embedded OpenClaw

In the embedded topology, Gateway and Harness live together in the same Pod:

                 OCC
                  │
                  ▼
          Kubernetes Compute
                  │
                  ▼
        Tenant Kubernetes NS
                  │
                  ▼
        ┌──────────────────┐
        │ OpenClaw Pod     │
        │                  │
        │ Gateway          │
        │ +                │
        │ Harness          │
        └──────────────────┘

Advantages: fewer resources, simpler architecture, less Pod-to-Pod communication, lower storage consumption and a good entry point.

Drawbacks: less blast-radius separation; gateway and workload share a runtime; less suitable for more sensitive or potentially risky execution.

Topology 2 — Dedicated Gateway and Harness

              OCC Control Plane
                      │
                      ▼
                Compute Driver
                      │
        ┌─────────────┴─────────────┐
        ▼                           ▼

Gateway Namespace              Data Namespace

┌──────────────┐               ┌──────────────┐
│ Gateway Pod  │◄─────────────►│ Harness Pod  │
│              │               │              │
│ identity     │               │ workspace    │
│ state        │               │ model key    │
└──────────────┘               └──────────────┘

Gateway and Harness have separate ServiceAccounts, storage, namespaces and identities. The model credential is delivered only to the component that actually needs to run inference; a dedicated Gateway does not receive the model credential. This is an important improvement from a security standpoint.

Topology 3 — Separate node pools

For production, we can add physical scheduling isolation:

Cluster
│
├── trusted-pool
│    oce-role=control
│
│    ├── OCC API
│    ├── Worker
│    └── Gateways
│
└── agent-pool
     oce-role=agents

     ├── Harness A
     ├── Harness B
     ├── Harness C
     └── Embedded workloads

This reduces the risk of an Agent workload competing directly with the Control Plane. It is especially important when Agents have command-execution or code-manipulation tools.

Topology 4 — Two clusters

The Kubernetes Compute Driver has an experimental setting that lets you point execution at a different Kubernetes API. The conceptual design would be:

Cluster A
Control Plane
│
├── OCC
├── PostgreSQL access
├── Worker
└── Gateways
       │
       │
       ▼
Cluster B
Execution
│
├── Agent Harness
├── workspaces
└── runtime

This architecture is attractive for strong isolation. However, current two-cluster support is explicitly treated as experimental, and the documentation indicates that full runtime acceptance is still pending. It should therefore not be presented as a standard production topology.

A day-to-day example

Consider a company with five squads: Payments, Customer Experience, Security, Platform and Data. Each team starts building internal agents.

Without a Control Plane, the environment quickly turns into:

deployment-agent-a.yaml
deployment-agent-b.yaml
secret-agent-a.yaml
secret-agent-b.yaml
config-agent-v3-final-final.yaml

Each team manually manages Secrets, PVCs, Ingress, NetworkPolicy, ServiceAccounts, model keys and deployments. There is no central view of revisions.

With the OCC

Installation
│
├── Namespace Payments
│     ├── Agent fraud-review
│     └── Agent chargeback
│
├── Namespace Platform
│     ├── Agent incident-triage
│     └── Agent deployment-review
│
└── Namespace Data
      └── Agent sql-review

The flow becomes:

Developer
   ↓
OCC API
   ↓
Authorization
   ↓
AgentRevision
   ↓
Worker
   ↓
Kubernetes Compute Driver
   ↓
runtime

The result is a declarative, auditable model that doesn't force every application team to know the full Kubernetes implementation.

Production environment

An architecture closer to production would be:

                       ┌────────────────────┐
                       │ Internal LB /      │
                       │ trusted ingress    │
                       └─────────┬──────────┘
                                 │
                                 ▼
                       ┌────────────────────┐
                       │ OCC API            │
                       └─────────┬──────────┘
                                 │
                   ┌─────────────┴─────────────┐
                   ▼                           ▼
              PostgreSQL                    Worker
                                                │
                                                ▼
                                         Compute Driver
                                                │
                           ┌────────────────────┼─────────────┐
                           ▼                    ▼             ▼
                     Gateway NS          Tenant NS      Tenant NS
                           │                    │             │
                        Gateway             Harness       Harness
                           │                    │             │
                           └──────── Envoy Gateway ───────────┘

External components: cert-manager, Gateway API, Envoy Gateway, Prometheus, log collector, container registry, managed PostgreSQL and persistent block storage.

NetworkPolicy and isolation

The Kubernetes Compute Driver architecture starts tenants with default-deny for ingress and egress, and adds only explicitly required flows. Accesses blocked by default include:

cross-tenant
Agent → another Agent
Kubernetes API
cloud metadata

Specific policies allow DNS, Gateway/Harness and the necessary destinations.

A relevant point is that creating a NetworkPolicy object does not prove isolation. The CNI must actually implement it. On EKS, GKE or your own cluster, always validate with real tests (kubectl exec, curl, nc) to check both allowed and blocked connections.

Pod security

Workloads generated by the Compute Driver use practices such as:

runAsNonRoot
RuntimeDefault seccomp
drop capabilities
allowPrivilegeEscalation=false
readOnlyRootFilesystem

and ServiceAccount-based identity with a short-lived projected token. The goal is to keep the Agent's runtime from inheriting the controller's privileges.

RBAC

The principle should be:

OCC API
≠
Worker
≠
Gateway
≠
Harness

Each component has different responsibilities. The Worker needs to create and modify certain resources inside the managed namespaces. The Agent must not receive the Worker's credentials.

The documentation explicitly warns against wildcard permissions, cluster-wide tenant access, RoleBinding escalation and controller credentials inside workloads.

Secrets

Another essential principle is to separate controller credentials, database credentials, gateway credentials, model credentials and Agent credentials. Don't use a single Secret containing all of the platform's credentials.

In the dedicated model:

Gateway
    X
    │ does not receive the model API key
    │
Harness
    │
    └── model credential

This reduces the impact of exposing any single component.

Observability

The OCC has private metrics for the API and Worker. By default, the Helm chart can expose these metrics on the Pod IP through port 9464. Scrape access uses Namespace and Pod selectors:

metrics:
  enabled: true
  port: 9464

  scraperNamespaceLabels:
    kubernetes.io/metadata.name: monitoring

  scraperPodLabels:
    app: prometheus

The chart does not automatically create a ServiceMonitor, a metrics Service or a public Ingress for this endpoint. Discovery is therefore recommended directly from the Pods.

Important metrics

occ_http_requests_total
occ_http_request_duration_seconds
occ_agents
occ_work_pending
occ_work_oldest_pending_age_seconds
occ_agent_operation_duration_seconds

Throughput:

sum by (cluster, installation) (
  rate(occ_http_requests_total[5m])
)

Request P95:

histogram_quantile(
  0.95,
  sum by (cluster, installation, le) (
    rate(occ_http_request_duration_seconds_bucket[5m])
  )
)

Backlog:

max by (cluster, installation) (
  occ_work_pending
)

Age of the oldest pending work:

max by (cluster, installation) (
  occ_work_oldest_pending_age_seconds
)

Backlog is especially important because the OCC relies on asynchronous reconciliation.

Logs

The API and Worker use structured logging. The Worker emits events such as worker.started, worker.health, worker.completed, worker.error and worker.stopped. Deployment events also include measurements such as durationMs, prepareMs, readinessWaitMs, activationMs and elapsedMs.

This lets you build dashboards that show not only whether an Agent failed, but in which reconciliation phase it got slow. One possible stack:

OCC
 │
 ├── metrics → Prometheus → Grafana
 │
 └── logs → Collector → Loki

OpenTelemetry can also be used in the general collection infrastructure, depending on the observability stack adopted.

Troubleshooting

Checking the Control Plane

kubectl get pods \
  -n openclaw-system \
  -o wide

kubectl get events \
  -n openclaw-system \
  --sort-by=.metadata.creationTimestamp

Locating the API and Worker

kubectl get pods \
  -n openclaw-system \
  -l app.kubernetes.io/instance=oce \
  --show-labels

kubectl logs -n openclaw-system <api-pod>

kubectl logs -n openclaw-system <worker-pod>

Namespace stuck in provisioning

First check that the Worker is running (worker.started, worker.health, worker.completed). Then validate:

kubectl get namespaces

kubectl get rolebindings -A

kubectl get networkpolicies -A

Possible causes include a missing Worker, insufficient RBAC, an incorrect NetworkPolicy, a different Compute Driver between API and Worker, and failed access to the Kubernetes API.

AgentRevision does not activate

kubectl get pods -A -o wide

kubectl describe pod \
  -n <tenant-namespace> \
  <agent-pod>

Investigate ImagePullBackOff, Pending, PVC Pending, readiness failure, missing Secret, ResourceQuota, NetworkPolicy and nodeSelector.

Gateway API

kubectl get gatewayclass

kubectl get gateway -A

kubectl get httproute -A

kubectl describe httproute \
  -n <namespace> \
  <route>

When the Gateway API CRDs are missing or the Worker lacks permission to manipulate the required routes, reconciliation fails; the OCC does not silently disable routing.

Development vs production

A local environment is for understanding how things work. It shouldn't be copied wholesale into production.

High availability and current limitations

It is important not to assume that "running on Kubernetes" automatically means active-active. The current architecture uses Recreate at key points.

The API Deployment uses the Recreate strategy, avoiding two controllers serving at once during certain updates. Each Agent Gateway also has one desired replica and uses Recreate, so there may be unavailability during replacements.

So Kubernetes does not equal automatic HA. In production, high availability must be analyzed separately for PostgreSQL, nodes, storage, network, registry, Envoy, DNS, the Control Plane and Agent gateways.

Costs and FinOps

The solution's cost is not just the OCC. Consider Control Plane nodes, Agent nodes, PostgreSQL, block storage, Envoy, observability, container registry and model API usage. The cost of the models themselves can easily exceed the Kubernetes cost.

Embedded vs Dedicated

• Embedded: fewer Pods, fewer PVCs, lower overhead;
• Dedicated: separate Gateway, separate Harness, additional storage, stronger isolation.

The more Agents you have, the more important it becomes to track CPU requests, memory requests, provisioned PVC, used PVC, Agent idle time and model spend.

Spot vs On-Demand

A general Kubernetes strategy for interruption-tolerant environments could be:

Control Plane, Gateways, PostgreSQL        → On-Demand
Rebuildable Harnesses, batch Agents,
evaluation workloads                       → Spot

However, you need to evaluate the behavior of ReadWriteOnce PVCs, session interruptions and rescheduling time. Putting every Agent on Spot indiscriminately can save compute while degrading availability and increasing recovery time.

Requests and Limits

Never size Agents only by theoretical maximum capacity. For example:

requests:
  cpu: 100m
  memory: 128Mi

limits:
  cpu: "4"
  memory: 4Gi

allows a large gap between scheduling and potential consumption. With 100 Agents:

scheduler:  100 × 100m = 10 CPUs
burst:      100 × 4    = 400 CPUs

This scenario can cause severe contention. Sizing should consider CPU P50 and P95, working set memory, CPU throttling, OOMKilled, Agent concurrency and queue depth.

Best practices

A mature implementation should follow at least these guidelines:

1. separate Control Plane and Agent nodes;
2. use images pinned by SHA-256;
3. keep PostgreSQL outside the OCC Pods in production;
4. separate application and migration credentials;
5. enable verified TLS on the database;
6. use default-deny NetworkPolicy;
7. actually test CNI enforcement;
8. give Gateway and Harness different ServiceAccounts;
9. never hand controller credentials to Agents;
10. use block-backed, SQLite-compatible storage for Gateways;
11. monitor backlog and reconciliation time;
12. alert on occ_work_oldest_pending_age_seconds;
13. keep Gateway API and Envoy under explicit platform management;
14. validate a real model turn after deployment;
15. treat AgentRevision as the immutable unit of change.

What to avoid

Avoid treating helm install succeeded as a synonym for an operational platform. You still need to validate: OCC authentication, the Worker, Kubernetes access, Gateway routing, Agent readiness and a model request.

Also avoid:

• latest in production images;
• overly broad NetworkPolicies, such as ipBlock with cidr: 0.0.0.0/0, whenever the flow can be restricted;
• running the Control Plane and Agents without node placement separation;
• granting cluster-admin to the Agents' runtime just to quickly fix RBAC problems.

When to use it

The OCC makes sense when you need multiple Agents, multi-tenancy, centralized IAM, auditing, immutable revisions, isolation between teams, Secrets control, lifecycle automation, a Kubernetes runtime and Gateway control.

It is particularly interesting for Platform Engineering teams building an enterprise agent platform.

When not to use it

For a single, simple internal agent, this architecture may be overkill. If the requirement is just 1 OpenClaw, 1 API key, 1 team and 1 namespace, a conventional Kubernetes Deployment or an OpenClawInstance-based operator may be operationally simpler.

It's also worth assessing whether the organization really needs Kubernetes. For small environments, a simpler deployment can considerably reduce cost, complexity, operational time and failure surface.

Practical summary

User
 ↓
OCC API
 ↓
IAM
 ↓
PostgreSQL
 ↓
Durable Work
 ↓
Controller Worker
 ↓
Compute Driver
 ↓
Kubernetes API
 ↓
Namespace / Gateway / Harness

The main architectural distinction is that Agent, AgentRevision, Configuration and Namespace are OpenClaw resources, not Kubernetes CRDs. Gateway and HTTPRoute, on the other hand, are part of the Kubernetes Gateway API used by the infrastructure.

There is also a separate approach using a Kubernetes Operator with OpenClawInstance, suited to those who want to manage instances directly from the Kubernetes API.

Conclusion

The most interesting aspect of the OpenClaw Control Plane is not the Helm installation. It is the control model built on top of Kubernetes.

Instead of letting each team directly manage Deployment, Service, Secret, PVC, NetworkPolicy, HTTPRoute and ServiceAccount, the platform works with concepts closer to the domain: Namespace, Agent, Configuration, AgentRevision, Secret and ServiceAccount.

The OCC receives these intents, authorizes the operation, persists the desired state, creates durable work and uses the Controller Worker and Compute Driver to reconcile Kubernetes. This separation turns Kubernetes from an interface consumed directly by the user into the platform's execution substrate.

It is exactly the same principle used by good internal platforms:

Developer
      ↓
Platform API
      ↓
Policy
      ↓
Controller
      ↓
Cloud / Kubernetes

The result is an architecture better suited to environments where agents stop being isolated experiments and become part of corporate infrastructure.

For a modern Platform Engineering strategy, that is the central point: not just offering Kubernetes to the AI team, but building a control layer able to standardize the identity, isolation, configuration, deployment, observability, security and lifecycle of Agents.