OpenClaw EnterpriseDOCSGitHub

Set up OpenClaw Enterprise on Kubernetes

Prepare a Kubernetes cluster you already operate, then follow the shared production installation runbook to install and authenticate to the OpenClaw Control Plane (OCC). If you want to try OpenClaw Enterprise on your machine, use Local Setup.

Before you start

You need:

The standard Kubernetes guide covers node pools, storage, and network access in detail. For AWS, start with Amazon EKS; it uses the same Helm installation procedure.

1. Check the cluster

Run from the repository root. Set the private directory and approved cluster context. Save the administrator-provided kubeconfig at the path shown before continuing:

bash
export OCC_INPUT_DIRECTORY='/secure/occ'export KUBECONFIG_FILE="$OCC_INPUT_DIRECTORY/kubeconfig"export CONTEXT='<approved-cluster-context>'install -d -m 700 "$OCC_INPUT_DIRECTORY"# Save the administrator-provided kubeconfig at $KUBECONFIG_FILE before continuing.chmod 600 "$KUBECONFIG_FILE"kubectl --kubeconfig "$KUBECONFIG_FILE" --context "$CONTEXT" versionkubectl --kubeconfig "$KUBECONFIG_FILE" --context "$CONTEXT" get nodes -L oce-rolekubectl --kubeconfig "$KUBECONFIG_FILE" --context "$CONTEXT" get storageclasses

Confirm the server version, that nodes have the control-plane and Agent labels you plan to use, and that the required StorageClasses exist. The provided examples use oce-role=control and oce-role=agents. If your labels differ, replace oce-role in the get nodes command with your label key and update the configuration.

2. Prepare the inputs and install OCC

In the same operator shell, complete Install the production control plane through its authentication check. It covers image selection, configuration, system Secrets, private routing, the bootstrap volume, and Helm installation. Generate configuration with its recommended profile path, or use its advanced manual YAML branch when you need custom settings.

If installation fails, follow platform troubleshooting and bootstrap recovery.

3. Deploy and verify an Agent

A ready control plane and a passing authentication check do not prove that an Agent can answer a model request.

Keep the same shell and temporary key copy to prepare Namespaces and deploy Agents, then verify workspace access and a real model response from that Agent. These are separate completion checks; a successful deployment does not establish either one. At the end, remove only the temporary credential copies. The local first-Agent walkthrough uses a different installation and should not be run against this one.

Search documentation