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)
Let’s be honest. A production SPA is usually just an nginx container serving static files. No database migrations. No stateful sets. No persistent volumes.
The "Vanilla YAML" setup looks like this:
yaml
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-spa
spec:
replicas: 3
selector:
matchLabels:
app: my-spa
template:
metadata:
labels:
app: my-spa
spec:
containers:
- name: nginx
image: nginx:alpine
ports:
- containerPort: 80
service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-spa-svc
spec:
selector:
app: my-spa
ports:
- port: 80
That’s it. Copy that into your CI/CD pipeline, run kubectl apply -f, and go home.
Why Helm feels like overkill here:
Cognitive load: You now have to explain Go templating to junior devs who just want to fix a button color.
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)
You might be thinking, "But I only have one SPA!"
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
values/staging.yaml
replicaCount: 1
image:
tag: latest
ingress:
host: staging.myapp.com
values/prod.yaml
replicaCount: 5
image:
tag: v1.2.3
ingress:
host: myapp.com
helm install -f values/prod.yaml is a beautiful thing.
- 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
Scenario Use Helm? Why
Personal portfolio / hobby cluster No Just use kubectl apply or Kustomize. Helm adds friction without value.
Startup with 2 environments Maybe If you manually copy-paste YAML across dev/staging/prod, switch to Helm today.
Enterprise with 50+ microservices Yes Standardizing on Helm (even for SPAs) reduces "snowflake" infrastructure. Your Ops team will thank you.
You use ArgoCD Yes ArgoCD loves Helm charts. It gives you a UI to see exactly which values changed between deploys.
A Better Alternative: Helm + Raw Manifest
You don't have to use all of Helm's features.
Don't do this:
go
{{ if .Values.ingress.enabled }}
{{ include "my-spa.ingress" . }}
{{ end }}
Do this instead:
Keep your chart stupidly simple. Use a flat templates/ directory with minimal logic, and use values.yaml only for:
image.tag
replicaCount
ingress.host
Keep your helpers empty.
The "Golden Path" for SPAs
Here is the pragmatic rule:
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
yaml
values.yaml
replicaCount: 2
image:
repository: myregistry/spa
tag: latest
pullPolicy: IfNotPresent
service:
port: 80
ingress:
enabled: true
host: app.mycompany.com
tls:
- secretName: myapp-tls
yaml
templates/deployment.yaml (Condensed)
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-spa
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ .Release.Name }}
spec:
containers:
- name: nginx
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: {{ .Values.service.port }}
Final Takeaway
Is Helm worth it for a simple SPA?
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! 🚢