Abo -30% SUB30
OpenClaw auf Kubernetes deployen mit Helm Charts: Praxisanleitung
$ ./blog/guides
Anleitungen

OpenClaw auf Kubernetes deployen mit Helm Charts: Praxisanleitung

ClawHosters
ClawHosters von Daniel Samer
6 Min. Lesezeit

Du betreibst bereits einen Kubernetes Cluster? Dann ist es sinnvoll, OpenClaw dort mit einzupacken. Dein Infra-Team kennt das Tooling, Monitoring läuft, und ein zusätzlicher Workload fällt kaum ins Gewicht.

Aber wenn du K8s nur für OpenClaw aufsetzen willst, lies zuerst den Kostenabschnitt weiter unten.

Diese Anleitung behandelt beide Community openclaw helm chart Optionen, die tatsächlichen Install-Befehle und die Stolperfallen, über die sonst niemand spricht, bis du sie nachts um zwei selbst entdeckst.

Welches OpenClaw Helm Chart passt zu dir?

Es gibt kein offizielles OpenClaw Helm Chart vom Projekt selbst. Zwei von der Community gepflegte Charts füllen diese Lücke, und beide verfolgen unterschiedliche Ansätze.

Chrisbattarbee/openclaw-helm ist die einfachere Variante. Drei Befehle und du bist am Laufen. Das Chart verfolgt das neueste OpenClaw Image (2026.3.2 zum Zeitpunkt dieses Artikels) und liefert eine übersichtliche Values-Datei ohne zu viele vorgefertigte Meinungen.

serhanekicii/openclaw-helm baut auf dem bjw-s App-Template auf. Es bringt strengere Security-Defaults mit, Network Policies und eine stärker vorgegebene Struktur. Wenn dein Cluster bereits Calico oder Cilium für Network Policy Enforcement nutzt, passt dieses Chart gut rein.

Welches solltest du nehmen? Wahrscheinlich Chrisbattarbee's, wenn du den schnellsten Weg zu einer laufenden Instanz willst. Serhanekicii's, wenn dein Security-Team Wert auf Pod-Level Network Isolation legt.

OpenClaw Helm Chart installieren

So sieht das eigentliche openclaw kubernetes deployment mit dem Chrisbattarbee Chart aus:

helm repo add openclaw https://chrisbattarbee.github.io/openclaw-helm
helm repo update
helm install openclaw openclaw/openclaw

Drei Befehle. OpenClaw läuft mit Standardeinstellungen auf deinem Cluster.

Für eine angepasste Values-Datei (die du in Production auf jeden Fall willst):

helm install openclaw openclaw/openclaw -f my-values.yaml

Die wichtigsten Values-Einstellungen

In der values.yaml fallen die eigentlichen Entscheidungen. Hier die Punkte, die für deine openclaw helm konfiguration wirklich zählen:

Resource Requests und Limits

resources:
  requests:
    cpu: 100m
    memory: 512Mi
  limits:
    cpu: 2000m
    memory: 2Gi

Der Speicherverbrauch von OpenClaw hängt stark von deiner Tool-Konfiguration und der Größe des Conversation-Verlaufs ab. Ich würde mit 512Mi starten und die Metriken beobachten. Manche Setups fressen regelmäßig 1,5Gi.

Persistent Storage

persistence:
  enabled: true
  size: 10Gi
  accessModes:
    - ReadWriteOnce

Hier liegen Agent-Konfigurationen, Conversation Logs und die SQLite-Datenbank. Der ReadWriteOnce Access Mode ist wichtig: Nur ein Pod kann dieses Volume mounten. Das wird im nächsten Abschnitt relevant.

Config Mode

configMode: merge

Zwei Optionen. merge behält UI-Änderungen bei Helm Upgrades bei. overwrite ersetzt alles mit dem, was in deiner Values-Datei steht. Für Teams, die Config über GitOps verwalten, ist overwrite sauberer. Für alle anderen vermeidet merge unangenehme Überraschungen.

Stolperfallen, die dich erwischen werden

Nach einiger Zeit mit OpenClaw auf K8s, und basierend auf dem, was uns Nutzer über unseren Self-Hosting vs. Managed Vergleich berichten, sind das die Probleme, die Leute auf dem falschen Fuß erwischen.

Die configMode merge Falle. Du setzt configMode: merge, konfigurierst deinen Agent über die UI und startest dann helm upgrade mit leicht veränderten Values. Deine UI-Konfiguration wird teilweise überschrieben. Das Merge ist kein Deep Merge. Wenn du einen Key in der values.yaml definierst, der auch in der UI-Config existiert, gewinnt der Helm-Wert. Dokumentiere genau, welche Einstellungen wo leben. Oder entscheide dich konsequent für einen Weg.

