Learn OpenClaw - Installation & Basic Setup

#Introduction

Welcome to episode 3 of the Learn OpenClaw series! In episode 2 you understood the architecture: the control plane that decides, the data plane that executes, and the policy engine that evaluates. Now you'll bring that theory to life on the cluster you created in episode 0.

This episode contains installation steps that must be run in sequence. Starting with adding the helm repository, deploying OpenClaw, doing the initial configuration, verifying components, and running a sample application. If a step fails, the troubleshooting section at the end of the episode will help.

#Prerequisites: Cluster and Tooling

Make sure your episode 0 environment is still alive. Check the cluster status and the active context:

kubectl get nodes
kubectl config current-context

I recommend creating a separate namespace for OpenClaw, e.g. openclaw-system, so its components stay neatly grouped:

kubectl create namespace openclaw-system

#Deploying OpenClaw with Helm

OpenClaw is distributed as a Helm chart. First, add its official repository and update the index:

helm repo add openclaw https://charts.openclaw.example
helm repo update

Once the repository is ready, install the chart into the openclaw-system namespace, then check the release status and the Pods that were created:

bashbash

helm install openclaw openclaw/openclaw{:bash} \
  --namespace openclaw-system \
  --create-namespace

helm status openclaw --namespace openclaw-system
kubectl get pods -n openclaw-system

Helm will create all the resources: CRDs for policies, the control plane controller, and the data plane daemonset. Wait a moment until all Pods have a Running or Completed status. If any is in CrashLoopBackOff, note the Pod name — we'll cover it in the troubleshooting section.

#Initial Configuration

After installation, there are a few configuration values you'll typically adjust: data plane mode (for example CNI integration), default values for mTLS, and logging level. Configuration is stored as Helm values and can be viewed first:

helm get values openclaw --namespace openclaw-system

For light customization, save the values in a values.yaml file and upgrade the release:

dataPlane:
  mode: envoy
logging:
  level: info
policyEngine:
  cache:
    enabled: true
    size: "512Mi"

helm upgrade openclaw openclaw/openclaw{:bash} \
  --namespace openclaw-system \
  -f values.yaml

Get into the habit of using helm upgrade with a values.yaml file from the start. Configuration recorded in a file is far easier to audit than repeated --set flags.

#Verifying Components

Verification is the bridge between "installed" and "working". Check three things: CRDs are registered, the controller is running, and the data plane is ready.

Checking OpenClaw CRDs

kubectl get crds | grep openclaw

You should see CRDs like policies.openclaw.io and gateways.openclaw.io. Then make sure the control plane controller is healthy:

Checking the controller

kubectl get deploy -n openclaw-system
kubectl logs -n openclaw-system -l app=openclaw-control-plane --tail=50

Clean logs indicate the controller has successfully connected to the Kubernetes API and is ready to watch for policy changes.

#Running the Sample Application

The most satisfying part: running an application protected by OpenClaw. OpenClaw typically provides an openclaw-sample chart containing two simple services, e.g. web and api, complete with default policies:

helm install openclaw-sample openclaw/openclaw-sample{:bash} \
  --namespace sample

Once the application is alive, verify the services and policies that were created:

Viewing sample services and policies

kubectl get svc -n sample
kubectl get policies -n sample

Now test communication between services. Run a temporary Pod that can send requests to api:

kubectl run -it --rm debug --image=curlimages/curl --namespace sample -- sh
curl http://api:8080/healthz

If the default policy allows it, you'll get a successful response. If you get 403, the policy is rejecting — and that's actually proof the policy engine is working.

#Common Troubleshooting

Some of the most common issues during setup:

• Pod CrashLoopBackOff: usually a resource conflict or CRDs not yet registered. Check with kubectl describe pod <name> -n openclaw-system and look at the events at the bottom.
• Policy has no effect: check whether the controller is syncing the policy. Run kubectl describe policy <name> and compare the status with your expectations.
• No data plane in application Pods: make sure the application namespace is injected correctly per the documentation, for example via a namespace label or annotation.

#Wrap-Up

In episode 3 you successfully deployed OpenClaw to your cluster with helm, adjusted the initial configuration through values.yaml, verified the CRDs, controller, and data plane, and ran a sample application protected by policy for the first time.

Key takeaways:

• Always install OpenClaw in a separate namespace like openclaw-system.
• Use helm upgrade with a values.yaml file, not repeated --set flags.
• Verify three layers: CRDs registered, controller healthy, data plane active.
• The sample application is the fastest way to validate that the policy engine really works.
• The troubleshooting pattern follows the install order: helm, CRDs, controller, data plane.

In the next episode, episode 4, we'll write your first network policy and traffic rules: defining inbound and outbound policies, doing layer 7 routing and request filtering, and understanding priority, scope, and matching rules. This is the episode where OpenClaw starts truly managing traffic.