Helm Charts for a Simple SPA: Over-Engineering or Smart DevOps?

Source: Dev.to

Ah, the Single Page Application (SPA). You’ve built it in React, Vue, or Svelte. You’ve run npm run build, and out pops a dist/ folder containing a few .js, .css, and an index.html. Now comes the boring part: Getting it onto a Kubernetes cluster. You have two options: Write a simple Deployment and Service YAML file (maybe 30 lines total). Scaffold a full Helm chart with values.yaml, _helpers.tpl, and templates/. Is Helm worth it for a static file server? Let’s break down the dogma from the reality. The Case Against Helm (The “KISS” Principle) The “Vanilla YAML” setup looks like this: yaml apiVersion: apps/v1 apiVersion: v1 Why Helm feels like overkill here: The “Hello World” paradox: Your chart ends up being 90% boilerplate and 10% actual config. Debugging hell: helm template is cool, but kubectl describe on raw YAML is simpler. The Case FOR Helm (The “Reality” Check) Sure. For now. But let’s look at the six-month horizon. The Ingress + TLS problem Your simple SPA needs HTTPS. So you add an Ingress resource. Then you need to annotate it for your specific controller (AWS ALB, nginx, Traefik). Then you need to reference a TLS secret. Suddenly, your 30 lines of YAML become 80 lines, and you have to remember the annotation syntax for the 10th time. Environment parity (Staging vs. Production) You need Staging (with replicas: 1 and latest tag) and Production (with replicas: 5 and v1.2.3 tag). Without Helm, you either: Maintain two separate YAML folders (boring, error-prone). Use sed to replace values (brittle, 1990s style). With Helm: yaml replicaCount: 1 replicaCount: 5 The “ConfigMap Reload” trick for env.js SPAs often need runtime config (API URLs) injected into window.env. The standard pattern is: A ConfigMap holding env.js. An nginx sub_filter or a init-container to inject it. Managing that ConfigMap lifecycle (rolling update when env vars change) is annoying in raw YAML. Helm hooks and helper templates make this deterministic. The Verdict: It depends on your org size Don’t do this: go {{ if .Values.ingress.enabled }} {{ include “my-spa.ingress” . }} {{ end }} image.tag replicaCount ingress.host Keep your helpers empty. The “Golden Path” for SPAs If your SPA YAML fits on one screen (50 lines): Use raw manifests + Kustomize. If you have more than one environment (dev/staging/prod): Use Helm. If you are already using Helm for your backend APIs: Use Helm for the SPA. Consistency > Purity. Sample “Just enough Helm” Chart for an SPA replicaCount: 2 apiVersion: apps/v1 Technically: No. It’s a sledgehammer for a thumbtack. Operationally: Yes. If you value —dry-run debugging, environment parity, and not rewriting YAML. My advice: Use Kustomize as the middle ground. It gives you environment overlays without the templating headache. But if your team already speaks Helm, don’t fight it—just keep the chart boring. What’s your take? Are you running SPAs in production with raw YAML, or have you embraced the Helm whale? Feel free to adapt this post with your specific nginx config examples or CI/CD snippets. Happy shipping! 🚢