Helm Chart Checklist for Enterprise Software Vendors

A practical checklist, built on years of experience helping ISVs distribute software with Helm. Learn how to build flexible, scalable charts, streamline distribution, and empower your customers to deploy your software anywhere.

Replicated Value

Replicated brings everything you need to efficiently handle the toughest requirements around delivering your app to your customers. Our platform is designed around the needs of your organization to help simplify complex tasks. Don’t try to build all these capabilities yourself! Instead reduce your effort and cost with a trusted solution.

Need help implementing these Enterprise Helm best practices? Replicated has you covered with ChartSmith.ai, an AI agent designed to guide you every step of the way.

Introduction

At Replicated, we’ve been helping Independent Software Vendors (ISVs) distribute their software into customer-managed environments for over a decade. Over the years, we have carefully evaluated and recommended technologies that provide long-term value. Helm, which we began supporting in 2020, has continued to be the essential package manager for Kubernetes. It simplifies deployment, management, and versioning of applications using reusable, configurable Charts, making it a key tool for distributing enterprise software.

This checklist outlines Helm best practices we’ve developed while working with software vendors. It provides recommendations on structuring flexible, scalable charts, strategies for distributing them, and guidance on training customers to use your software effectively. Technical leaders in enterprise self-hosted software will find this a valuable resource for improving their Helm charts or setting them up for the first time.

Prerequisites

This checklist will be most useful to technical leaders with:

Strong Kubernetes knowledge  (Pods, Deployments, Services, ConfigMaps, Secrets, etc.)

Familiarity with YAML syntax and validation

Medium-level experience with Helm  (creating and editing charts, customizing YAML files)

Replicated has created a sample Helm Chart for a sample app, MLFlow, that follows these best practices. It can be explored in this repo and is referenced in many of our best practices below. Keep in mind this is an example application, and should be used for inspiration and direction.

Section 1:
Enterprise Helm Chart High Level Architecture Considerations

Distributing Helm charts efficiently ensures smooth installation and maintenance. This section provides best practices for packaging and securely storing charts.

Best Practices for Distributing Helm Charts

1. Distribute a Single Chart

Whenever possible, provide a single, comprehensive chart to simplify installation and upgrades. However, balance this with maintaining clarity and modularity.

Link to Example in MLFlow Helm Chart

A Helm Story - Moving from Many Charts to One

A fast-growing enterprise AI company was struggling to manage its deployments across cloud and on-prem environments. Their DevOps team maintained multiple Helm charts for different services, leading to redundant configurations, versioning conflicts, and inconsistent deployments for their customers. Recognizing the inefficiencies, they turned to the Replicated team for guidance. With expert support, they consolidated everything into a single, well-structured Helm chart, streamlining deployments and ensuring a more consistent installation experience. This shift not only reduced maintenance overhead but also improved scalability, allowing them to deliver updates faster and with greater confidence across all their enterprise environments.

2. Avoid Bundling Infrastructure Dependencies

Do not package infrastructure components like Istio or Rook within your Helm chart. Instead, allow users to manage these dependencies separately to reduce complexity and increase flexibility. If it is necessary to provide these components, distribute them as distinct charts separate from your application chart.

3. Evaluate Dependencies for Enterprise Readiness

Before adopting an upstream Helm chart, assess its maintenance status, community trust, and upgrade process. For instance, the Bitnami PostgreSQL chart may require manual intervention during routine database updates, introducing challenges in production environments. In such cases, consider whether an operator-based approach would better manage complex dependencies like databases. Additionally, be aware that Helm charts requiring cluster-level access can face installation difficulties in shared Kubernetes clusters with restricted permissions.

4. Understand Customer Constraints for Operators

Although operators can simplify managing complex dependencies, they often require cluster-wide permissions, which may not align with environments where applications are restricted to a single namespace. Some customers enforce strict namespace isolation, limiting the ability to deploy Custom Resource Definitions (CRDs) or manage resources beyond their scope. When using an operator-based approach, consider whether it supports namespace-scoped deployments or requires elevated permissions. Additionally, document and manage the CRD lifecycle explicitly, as Helm does not upgrade CRDs automatically. Provide clear guidance on how users should handle CRD updates manually to avoid version mismatches or deployment issues. Ensuring your chart accommodates these constraints improves usability in shared and restricted environments.

