Q&A: OpenClaw Sidecar Deployment — Container Images, PostgreSQL, Key Vault, Helm Chart

[imran-siddique]

Great questions — and thank you for digging in deeply enough to find these gaps. You're right that the deployment docs need work. Let me address each point honestly.

1. Container Images (trust-engine, policy-server, audit-collector, api-gateway)

These images are not published to any public registry. This is the biggest gap in our deployment story and I should have been clearer about it.

What to do today: You need to build the images yourself and push to your own ACR (or any private registry). The source is in the repo but we don't ship pre-built containers yet. Here's the quickest path:

# Build the governance sidecar from the agent-os package
cd packages/agent-os
docker build -t <your-acr>.azurecr.io/agentmesh/governance-sidecar:0.3.0 .
docker push <your-acr>.azurecr.io/agentmesh/governance-sidecar:0.3.0

# Then in your Helm values, override the image repositories:
# image.repository: <your-acr>.azurecr.io/agentmesh/governance-sidecar

The Helm chart's 4-component architecture (api-gateway, trust-engine, policy-server, audit-collector) is the production-grade design. For getting started with OpenClaw sidecar governance, you don't need all 4 — the single governance sidecar container from packages/agent-os bundles policy + trust + audit into one process. I'll update the docs to make this clearer.

2. PostgreSQL — Is It Necessary?

No, PostgreSQL is NOT required for the basic sidecar setup. Here's the breakdown:

Component	Requires PostgreSQL?	Purpose
Governance Sidecar (single-pod)	❌ No	Audit logs go to stdout/PVC
Full AgentMesh cluster (HA)	Optional	Persistent audit storage, agent registry
Azure Monitor export	❌ No	Uses Event Grid / OTLP instead

PostgreSQL appears in the architecture diagram because the enterprise HA deployment uses it for persistent audit log storage and agent registry state. For the OpenClaw sidecar scenario, audit logs write to the container filesystem or stdout — you just need kubectl logs to see them.

3. Key Vault Secrets — What Goes There?

The Key Vault stores:

Secret	Purpose	Required?
Ed25519 agent private keys	Agent identity signing	Yes, if using DID identity
TLS cert/key	Inter-component mTLS	Yes, if TLS enabled
Redis connection string	Session/cache state	Only for HA mode
PostgreSQL credentials	Audit persistence	Only if using PG

For the OpenClaw sidecar, you only need the agent private key in KV if you want DID-based identity. For a basic policy-only setup, you can skip KV entirely and just mount policies via ConfigMap.

4. OpenClaw Sidecar Helm Chart — The Honest Answer

You are correct that the values-openclaw.yaml references values that don't exist in the Helm chart templates. The chart was designed for the 4-component architecture (trust-engine, policy-server, audit-collector, api-gateway). The openclaw.enabled and sidecar.enabled values in the OpenClaw deployment guide are aspirational — they document where we're heading, not where we are today.

What works right now for OpenClaw sidecar:

Option A: Docker Compose (local dev — works today)

The Docker Compose example in the sidecar doc works. Build the governance sidecar from packages/agent-os and run alongside OpenClaw.

Option B: Plain K8s manifests (production — works today)

Write a Pod spec with two containers (OpenClaw + governance sidecar) instead of using the Helm chart:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: openclaw-governed
  namespace: openclaw-governed  # Use your own namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: openclaw-governed
  template:
    spec:
      containers:
        - name: openclaw
          image: ghcr.io/openclaw/openclaw:latest
          env:
            - name: GOVERNANCE_PROXY
              value: http://localhost:8081
        - name: governance-sidecar
          image: <your-acr>.azurecr.io/agentmesh/governance-sidecar:0.3.0
          ports:
            - containerPort: 8081
            - containerPort: 9091
          env:
            - name: POLICY_DIR
              value: /policies
          volumeMounts:
            - name: policies
              mountPath: /policies
              readOnly: true
      volumes:
        - name: policies
          configMap:
            name: openclaw-policies

Option C: Helm chart with overrides (we need to build this)

This is the gap — we need to add sidecar injection support to the Helm chart. I'll track this as a feature.

Namespace: Use openclaw-governed or whatever you prefer — the agentmesh namespace is for the full cluster deployment.

PostgreSQL/EventGrid: Not needed for the sidecar scenario. Only needed for full enterprise deployment.

Next Steps

I'm going to:

1. File an issue to track the missing container images and publish to GHCR
2. Update the OpenClaw sidecar docs with the plain K8s manifest approach that works today
3. Add a "Getting Started" section that's honest about what requires building vs what's ready

Your offer to help improve the docs after getting it working is very welcome. If you get the Docker Compose or plain K8s approach working, a PR with your learnings would be incredibly valuable.

Thanks for pushing on this — these are exactly the questions that make the docs better for everyone. 🙏

[imran-siddique]

Update: All Issues Fixed in Main

I've merged PR #954 that addresses every issue raised. Please pull latest main and retry.

What changed:

1. Container images - Added Dockerfile.sidecar at packages/agent-os/Dockerfile.sidecar. Build with: docker build -f Dockerfile.sidecar .
2. PostgreSQL - Docs now clearly state it's NOT required for sidecar mode
3. Key Vault - Added 'What Secrets Do I Need?' tables. For basic sidecar: no secrets required
4. Production deployment - Replaced broken Helm values with working plain K8s manifests (kubectl apply directly)

Thank you for the detailed feedback - it made the docs significantly better. Please sync to latest and continue testing. If you'd like to contribute learnings back as a PR, very welcome!