feat(openclaw-helm): add SEO intro, security caveat, and editorial fixes

- Add SEO-friendly introduction paragraph and update page title
- Add blast radius caveat paragraph in security section
- Replace em dashes with natural phrasing throughout
- Fix inline references into proper markdown links (Cloudflare Tunnel, OpenBao)
- Add App of Apps pattern link to ArgoCD section
- Simplify CNI network policy note

Author: serhanekicii

openclaw-helm.html/0.md

@@ -1,4 +1,6 @@
-If you've been anywhere near Hacker News in the past few weeks, you've probably seen OpenClaw. The project, originally named Clawdbot, then briefly Moltbot before settling on its current name, has exploded in popularity since late last year. It crossed 100,000 GitHub stars and attracted around 2 million visitors in a single week. The hype got so intense that [Cloudflare's stock jumped 14%](https://www.reuters.com/business/cloudflare-surges-viral-ai-agent-buzz-lifts-expectations-2026-01-27/) because people were using their tunnel services to host the tool. Cloudflare even used the opportunity to come up with [Moltworker](https://blog.cloudflare.com/moltworker-self-hosted-ai-agent/), a proof of concept that runs OpenClaw on their Developer Platform using Sandboxes, Browser Rendering, and R2 storage.
+OpenClaw is an open-source AI agent that connects to messaging platforms and acts autonomously. This post covers deploying it on Kubernetes with a Helm chart that supports ArgoCD GitOps, config merge modes, declarative skill installation, network policy isolation, and secrets management.
+
+If you've been anywhere near Hacker News in the past few weeks, you've probably seen OpenClaw. The project, originally named Clawdbot, then briefly Moltbot before settling on its current name, has exploded in popularity since late last year. It crossed 100,000 GitHub stars and attracted around 2 million visitors in a single week. The hype got so intense that [Cloudflare's stock jumped 14%](https://www.reuters.com/business/cloudflare-surges-viral-ai-agent-buzz-lifts-expectations-2026-01-27/) because people were using [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) to host the tool. Cloudflare even used the opportunity to come up with [Moltworker](https://blog.cloudflare.com/moltworker-self-hosted-ai-agent/), a proof of concept that runs OpenClaw on their Developer Platform using Sandboxes, Browser Rendering, and R2 storage.
 
 What makes OpenClaw interesting isn't just that it's another AI assistant. It connects to your messaging platforms (WhatsApp, Telegram, Signal, Slack, Discord, and more) and does things autonomously. It's less chatbot, more autonomous agent. Give it a task, let it run, wake up to results.
 
@@ -13,6 +15,8 @@ OpenClaw's power comes with real security risks. The tool has shell access, read
 
 Running OpenClaw in Kubernetes provides meaningful isolation compared to running it directly on your workstation. Container isolation, network policies, and resource limits contain the blast radius if something goes wrong. Your host filesystem, credentials, and other workloads remain protected behind namespace boundaries. For anyone considering OpenClaw in a work context or handling sensitive data, Kubernetes is the safer option.
 
+That said, container isolation and network policies don't make OpenClaw completely safe. The tool still processes untrusted input and executes code inside the container. If a prompt injection leads to code execution, the damage is contained to the pod and whatever network access you've allowed, which is a lot better than having it run on your workstation with access to everything. The goal is minimizing blast radius, not eliminating risk entirely. Treat these measures as layers of defense that make exploitation significantly harder, not as a guarantee that nothing can go wrong.
+
 I run Kubernetes for everything in my homelab. When I saw OpenClaw gaining traction, I realized there wasn't a Helm chart available for deploying it. So I built one. Everything in my homelab is declarative, version-controlled in Git, and managed through ArgoCD, that's just how I operate.
 
 This post walks through deploying OpenClaw on Kubernetes using [my Helm chart](https://github.com/serhanekicii/openclaw-helm).
@@ -33,7 +37,7 @@ The Helm chart is built on the [bjw-s app-template](https://github.com/bjw-s/hel
 
 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.
+- **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, and so on) 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.
@@ -166,7 +170,7 @@ openclaw:
     # ... rest of your configuration
 ```
 
-Update the `openclaw.json` section with your settings—trusted proxies, model provider, timezone, channels, etc.
+Update the `openclaw.json` section with your settings: trusted proxies, model provider, timezone, channels, and so on.
 
 Before deploying, verify your chart renders correctly:
 
@@ -202,13 +206,13 @@ spec:
 
 With `automated` sync enabled, ArgoCD will detect changes and deploy automatically. Any drift gets corrected.
 
-This pattern works well with [ApplicationSets](https://argo-cd.readthedocs.io/en/latest/user-guide/application-set/) too. You can have ArgoCD automatically discover and deploy any chart in the `workloads/` directory based on path patterns. For more on ArgoCD with Helm charts, see their [Helm documentation](https://argo-cd.readthedocs.io/en/stable/user-guide/helm/).
+This pattern works well with [ApplicationSets](https://argo-cd.readthedocs.io/en/latest/user-guide/application-set/) too. You can have ArgoCD automatically discover and deploy any chart in the `workloads/` directory based on path patterns. If you want a broader overview of managing multiple applications, the [App of Apps pattern](https://argo-cd.readthedocs.io/en/latest/operator-manual/cluster-bootstrapping/#app-of-apps-pattern-alternative) is worth looking at as well. For more on ArgoCD with Helm charts, see their [Helm documentation](https://argo-cd.readthedocs.io/en/stable/user-guide/helm/).
 
 ### Secrets Management
 
 OpenClaw needs API keys and tokens to function. How you manage these depends on your setup.
 
-If you run HashiCorp Vault (which I do), the [Vault Secrets Operator](https://developer.hashicorp.com/vault/docs/platform/k8s/vso) handles syncing secrets to Kubernetes. Store your credentials in Vault at a path like `secret/openclaw/env`, then create a VaultStaticSecret. In the umbrella chart pattern, I keep these manifests in a `crds/` directory alongside the chart. ArgoCD will apply them before the Helm release:
+If you run HashiCorp Vault (or its Linux Foundation fork [OpenBao](https://openbao.org/)), the [Vault Secrets Operator](https://developer.hashicorp.com/vault/docs/platform/k8s/vso) handles syncing secrets to Kubernetes. Store your credentials in Vault at a path like `secret/openclaw/env`, then create a VaultStaticSecret. In the umbrella chart pattern, I keep these manifests in a `crds/` directory alongside the chart. ArgoCD will apply them before the Helm release:
 
 ```yaml
 apiVersion: secrets.hashicorp.com/v1beta1
@@ -278,7 +282,7 @@ For TLS termination and DNS automation (using tools like [cert-manager](https://
 
 ### 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.
+Given that OpenClaw has shell access, reads files, and processes untrusted input, 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:
 
@@ -346,7 +350,7 @@ openclaw:
                   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.
+Make sure your CNI plugin supports network policies (Calico, Cilium, etc.), otherwise the policies will be created but not enforced.
 
 ### Post-Installation: Device Pairing
 

openclaw-helm.html/conf

@@ -1,5 +1,5 @@
-title="Running OpenClaw on Kubernetes"
-description="OpenClaw is powerful but risky—shell access, untrusted input, and third-party skills create real attack surfaces. This guide covers deploying OpenClaw on Kubernetes with Helm and ArgoCD, where container isolation and network policies contain the blast radius."
+title="Deploying OpenClaw on Kubernetes with Helm"
+description="OpenClaw is powerful but risky. Shell access, untrusted input, and third-party skills create real attack surfaces. This guide covers deploying OpenClaw on Kubernetes with Helm and ArgoCD, where container isolation and network policies contain the blast radius."
 site_description="$description"
 page_title="$title"
 page_path="openclaw-helm.html"