5. Choose the Right Storage Strategy

Use OCI-based registries for Helm chart distribution to take advantage of standardized tooling and improved integration with container workflows. They support features like access control, audit logging, and chart signing, providing stronger security out of the box compared to traditional HTTP-based repositories. Charts stored in OCI registries can also benefit from existing image scanning and policy enforcement tools already used for container images. Beyond security, OCI registries simplify chart lifecycle management, enabling consistent promotion workflows and reducing the need for separate infrastructure.

Section 2:
Implementation Examples For Enterprise-Ready Helm Charts

Distributing Helm charts efficiently ensures smooth installation and maintenance. This section provides best practices for packaging and securely storing charts.

Best Practices for Writing Helm Charts

1. Add Labels and Annotations

Labels and annotations are essential for Kubernetes tooling (e.g. Velero, Prometheus) and policy enforcement (e.g. Gatekeeper). Ensure your Helm charts include appropriate labels and annotations to align with organizational requirements.

Link to Example in MLFlow Helm Chart

3. Make the Security Context Configurable

Security policies vary across environments. Providing configurable security contexts (e.g., runAsUser, fsGroup) helps users comply with platform-specific security constraints such as OpenShift’s non-root user enforcement.

Link to Example in MLFlow Helm Chart

4. Make Scheduling and Node Affinity Configurable

Allow users to set node selectors, affinity rules, and tolerations. This is critical to ensure that stateful applications like databases are scheduled correctly across availability zones for fault tolerance.

Link to Example in MLFlow Helm Chart

5. Make Kubernetes Services Configurable

Expose the Kubernetes Service type (e.g. LoadBalancer, NodePort) as a configurable parameter. In environments with network restrictions, compliance requirements, or specific infrastructure constraints, users may need to adjust the service type to ensure their deployment functions correctly. Providing this flexibility allows deployments to adapt to different cloud providers, on-premises setups, and security policies without requiring manual modifications to the deployment manifests.

Link to Example in MLFlow Helm Chart

6. Make Ingress Configurable

Ingress settings should be configurable, allowing users to define the ingress class, annotations, and TLS settings. This flexibility ensures compatibility with different ingress controllers, enables custom routing and security policies, and supports secure access control based on specific deployment needs.

Link to Example in MLFlow Helm Chart

7. Allow Referencing Existing Kubernetes Objects

Enable referencing existing Secrets, ServiceAccounts, and PersistentVolumeClaims (PVCs) to support pre-configured infrastructure. This flexibility allows users to either specify values directly—such as providing S3 credentials via values—or reference an existing Secret. Using an existing Secret can be beneficial for standardizing secret management across the cluster, ensuring consistency, and reusing credentials across multiple services and tools.

Link to Example in MLFlow Helm Chart

8. Use Helper Functions

Define reusable templates for labels, annotations, and common values to maintain DRY (Don’t Repeat Yourself) principles and ensure consistency across charts. Note if these are long you may also break them up into multiple files beginning with an underscore per Helm’s Named Templates documentation.

Link to Example in MLFlow Helm Chart

Section 3:
Helping Users Install Your Charts Successfully

Ensuring customers can install and maintain your Helm chart is just as important as creating and distributing it. Providing proper documentation with clear instructions improves the user experience.

Best Practices for Supporting Users

1. Maintain Comprehensive Documentation

A well-structured README should explain installation, configuration, and upgrade steps. Automate documentation updates to stay in sync with chart changes.

Link to Example in MLFlow Helm Chart

2. Support Air-Gapped Installations

Provide offline installation instructions, including mirroring images and dependencies for environments without direct internet access.

A Helm Story - Supporting Air Gap For the Most Security Conscious Customers

A fintech company providing risk analysis software to large banks struggled with deployments in air-gapped environments, where strict security policies prohibited external dependencies. Their Helm charts required internet access, leading to failed installations and slow onboarding for their banking customers. To solve this, they reconfigured their charts to support fully air-gapped deployments, bundling all necessary images and dependencies while enabling offline configuration. This ensured seamless, compliant installations, allowing banks to deploy critical financial software without security concerns or operational delays.