Kein horizontales Skalieren. OpenClaw nutzt SQLite und lokalen File Storage. Das PVC hat ReadWriteOnce. Die Deployment-Strategie ist Recreate, nicht RollingUpdate. Zwei Replicas gleichzeitig? Geht nicht. Das ist eine Single-Instance-Anwendung. Wenn du mehr Last verarbeiten musst, deploye separate OpenClaw-Instanzen für verschiedene Agents, statt Pods horizontal zu skalieren.

Upgrades verursachen Downtime. Weil die Strategie Recreate ist (der alte Pod stoppt bevor der neue startet), bedeutet jedes Helm Upgrade 30 bis 90 Sekunden Downtime. Für ein internes Team-Tool wahrscheinlich kein Problem. Für einen kundenseitigen Agent solltest du Upgrade-Fenster einplanen.

Security Checkliste

Wenn du einen AI Agent auf Kubernetes betreiben willst, dann beachte mindestens Folgendes:

Speichere deine LLM API Keys in Kubernetes Secrets, nicht in ConfigMaps. Aber bedenke: K8s Secrets sind nur base64-encoded, nicht verschlüsselt im Ruhezustand (es sei denn, du hast Encryption auf API Server Ebene konfiguriert). Wie Daniel Hnyk in seiner Self-Hosting-Anleitung erklärt, wird das von vielen unterschätzt.

Aktiviere Network Policies, wenn dein CNI sie unterstützt. Das serhanekicii Chart bringt diese standardmäßig mit.

Beschränke die Tool-Allowlists für deinen Agent. Ein AI Agent mit uneingeschränktem Shell-Zugriff auf deinem Cluster ist... nicht ideal. In unserem Security Hardening Guide findest du die vollständige Checkliste.

Ist Kubernetes die richtige Wahl für dich?

Ehrliche Antwort? Kommt darauf an, ob du bereits einen Cluster betreibst.

OpenClaw auf einem bestehenden K8s Cluster verursacht vielleicht 5 bis 20 Dollar pro Monat an zusätzlichen Ressourcenkosten, plus ein paar Stunden initiales Setup. Völlig vertretbar, wenn die Infrastruktur ohnehin steht.

Einen neuen Kubernetes Cluster nur für OpenClaw aufsetzen? Das ist eine andere Rechnung. Du schaust auf 50 bis 200 Dollar pro Monat für den Cluster selbst, 8 bis 20 Stunden initiales Setup (mehr, wenn du K8s parallel lernst), und 2 bis 4 Stunden monatliche Wartung für Upgrades, Zertifikatsrotation und was auch immer dieses Mal kaputtgegangen ist.

Vergleiche das mit Managed Hosting bei ClawHosters, wo das Setup ungefähr 60 Sekunden dauert und die Kosten bei 19 Dollar pro Monat starten. Kein Cluster-Management, keine YAML-Debugging-Sessions, automatische Updates.

Für Teams, die bereits auf Kubernetes setzen, ist das OpenClaw Helm Chart eine solide Option. Für alle anderen spricht die Rechnung wahrscheinlich für Managed.

Häufig gestellte Fragen

Nein. OpenClaw nutzt SQLite und lokalen File Storage mit einem ReadWriteOnce PVC. Du bist auf ein einzelnes Replica beschränkt. Wenn du mehrere Agents brauchst, deploye separate OpenClaw-Instanzen mit jeweils eigenem Storage und eigener Konfiguration.

Chrisbattarbee/openclaw-helm für das einfachste Setup. serhanekicii/openclaw-helm, wenn du Network Policies und strengere Security-Defaults brauchst. Beide verfolgen aktuelle OpenClaw Releases.

Das hängt von deiner PVC Reclaim Policy ab. Die meisten Kubernetes Storage Classes setzen `reclaimPolicy: Delete` als Standard, was bedeutet: Ja, deine Daten sind weg. Setze die Reclaim Policy deines PVC auf `Retain`, wenn du Daten nach einem Uninstall behalten willst.

Ja. Beide Charts funktionieren mit GitOps Tooling. Setze `configMode: overwrite` in deinen Values, damit dein Git Repo die einzige Quelle der Wahrheit ist. Im `merge` Modus können UI-Änderungen und GitOps-Änderungen in Konflikt geraten.

Rechne mit 30 bis 90 Sekunden pro Upgrade. Das Deployment nutzt eine Recreate-Strategie (der alte Pod wird beendet, bevor der neue startet), weil zwei Pods das ReadWriteOnce Volume nicht gleichzeitig mounten können.
*Zuletzt aktualisiert: März 2026*

Quellen

  1. 1 Chrisbattarbee/openclaw-helm
  2. 2 serhanekicii/openclaw-helm
  3. 3 Self-Hosting vs. Managed Vergleich
  4. 4 Daniel Hnyk in seiner Self-Hosting-Anleitung erklärt
  5. 5 Security Hardening Guide
  6. 6 Managed Hosting bei ClawHosters
  7. 7 Kosten bei 19 Dollar pro Monat starten