Helm In Production Without The Guesswork
Charts, releases, and safer upgrades for teams that like sleep
Why Helm Still Earns A Place In Our Toolbox
We’ve all met the “just use raw YAML” argument. It usually appears right after someone has copy-pasted the same Deployment into six folders and called it simplicity. Raw manifests absolutely have their place, but once we start managing environments, versioning releases, and passing work between teams, Helm becomes less of a luxury and more of a sensible bit of kit.
At its core, helm is a package manager for Kubernetes. It gives us a way to bundle manifests into charts, parameterise them with values, and install them as versioned releases. That sounds tidy on paper, but the practical win is consistency. Instead of every service inventing its own folder structure and naming scheme, we get a repeatable deployment model that operators and developers can both follow without needing a treasure map.
We also like helm because it fits nicely with the rest of the ecosystem. It works well with common CI/CD flows, supports chart repositories, and gives us built-in commands for rendering, diffing, upgrading, and rolling back. In other words, it helps reduce the number of “who changed this at 4:57 p.m. on Friday?” conversations.
That said, helm isn’t magic. It won’t rescue a badly designed application, and it can absolutely become a mess if we cram every possible toggle into values.yaml. The goal isn’t to make Kubernetes disappear. The goal is to manage complexity without adding a fresh layer of chaos. Used well, helm gives us standard packaging, safer changes, and fewer one-off deployment surprises. Used badly, it gives us 900 lines of templating and a strong desire to go outside.
The Building Blocks: Charts, Templates, And Values
To use helm well, we need to understand its three main moving parts: charts, templates, and values. A chart is the package. It contains metadata, default configuration, and the Kubernetes resource templates that become actual manifests when rendered. Think of it as the deployable blueprint for an application or platform component.
Inside a chart, the templates/ directory holds manifest files written with Go templating. These templates let us substitute values, loop over lists, and include reusable snippets. That flexibility is helpful, but we’ve learned to keep it on a leash. If every resource is wrapped in nested conditionals and custom helpers, we end up building a tiny programming language that nobody wants to debug at 2 a.m.
Then we have values.yaml, which is where helm shines for day-to-day use. Values let us define defaults and override settings per environment, per team, or per deployment. Instead of forking manifests for dev, test, and production, we can keep one chart and vary only the configuration that needs to change. This is especially useful when paired with a Git-driven workflow and clear review rules.
A very small chart structure might look like this:
myapp/
Chart.yaml
values.yaml
templates/
deployment.yaml
service.yaml
ingress.yaml
A simple Chart.yaml could be:
apiVersion: v2
name: myapp
description: A sample application chart
type: application
version: 0.1.0
appVersion: "1.2.3"
The official chart template guide is worth bookmarking, and so is the chart best practices section. We’d also recommend reading the Kubernetes recommended labels guide, because good labels save more time than flashy dashboards ever will.
A Practical Workflow For Creating And Shipping Charts
When we start a new chart, we try very hard not to begin by writing clever templates. Instead, we begin with the boring questions: what resources do we need, what configuration truly varies, and what should remain fixed? This keeps the chart focused and prevents us from creating a Swiss Army knife when all we needed was a screwdriver.
A common starting point is helm create, which scaffolds a chart quickly:
helm create myapp
tree myapp
helm lint myapp
helm template myapp ./myapp
This gives us a working baseline, but we usually trim it down straight away. The generated files are helpful as examples, not as sacred text. If we don’t need autoscaling yet, we remove it. If the default helpers are overkill, we simplify them. Teams often keep too much boilerplate and then complain that helm is complicated. Helm isn’t always the problem; our reluctance to delete things often is.
From there, we render the chart locally with realistic values and inspect the output before ever touching a cluster. helm template is one of those commands that quietly saves us from embarrassment. It lets us catch naming mistakes, missing values, and weird indentation issues without turning the cluster into a test harness.
Once the chart is ready, we package and publish it to a chart repository or OCI registry. OCI support has made distribution cleaner, especially when we already use container registries in the estate. The OCI artifacts docs are useful here, and if we’re automating checks in pipelines, chart-testing is a handy tool for linting and installation tests. For schema validation of rendered manifests, kubeconform also earns its keep.
Values Management Without Turning values.yaml Into A Junk Drawer
If there’s one area where helm projects drift into nonsense, it’s values management. We’ve seen values.yaml files that look like tax returns: technically complete, emotionally exhausting, and understood by nobody. The trick is to separate what users genuinely need to change from what chart authors are merely nervous about hardcoding.
A healthy values file has sensible defaults, clear naming, and a small number of top-level sections. We like patterns such as image, resources, service, ingress, and env. We avoid exposing every field from every Kubernetes object unless there’s a real use case. If we make every knob configurable, we haven’t designed a chart; we’ve outsourced decision-making.
Here’s a compact example:
replicaCount: 2
image:
repository: ghcr.io/example/myapp
tag: "1.2.3"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 8080
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
ingress:
enabled: true
className: nginx
host: myapp.example.com
For environment-specific overrides, we prefer separate files such as values-dev.yaml and values-prod.yaml, then install with -f. That keeps defaults clean while making drift visible in Git. We also strongly recommend validating values with a JSON schema via values.schema.json, which helm supports nicely. It’s one of the easiest ways to stop bad input before it becomes bad YAML.
If we’re storing sensitive data, we don’t put secrets in plain values files and hope people behave. Tools like External Secrets Operator or SOPS with Git workflows are far better choices. Helm is a deployment tool, not a diary for credentials.
Upgrades, Rollbacks, And The Art Of Not Breaking Friday
The nicest thing about helm in production is that it gives us a structured way to change running applications. The second nicest thing is rollback. That feature alone has rescued many teams from the dreaded “quick patch” that became a long evening. Kubernetes can already reconcile resources, of course, but helm adds release history and a clearer operational workflow around upgrades.
Our standard path is simple: render first, lint second, upgrade with care, and use --atomic when the chart and workload support it. That flag tells helm to roll back automatically if the upgrade fails, which is a lovely feature when we’d rather not manually unwind a half-finished deployment.
A typical deployment flow looks like this:
helm lint ./myapp
helm template myapp ./myapp -f values-prod.yaml > rendered.yaml
helm upgrade --install myapp ./myapp \
--namespace production \
--create-namespace \
-f values-prod.yaml \
--atomic \
--history-max 10
When things do go wrong, release history helps us move quickly:
helm history myapp -n production
helm rollback myapp 12 -n production
helm status myapp -n production
We also like the helm diff plugin because previewing change is far better than explaining surprise. In GitOps setups, helm often sits behind tools such as Argo CD or Flux, where the same principles still apply: keep changes visible, scoped, and reversible.
One small warning: rollback isn’t a time machine for stateful systems. If a chart update includes database changes, persistent volume shifts, or destructive hooks, helm can’t magically unspill the milk. It will help with release management, but we still need application-aware migration plans and a healthy respect for irreversible operations.
Common Helm Mistakes We Keep Seeing
Helm is straightforward until we humans get involved. Then things become creative. One common mistake is treating charts as giant abstraction layers instead of deployment packages. When a chart tries to support every possible workload pattern, cloud provider, and operating mood, it becomes impossible to maintain. A chart should solve a clear deployment problem, not become a platform religion.
Another frequent issue is over-templating. Just because helm can template almost any field doesn’t mean it should. We’ve seen charts with conditionals inside conditionals, helper templates that call other helper templates, and naming logic that requires archaeology. When templates become harder to read than the rendered YAML, we’ve lost the plot.
We also run into weak defaults. If the chart installs but omits resource requests, health probes, or useful labels, we’ve shipped something technically functional and operationally annoying. Good charts encode sane defaults and encourage good Kubernetes behaviour. They don’t make users remember every best practice from memory.
Versioning gets muddled too. Chart version and app version are not the same thing, and mixing them casually creates confusion during audits and upgrades. We keep chart changes versioned according to packaging changes, while appVersion reflects the application being deployed. Boring? Yes. Helpful later? Very much yes.
Then there’s the “secrets in values files” classic, which deserves to retire immediately. We mentioned better options earlier because plaintext secrets in Git are still a bad idea, even if the repo is called private-prod-final-v2-real. Finally, many teams skip testing rendered manifests against cluster policies. Tools like OPA Gatekeeper and Kyverno are wonderful, but only if we validate before production teaches us a lesson with perfect timing.
Where Helm Fits With GitOps And Team Standards
Helm works best when it’s part of a broader operating model rather than a lone command somebody runs from a laptop named after a superhero. We like to pair helm with GitOps-style practices because they make intent visible. The chart, the values, and the release changes all live in version control, and the path to production becomes easier to review, reason about, and audit.
In a team setting, this matters more than the templating itself. Helm gives us a common packaging format, but standards give it real value. We want agreed naming conventions, labels, annotations, resource defaults, and release rules. We also want charts to look similar across services so that any engineer can step in without needing a local legend. Familiarity reduces mistakes, and it also reduces drama, which is a metric we quietly care about.
A sensible model is to maintain shared starter charts or common library charts for repeated patterns, then let application teams supply their own values. Helm library charts can be useful here, though we try not to build an elaborate hierarchy unless there’s a clear maintenance benefit. Reuse is good; inheritance-based confusion is less charming.
GitOps controllers can render helm charts directly or consume already-rendered manifests, depending on the approach we prefer. Either way, we still review values changes carefully, test rendered output, and keep environment differences explicit. The Argo CD Helm docs and Flux Helm controller docs are solid references if we’re heading that route.
In the end, helm fits best as a standard deployment layer: not the whole platform, not a substitute for good engineering, just a reliable way to package and operate Kubernetes applications with less improvisation and fewer Friday surprises.