3. Use Preflight Checks to Prevent Failures

Use tools during preflight (before releasing your Helm charts) to verify environmental prerequisites and reduce troubleshooting overhead. See Troubleshoot.sh docs for an example.

Conclusion

By following these best practices, enterprise software vendors can create well-structured, flexible, and secure Helm charts that simplify deployment for their customers. Ensuring clear documentation, proper packaging, and effective distribution strategies helps users successfully adopt and manage Helm-based applications in customer-managed Kubernetes environments. Make sure to explore our sample Helm chart, for MLFLow, that follows these best practices here.

If you’d like to speak with the Replicated team about offering your application in self-hosted environments, don’t hesitate to reach out.

Need help implementing these Enterprise Helm best practices? Replicated has you covered with ChartSmith.ai, an AI agent designed to guide you every step of the way.

Explore the Replicated Platform

See how Replicated supports every piece of the Software Distribution Lifecycle.

Learn more

Ready to get started?

Get a demo Try for free

Helm Chart Checklist for Enterprise Software Vendors

Replicated Value

Need help implementing these Enterprise Helm best practices? Replicated has you covered with ChartSmith.ai, an AI agent designed to guide you every step of the way.

Introduction

Prerequisites

This checklist will be most useful to technical leaders with:

Replicated has created a sample Helm Chart for a sample app, MLFlow, that follows these best practices. It can be explored in this repo and is referenced in many of our best practices below. Keep in mind this is an example application, and should be used for inspiration and direction.

Section 1: Enterprise Helm Chart High Level Architecture Considerations

Distributing Helm charts efficiently ensures smooth installation and maintenance. This section provides best practices for packaging and securely storing charts.

Best Practices for Distributing Helm Charts

1.

Distribute a Single Chart

A Helm Story - Moving from Many Charts to One

2.

Avoid Bundling Infrastructure Dependencies

3.

Evaluate Dependencies for Enterprise Readiness

4.

Understand Customer Constraints for Operators

5.

Choose the Right Storage Strategy

Section 2: Implementation Examples For Enterprise-Ready Helm Charts

Distributing Helm charts efficiently ensures smooth installation and maintenance. This section provides best practices for packaging and securely storing charts.

Best Practices for Writing Helm Charts

1.

Add Labels and Annotations

3.

Make the Security Context Configurable

4.

Make Scheduling and Node Affinity Configurable

5.

Make Kubernetes Services Configurable

6.

Make Ingress Configurable

7.

Allow Referencing Existing Kubernetes Objects

8.

Use Helper Functions

Section 3: Helping Users Install Your Charts Successfully

Ensuring customers can install and maintain your Helm chart is just as important as creating and distributing it. Providing proper documentation with clear instructions improves the user experience.

Best Practices for Supporting Users

1.

Maintain Comprehensive Documentation

2.

Support Air-Gapped Installations

A Helm Story - Supporting Air Gap For the Most Security Conscious Customers

3.

Use Preflight Checks to Prevent Failures

Conclusion

Need help implementing these Enterprise Helm best practices? Replicated has you covered with ChartSmith.ai, an AI agent designed to guide you every step of the way.

Explore the Replicated Platform

Learn more

Testing Releases in Customer-representative Environments

Announcing: The Commercial Software Distribution Handbook

Helm alone is not enough (for commercial software distribution)

Ready to get started?

Company

Projects

Developers

Find Us On

Subscribe to our newsletter

Need help implementing these Enterprise Helm best practices? Replicated has you covered with ChartSmith.ai, an AI agent designed to guide you every step of the way.

Section 1:
Enterprise Helm Chart High Level Architecture Considerations

Section 2:
Implementation Examples For Enterprise-Ready Helm Charts

Section 3:
Helping Users Install Your Charts Successfully

Need help implementing these Enterprise Helm best practices? Replicated has you covered with ChartSmith.ai, an AI agent designed to guide you every step of the way.