feat(openclaw-helm): bump to chart 1.3.4, document config merge modes

Bump version references to 1.3.4 (appVersion 2026.2.6). Rewrite the
GitOps Behavior section to cover the new configMode merge/overwrite
options introduced since 1.3.0, add ArgoCD ignoreDifferences hint for
merge mode, and mention the init-config container in the architecture
overview.

Author: serhanekicii

openclaw-helm.html/0.md

@@ -22,7 +22,7 @@ This post walks through deploying OpenClaw on Kubernetes using [my Helm chart](h
 The setup is straightforward:
 
 - **OpenClaw** runs as a single-replica Deployment (it cannot scale horizontally by design)
-- **Sidecars and init containers** include a Chromium browser for automation and an init-skills container for declaratively installing skills and runtime dependencies
+- **Sidecars and init containers** include a Chromium browser for automation, an init-config container for initializing configuration (with merge or overwrite modes), and an init-skills container for declaratively installing ClawHub skills and runtime dependencies
 - **Configuration** is stored in a ConfigMap using JSON5 format
 - **Persistent storage** keeps workspace data, sessions, and application state
 - **Secrets** are managed externally (Vault recommended, but optional)
@@ -31,7 +31,24 @@ The Helm chart is built on the [bjw-s app-template](https://github.com/bjw-s/hel
 
 #### GitOps Behavior
 
-This is important: **any configuration done via the OpenClaw web UI is ephemeral**. When the pod restarts, UI changes are wiped. The source of truth is your Helm values and manifests in Git. This is intentional. If you want persistent configuration changes, commit them to your repository.
+The chart supports two config modes, controlled by the `configMode` value:
+
+- **merge** (default): Helm values are deep-merged with the existing config on the PVC at each restart. Runtime changes made through the web UI—paired devices, settings tweaks, etc.—persist across pod restarts. Your Helm values act as defaults and overrides, but they don't wipe what's already there.
+- **overwrite**: strict GitOps. The config file is replaced wholesale on every restart, so the source of truth is purely your Helm values and manifests in Git. Any changes made through the UI are ephemeral.
+
+If you want full declarative control with no drift, set `configMode: overwrite`. If you prefer a more forgiving setup where UI changes survive restarts, leave the default.
+
+If you use merge mode with ArgoCD, you'll want to tell ArgoCD to ignore diffs on the ConfigMap so it doesn't fight with runtime config on the PVC:
+
+```yaml
+spec:
+  ignoreDifferences:
+    - group: ""
+      kind: ConfigMap
+      name: openclaw
+      jsonPointers:
+        - /data
+```
 
 ### Quick Start with Helm
 
@@ -118,11 +135,11 @@ name: openclaw
 description: OpenClaw deployment for my-cluster
 type: application
 version: 1.0.0
-appVersion: "2026.1.30"
+appVersion: "2026.2.6"
 
 dependencies:
   - name: openclaw
-    version: 1.3.0
+    version: 1.3.4
     repository: https://serhanekicii.github.io/openclaw-helm
 ```
 
@@ -259,6 +276,78 @@ spec:
 
 For TLS termination and DNS automation (using tools like [cert-manager](https://cert-manager.io/) and [external-dns](https://github.com/kubernetes-sigs/external-dns)), that's a topic that deserves its own post. For now, just know the Helm chart exposes the service on port 18789 and you can wire it up however fits your setup.
 
+### Network Policy Isolation
+
+Given OpenClaw's security profile—shell access, file reads, untrusted input processing—network policies add an important layer of defense. Even if the application gets compromised, network policies limit what an attacker can reach from within the pod.
+
+The Helm chart includes a network policy that's disabled by default. Enable it in your values:
+
+```yaml
+openclaw:
+  app-template:
+    networkpolicies:
+      main:
+        enabled: true
+```
+
+The default policy allows:
+
+- **Ingress** from the `gateway-system` namespace on port 18789
+- **Egress** to kube-dns for DNS resolution
+- **Egress** to all public internet IPs (blocks RFC1918 private ranges)
+
+This means OpenClaw can reach external APIs (Anthropic, OpenAI, messaging platforms) but cannot access your internal services, databases, or other workloads. The blast radius of a compromise stays contained.
+
+Adjust the ingress source to match your setup. If you're using ingress-nginx instead of Gateway API:
+
+```yaml
+openclaw:
+  app-template:
+    networkpolicies:
+      main:
+        enabled: true
+        rules:
+          ingress:
+            - from:
+                - namespaceSelector:
+                    matchLabels:
+                      kubernetes.io/metadata.name: ingress-nginx
+              ports:
+                - protocol: TCP
+                  port: 18789
+```
+
+If you need OpenClaw to reach specific internal services (Vault, a local LLM, internal APIs), add explicit egress rules:
+
+```yaml
+openclaw:
+  app-template:
+    networkpolicies:
+      main:
+        enabled: true
+        rules:
+          egress:
+            # ... keep existing rules ...
+            # Vault for secrets
+            - to:
+                - namespaceSelector:
+                    matchLabels:
+                      kubernetes.io/metadata.name: vault
+              ports:
+                - protocol: TCP
+                  port: 8200
+            # Local Ollama instance
+            - to:
+                - namespaceSelector:
+                    matchLabels:
+                      kubernetes.io/metadata.name: ollama
+              ports:
+                - protocol: TCP
+                  port: 11434
+```
+
+Note that network policies require a CNI that supports them—Calico, Cilium, and Weave all work. If you're running Flannel without the network policy controller, policies will be created but not enforced.
+
 ### Post-Installation: Device Pairing
 
 Once the pod is running, you need to pair your device with OpenClaw.