Systems Saturday 13: Helm
Fighting YAML abstractions is a losing game
If you’ve deployed anything beyond a “Hello, World” on Kubernetes, you’ve probably met Helm, the self-proclaimed package manager for Kubernetes. For years, Helm has been the default way to install complex applications, bundle manifests, and tame the sprawling YAML that comes with cluster life.
And for (somewhat) good reason: it works. Helm charts give teams a convenient way to package, version, and roll out applications with a single command. It became so standard that many open-source projects now ship their official deployments only as Helm charts.
But as the Kubernetes ecosystem has matured, Helm’s limitations have started to show. What once felt like a relief from hand-rolled manifests can, at scale, turn into a source of fragility, drift, and operational debt. Teams that begun with a few friendly helm install commands now wrestle with brittle templating, CRD upgrade issues, and mysterious chart dependencies.
This week’s Systems Saturday takes a closer look at where Helm still shines, where it falls short, and, perhaps most importantly, what alternatives are stepping up. By the end, you’ll have a clearer sense of when Helm is the right hammer for the job and when it’s just hitting the wrong nail.
Why Helm Still Matters
Before diving into the rough edges, it’s worth remembering why Helm became so dominant in the first place. For all its quirks, Helm solved a real pain point for Kubernetes users: managing the complexity of dozens (or hundreds) of YAML manifests that define even the simplest application.
1. A Package Manager for Kubernetes
Helm brought a familiar model from the Linux world into Kubernetes: charts as packages, repositories for distribution, and releases for version tracking.
Instead of copying manifests by hand, teams could now install an entire stack, an ingress controller, Prometheus, or a custom app with one simple command:
helm install myapp ./chartThat packaging model drastically lowered the barrier to entry for Kubernetes adoption.
2. Fast, Repeatable Deployments
Helm’s templating system and values.yaml file made it easy to spin up multiple environments with minimal duplication. You could deploy the same chart to dev, staging, and prod with different configurations and roll back in seconds if something broke.
For platform teams juggling multiple clusters or short-lived environments, this repeatability was (and often still is) invaluable.
3. An Ecosystem That’s Hard to Ignore
Helm’s biggest strength might actually be its ecosystem.
Most major open-source projects publish official Helm charts.
CI/CD tools, GitOps platforms, and managed Kubernetes offerings (like EKS and GKE) support Helm natively.
Many engineers already know it, which translated to less friction when onboarding or sharing internal tooling.
The result? A tool that became expected.
4. Still a Solid Default in the Right Context
For single applications, simple stacks, or teams without strict compliance or drift-management needs, Helm remains a solid, low-overhead choice. When your focus is shipping quickly and learning fast, Helm still gets you there with minimal ceremony.
The Cracks in the Armor
Helm made Kubernetes application management approachable, but as teams scale and complexity increases, its rough edges become hard to ignore. The same flexibility that made Helm attractive early on can lead to fragility, opacity, and operational pain later.
Here are some of the most common and consequential shortcomings teams run into with Helm in real-world use.
1. CRD Management Headaches
Helm’s treatment of Custom Resource Definitions (CRDs) is one of its longest-standing issues.
CRDs that live in a chart’s crds/ directory are installed once but Helm intentionally ignores them during upgrades. That means if a CRD schema changes, Helm won’t update it for you.
The implications are messy: you’re forced into manual steps, shell scripts, or brittle pre-install hooks just to keep CRDs aligned with their controllers.
In large clusters that depend on multiple operators, CRD lifecycle drift can quickly become a maintenance nightmare.
2. Dependency and Namespace Limitations
Helm supports sub-charts, but all sub-charts deploy into the same namespace as the parent release.
That design simplifies things for simple apps but becomes a blocker for multi-namespace architectures. Want to share a dependency (say, a shared database chart) across releases? You’ll often end up duplicating the same chart multiple times or, worse yet, writing orchestration glue outside Helm entirely.
The result: what started as a single command turns into a tangle of inter-dependent charts with unclear ownership.
3. Template Complexity and Readability Drift
Helm’s templating language (Go templates plus its own helpers) is powerful, but power comes at a cost.
As projects evolve, values.yaml files balloon into hundreds of lines of configuration, and templates become littered with conditionals, if blocks, and deeply nested helpers.
It’s not uncommon for engineers to lose track of what the rendered YAML actually looks like until something breaks in production. That loss of transparency undermines one of Kubernetes’s biggest advantages: declarative clarity.
4. Limited Lifecycle and Drift Awareness
Once Helm installs a release, its job is largely done. It doesn’t reconcile the cluster’s live state against the desired configuration like a controller would. If someone manually changes a resource in the cluster, Helm won’t notice. If the environment drifts, Helm can’t self-heal.
This client-side model makes Helm easy to use but ill-suited for modern GitOps or drift-aware workflows, where continuous reconciliation is key.
5. Security and Audit Challenges
Because Helm charts are distributed like software packages, not all of them are created equal. Many community charts come with insecure defaults, over-privileged service accounts, or outdated image tags.
Auditing them is tricky: the templating system hides much of the actual configuration until runtime. That opacity makes it difficult for security teams to review changes or for auditors to map manifests to chart sources. In some regulated environments, this has been enough reason to move away from Helm entirely.
6. Harder to Debug = Harder to Trust
In combination, these issues create a larger meta-problem: trust erosion.
When an upgrade fails or a deployment drifts, it’s not always clear whether the issue lies in the chart, the values, or Helm itself. The debugging process can feel full of nested templates and invisible assumptions.
For many platform teams, this lack of predictability is what ultimately pushes them to explore alternatives.
Emerging Alternatives
For all of Helm’s convenience, its design shows its age in an ecosystem that now prizes transparency, reconciliation, and composability. Fortunately, a wave of newer tools have stepped up to fill in the gaps Helm leaves behind!
Below are the most noteworthy contenders and how they differ in philosophy and execution.
1. Kustomize — Overlays, Not Templates
Kustomize ships with kubectl and takes a declarative approach: no templates, just plain YAML with layered modifications.
Instead of dynamically generating manifests, Kustomize patches existing ones using overlays.
That means:
What you see is what you deploy. The manifests in Git are exactly what end up in the cluster.
It plays beautifully with GitOps workflows, because rendered output is explicit.
Environment differences are handled cleanly through patches and bases rather than conditional logic.
Teams that value simplicity, transparency, and Git-driven deployment pipelines will love to use Kustomize.
Some tradeoffs: there’s no package concept, no built-in rollback or release tracking. Kustomize doesn’t replace Helm’s packaging ecosystem but provides a cleaner configuration layer when Helm’s templating becomes unmanageable.
2. Carvel — A Toolkit of Small, Sharp Tools
The Carvel suite (from VMware Tanzu) embraces the Unix philosophy: one tool per concern.
ytthandles YAML templating with a real programming language feel (using embedded Python-adjacent syntax).kappfocuses on deployment lifecycle, diffing, and reconciliation.Other tools handle packaging (
kbld,imgpkg, etc.).
Together, they form a flexible system that can fully replace Helm, or even integrate with it.
Carvel’s advantage lies in clarity: you can see exactly what changes before anything is applied, and kapp’s diffing model gives Helm’s “fire and forget” a serious upgrade.
It works best for teams that need strong deployment lifecycle management, deterministic diffs, and structured templating without losing transparency.
One of the downsides is that Carvel does pose a steeper learning curve and smaller ecosystem compared to Helm.
3. Timoni — Helm, Reimagined in CUE
A newer entrant, Timoni, rethinks Helm from first principles. It replaces YAML templating with the CUE language, giving you type safety, schema validation, and composable modules.
Timoni packages modules as OCI artifacts, similar to container images. This means you can push and pull deployments using existing registry infrastructure. It also integrates with GitOps models and includes built-in lifecycle and reconciliation features.
This really is best suited for engineering organizations that crave stronger validation and structure, or are already exploring CUE for configuration.
Notably, this framework is still young, has a smaller community, and less tooling maturity than Helm or Kustomize.
Closing Thoughts
Helm has earned its place in the Kubernetes story. It was the first tool to make Kubernetes feel approachable. To turn hundreds of YAML manifests into a single command, and to give developers something that looked like a package manager in a world of endless configuration files.
But as with most early solutions, Helm’s design reflects the assumptions of its time. It was built for deploying applications, not managing long-lived, continuously reconciled systems. Today’s Kubernetes environments are more dynamic, more automated, and more compliance-sensitive than ever — and that’s where Helm starts to feel like trying to fit a square peg in a round hole.
The good news? The ecosystem has evolved.
Kustomize gives us transparency and Git-friendly overlays.
Carvel adds lifecycle awareness and structured templating.
Timoni experiments with strong typing and modern packaging.
And hybrid approaches bridge the gap, proving that the answer isn’t always “ditch Helm,” but rather “use Helm more wisely.”
Helm still works but it’s not the only hammer in the toolbox anymore. If your workloads are simple, keep using it. If you’re hitting issues with CRDs, drift, or chart sprawl, start experimenting with newer tools.
Each of these alternatives reflects a different philosophy: from templating to layering, from fire-and-forget to continuous reconciliation.
Ultimately, that’s a healthy sign. The Kubernetes ecosystem is maturing beyond one-size-fits-all tooling, and Helm’s shortcomings are what pushed it there.
But, until a better alternative comes along: deploy thoughtfully, version everything, and never stop questioning the defaults.