.png)
Helm has become the de facto tool for packaging Kubernetes applications. But when it comes to shipping commercial software into enterprise environments, using Helm “as-is” isn’t enough.
In a recent Replicated Deep Dive, Helm maintainers and enterprise deployment experts shared hard-won guidance on making Helm charts enterprise-ready. This wasn’t about theory — it was about real software running in real customer environments, and the decisions vendors must make to meet enterprise expectations.
This post unpacks the best practices discussed in that session, why they matter, and how vendors can apply them. A recording of the session is below.
Enterprise-Ready Helm Is Complex
Most vendors start with Helm to support SaaS delivery — but exporting those charts into enterprise environments introduces new constraints. Making Helm enterprise-ready means:
- Writing configurable, modular charts
- Anticipating air-gapped, restricted, and regulated deployments
- Separating infrastructure from application configuration
- Supporting orchestration across multiple charts
- Documenting and simplifying values for real operators
It Starts With the Chart: Write It Right
Enterprise readiness begins with fundamentals. If your Helm chart makes assumptions about your SaaS infrastructure — hardcoded image paths, baked-in labels, single-namespace design — you’ll hit friction immediately when deploying into customer clusters.
“Step one is just writing the chart the right way. A lot of folks assume what worked in their SaaS setup will work for customers — it won’t.” — Evans Mungai, Replicated
Make images configurable. Expose security context settings. Allow flexibility for annotations, tolerations, and node selectors. These are not just nice-to-haves; they’re required in enterprise environments.
Labels, Annotations, and the Cost of Missing Metadata
In SaaS environments, labels might be optional. Not so in enterprise. Large customers rely on structured metadata to manage their infrastructure at scale.
“In a big bank, if a pod misbehaves, they need to know who owns it — labels aren’t optional, they’re operational tooling.” — Chuck D’Antonio, Replicated
Every chart should support required labels and annotations as configuration, not assumptions. When vendors ignore this, customers are forced to hack workarounds — or worse, walk away.
Exposing the Right Values — and Only the Right Values
Helm’s power lies in configuration. But complexity can overwhelm.
“Your values file shouldn't scroll forever. Most users only want to touch the 5–10 things that matter.” — Scott Rigby, Helm Maintainer
Vendors should:
- Separate platform config (e.g., node affinities) from app-level settings
- Provide example values files for common scenarios
- Use global values in umbrella charts to centralize config
- Avoid unnecessary value sprawl by supporting overlays or post-renderers for advanced needs
When you expose too much, users are confused. When you expose too little, they’re blocked. Balance matters.
Beyond One Chart: Helm Doesn’t Orchestrate for You
Commercial applications rarely consist of a single Helm chart. Supporting multiple services — often built by different teams — means orchestrating their install, upgrade, and configuration lifecycle.
“Enterprise vendors often realize too late that they need orchestration. Helm can’t sequence your components. You’ll need umbrella charts or external tools.” — Evans Mungai, Replicated
Umbrella charts work when you control all subcharts and need centralized values. But they break down when services span namespaces or depend on pre-existing infrastructure.
Helmfile, Replicated’s Embedded Cluster, and CD tools like Argo or Flux can help coordinate sequencing and shared config. Just don’t expect helm install to be enough for multi-service delivery.
Security, Secrets, and Environmental Flexibility
Enterprise customers bring their own secrets — literally. Credentials, TLS certs, and connection strings are often provisioned externally via secret managers or security platforms.
“Don’t hardcode secrets. Assume they’re managed elsewhere, and let users reference them.” — Scott Rigby, Helm Maintainer
Make your charts work with pre-created secrets. Avoid assuming you’ll create all infrastructure. Let advanced customers inject configuration through existing systems. That flexibility can be the difference between an eval and a deployment.
The Path Forward: Helm 4 and What’s Coming
Helm 4 is on the horizon, with a focus on improving usability and configurability. The maintainers are exploring tools like yaml-script to offer simpler alternatives to deeply nested Go templates, and there's interest in making values files less intimidating for end users.
“We know values files are a problem. Helm 4 is looking at ways to make that better — but for now, vendors have to carry that complexity thoughtfully.” — Scott Rigby, Helm Maintainer
Want to shape Helm’s future? Helm 4 pre-releases are expected in August — early feedback is welcome.
Conclusion: Making Your Helm Charts Enterprise-Ready
Shipping Helm charts to enterprise customers is about more than packaging. It’s about anticipating how your software will land in unfamiliar environments — and helping customers succeed, not just install.
That means clean charts, sensible defaults, flexibility for infrastructure variance, and support for real-world orchestration. Helm gives you the tools. Replicated and the community can help you use them well.
If you’re building Helm charts for enterprise delivery, we’d love to help. Reach out to learn how Replicated supports commercial vendors in every step of the Helm journey.