Deploy OpenClaw Enterprise

Install OpenClaw Enterprise (OCE), verify access to the OpenClaw Control Plane (OCC), then deploy an Agent and check its model response. Choose one installation path below and keep its operator shell and protected files for the next step. Run repository commands from the matching release checkout's root. Starting OCC needs no model credential; an Agent needs one to send a model request.

OCE's OpenShell integration is not production-qualified. Review its remaining qualification work before choosing an OpenShell installation path.

Development

Use Local Setup to start the platform with Kubernetes and verify authenticated access. Then prepare the local Agent session. The local Kubernetes development guide explains the profile for contributors working on the platform.

Verify development

Follow Local Setup to verify the control plane. That check proves authenticated access; it does not prove an Agent can answer a model request. Follow model verification for that result. For local Kubernetes images and cleanup, see local operations.

Open the platform console

Use Local Setup for local sign-in. In production, open /console/ on the approved internal HTTPS origin matching OCC_AUTH_BASE_URL. Sign in with a human administrator account; service keys are for automation. The console reference covers browser behavior and limits.

Production

The Kubernetes and EKS setup guides install OCE with OpenShell and prepare the shared operator session for Deploy your first Agent. Do not repeat the custom installation sequence below after either setup guide. Installation profiles and the custom Helm procedure use a separate configuration and Agent deployment path. Cluster hosting does not select the Agent model provider.

Production prerequisites

• Cluster and access: Kubernetes 1.35 or later, IPv4 connectivity, a network plugin that enforces NetworkPolicies, and an explicitly selected Kubernetes context. The operator needs permission to create namespaces, RBAC, Secrets, and storage claims. Older Kubernetes versions are outside the supported boundary.
• Routing: Envoy Gateway, Gateway API CRDs, cert-manager, and an existing Envoy GatewayClass. Complete the workspace routing requirements. The OCE chart does not install these controllers or create public TLS or Ingress. Provide an approved internal HTTPS origin and exact IPv4 /32 egress destinations.
• Operator tools: Helm, a version-compatible kubectl, Python 3, jq, yq v4, and the OCC CLI. Use Bash for image selection and model verification. To generate a custom Installation from a profile, use Node.js satisfying engines.node in the selected release checkout's package.json. The manual YAML examples skip profile generation.
• Images: Docker and Git to select published images and their matching source checkout and chart. Use immutable controller and runtime image digests. Buildx is needed only when building images. Every eligible node needs registry pull access; see private registry delivery.
• Database: External PostgreSQL 18.6 with separate application and migration roles and verified TLS. See version compatibility. Prepare protected startup, database, authentication, and any selected Backend credentials during installation.
• Node pools: A trusted pool for OCC and dedicated Agent gateways, separate from the pool for Harness and embedded Agent Pods. Match the reviewed labels in controlPlane.nodeSelector, runtime.gatewayNodeSelector, and runtime.nodeSelector; see Kubernetes cluster preparation.
• Storage: A fresh protected bootstrap PVC and gateway storage. Dedicated Agent workspaces also need a default StorageClass supporting ReadWriteOnce. Use the storage requirements to select capacities and classes.
• Agent authentication: Installation alone does not need a model credential. To run an Agent with an OpenAI API key, provide the credential and grant the Agent operate on its exact Secret. Fresh native-IAM bootstrap gives its administrator service key the required Installation administer, Namespace read, and Secret read permissions. With a limited credential, arrange for an administrator to create the grant. Kubernetes RBAC does not replace OCC IAM.

Production installation sequence

For a custom Helm installation, follow these pages in order:

1. Select images and install the control plane. Generate configuration from an installation profile (recommended) or copy the manual YAML examples, then create system Secrets, prepare the fresh bootstrap PVC, and install the chart once with occ installation install. Keep the bootstrap key in the installation shell. Use it there to authenticate to the production API.
2. Prepare Namespaces and deploy Agents. Grant tenant RoleBindings, choose embedded OpenClaw or dedicated Codex, and grant access to the model Secret. Switch to the Namespace service key in a separate shell before deploying the reviewed Configuration with occ agent deploy-first.
3. Verify the production workload. Confirm the selected version and require a real model response. The guide offers a TUI and an HTTP check using the optional loopback password on Kubernetes trusted-proxy gateways.

Before upgrading a retained installation, complete the upgrade checklist. Then use production image upgrades to release the control plane without replacing Agent revisions, or to update Agent runtimes and redeploy the running fleet. Runtime releases require an interruption window. For a persistent Helm installation on k3d, use local k3d image upgrades.

For ongoing business operation, use production handoff to record owners, credential renewal, alert response, and recovery decisions. When external sign-in needs recovery or must be turned back off, use sign-in maintenance with the API stopped.

For private workspace-file administration, configure Agent workspace routing. For operational logs, use platform observability.

To exercise this production procedure in a disposable local Kubernetes cluster, build and import local images, then resume the production installation sequence with the generated YAML copies. For first-time setup, use Local Setup.

Stop or remove a production deployment

Inventory tenant workloads before uninstalling the control plane:

helm uninstall oce --namespace openclaw-system \  --kubeconfig "$KUBECONFIG_FILE" --kube-context "$CONTEXT"

Helm does not own external PostgreSQL, operator-created Secrets, bootstrap PVCs, or tenant workloads created by Compute. Retain database, bootstrap storage, and tenant resources until recovery and retention requirements are satisfied.

For startup diagnosis, see the production startup flow. For runtime proof, see the production TUI flow.

Customization

Apply a console theme to customize the product name, logo, browser icons, and colors through mounted files with the upstream image.

Use Helm values, Kubernetes manifests, Installation startup YAML, and Collector Secrets for production. Use deploy/runtime for runtime image recipe and pinned source identity. The settings reference and Driver references own field defaults, precedence, and limits.

Trusted Installation YAML can also select the SSH Compute Driver; that reference owns host configuration, credentials, and operational limits.

Trusted Installation YAML can select a PluginDriver for Agent plugin resolution. Agent create/update stores structurally valid plugin maps; deployment startup validates catalog membership and policy support. SSH Compute rejects nonempty plugin maps and Agent default plugin approver policies, so use Kubernetes Compute for those runtime paths. See Agent plugins for the current contract and testing for fixture prerequisites.

Related

• Operate the platform
• Troubleshoot the platform
• Service API keys, rotation, and bootstrap recovery
• Credential renewal and revocation
• Render installation profiles
• Local Kubernetes, development TUI, and cleanup
• Local Kubernetes development inner loop
• Configuration and settings