Helm is an open-source package manager for Kubernetes that streamlines the packaging, configuration, and deployment of applications using YAML-based charts, enabling users to define, install, and upgrade even the most complex Kubernetes resources in a consistent manner.^[1] Originally developed by Deis as Helm Classic in 2015 and introduced at the inaugural KubeCon conference, it quickly became a de facto standard for managing Kubernetes applications.^[2] Helm joined the Cloud Native Computing Foundation (CNCF) as an incubating project on June 1, 2018, and achieved graduated status on April 30, 2020, reflecting its maturity and widespread adoption within the cloud native ecosystem.^[3][4] Key milestones in Helm's evolution include the release of Helm 2.0 in November 2016, which introduced Tiller—a server-side component that handled chart rendering and deployment to improve security and multi-tenancy in shared clusters.^[5] However, concerns over Tiller's security model led to its removal in Helm 3.0, released on November 13, 2019, which shifted to client-side operations for enhanced simplicity and safety while introducing features like improved chart dependencies and library charts.^[6] The most recent major update, Helm 4.0.0, arrived in November 2025 with architectural improvements such as better support for modern Kubernetes versions, enhanced performance, and refinements to the chart lifecycle, marking the project's 10-year anniversary and ensuring continued relevance in evolving cloud native environments.^[7] Today, Helm is maintained by a vibrant community under the CNCF, with its GitHub repository serving as the primary hub for contributions, and it integrates seamlessly with tools like Kubernetes for deploying production-grade applications.^[8]

History

Origins and Early Development

Helm was initially developed by Deis, a company focused on cloud-native technologies, as an open-source tool known as Helm Classic in 2015.^[9] The project aimed to simplify the management of Kubernetes applications by providing a packaging format for YAML manifests, addressing the complexities of deploying and configuring applications on Kubernetes clusters at a time when such tools were nascent. Deis officially announced Helm at the inaugural KubeCon conference in San Francisco in November 2015, marking its public debut and highlighting its potential as a key enabler for Kubernetes adoption.^[10] In its early incarnation as Helm Classic, the tool emphasized a client-side approach to packaging and deployment, operating without any server-side components to keep operations lightweight and decentralized. This design choice reflected the project's origins in solving practical deployment challenges faced by Deis in their PaaS offerings, focusing on templating and versioning Kubernetes resources directly from the user's local environment. A pivotal moment in Helm's early development occurred in January 2016, when the Deis team merged their efforts with the Kubernetes Deployment Manager, a tool originally ported from Google Cloud's internal systems to support Kubernetes application management.^[11] This merger, which took place during a collaborative meeting in Seattle, combined the strengths of both projects—Helm's packaging capabilities with Deployment Manager's deployment orchestration—resulting in Helm being brought under the broader Kubernetes project umbrella for enhanced community governance and integration.^[12] The integration solidified Helm's foundational role in the Kubernetes ecosystem while maintaining its client-centric focus during this formative phase.

Key Milestones and Versions

Helm 2.0 was released in 2016, marking a significant evolution by introducing the server-side Tiller component, which handled the deployment and management of Kubernetes applications on the cluster.^[2] This version established Helm as a more robust tool for packaging and deploying applications, building on earlier prototypes while incorporating key features like chart repositories for sharing packages.^[2] In June 2018, Helm was promoted to an incubating project under the Cloud Native Computing Foundation (CNCF), transitioning from a Kubernetes subproject to a full-fledged CNCF initiative.^[3] This milestone included the absorption of related tools such as Monocular for cataloging charts and Chart Museum for repository storage, enhancing Helm's ecosystem for discovery and distribution.^[2] Helm 3.0 arrived in November 2019, representing a major architectural shift by removing the Tiller component entirely to adopt a client-only model, which improved security and simplified operations by eliminating the need for in-cluster server deployment.^[13] This release addressed longstanding concerns about Tiller's security vulnerabilities and made Helm more lightweight and portable across environments.^[14] Helm achieved graduated status as a CNCF project in April 2020, signifying its maturity, widespread adoption, and alignment with cloud-native standards after demonstrating sustained community governance and technical excellence.^[15] In October 2020, the CNCF Artifact Hub replaced the Helm Hub, providing a unified, searchable platform for discovering and sharing Helm charts alongside other cloud-native artifacts, thereby streamlining the ecosystem beyond Helm-specific needs.^[2] Helm 4.0.0 was released in November 2025, introducing architectural improvements such as a redesigned plugin system supporting WebAssembly-based plugins and support for server-side apply, while incorporating breaking changes like deprecations from Helm 3 to enforce stricter validation and promote best practices.^[7] This version also backported select changes to the v3 series for compatibility, ensuring a smoother transition for users while advancing the project's long-term sustainability.^[16]

Overview

Purpose and Functionality

Helm is an open-source package manager designed specifically for Kubernetes, enabling users to package, install, configure, and manage applications and services on Kubernetes clusters in a streamlined manner. It functions similarly to traditional package managers like apt for Debian-based systems or Homebrew for macOS, but is tailored to handle the complexities of container orchestration by bundling Kubernetes resources into reusable units called charts. This approach allows developers and operators to deploy even complex applications consistently across environments, reducing the manual effort required for Kubernetes-native workflows.^[1][17][18] One of Helm's primary purposes is to address key challenges in Kubernetes deployments, such as the intricacies of managing extensive YAML manifests, ensuring version compatibility, and achieving repeatable installations without errors. By abstracting these details into portable packages, Helm simplifies the process of sharing and versioning applications, making it easier to collaborate on infrastructure as code and maintain consistency in production environments. For instance, it mitigates issues like configuration drift and deployment failures that often arise from hand-editing YAML files directly on clusters.^[19][20][18] At a high level, Helm's functionality revolves around a workflow that begins with packaging Kubernetes applications into charts, followed by deploying them as releases on a cluster, and supporting lifecycle operations such as upgrades, rollbacks, and deletions. This enables efficient management of application lifecycles, allowing teams to test changes in staging before promoting them to production, all while preserving the ability to revert to previous states if needed. Components like charts and releases form the basis of this process, providing a structured way to parameterize and instantiate deployments.^[1][17][19]

Core Concepts

Helm's core concepts revolve around three primary building blocks: charts, releases, and repositories, which together enable the packaging, deployment, and distribution of Kubernetes applications. A chart in Helm is a collection of files organized into a logical package that defines a set of Kubernetes resources, such as Deployments, Services, and ConfigMaps, primarily using YAML manifests. These charts serve as templates that can be parameterized for customization, allowing users to encapsulate complex application configurations into reusable artifacts that simplify deployment across different environments. For instance, a chart might include all the necessary YAML files to deploy a web application stack, including its database and load balancer components.^[21] A release represents an instance of a deployed chart within a Kubernetes cluster, functioning as a named deployment with its own configuration values and revision history. Each release is uniquely identified by a name chosen by the user and maintains a record of changes over time, enabling operations like upgrades, rollbacks, and inspections without affecting other deployments. This concept allows multiple instances of the same chart to run concurrently in a cluster, each tailored to specific needs.^[22] Repositories act as centralized stores for hosting and distributing Helm charts, facilitating discovery and sharing among users and organizations. They function similarly to package registries in other ecosystems, where charts can be indexed, versioned, and retrieved via Helm's command-line interface. Public repositories, such as Artifact Hub, provide access to a wide array of community-contributed charts for common applications like databases and monitoring tools.^[22]

Architecture

Charts

In Helm, a chart serves as the fundamental packaging unit for Kubernetes applications, encapsulating all necessary resources and configurations into a distributable format.^[23] This structure allows developers to define, version, and share complex deployments as a single entity, promoting reusability and consistency across environments.^[23] The directory structure of a Helm chart is hierarchical and well-defined, consisting of key files and subdirectories that organize metadata, configurations, and templates. At the root, the Chart.yaml file contains essential metadata such as the chart's name, version, description, and dependencies, which Helm uses to identify and manage the package.^[23] Accompanying this is the values.yaml file, which provides default configuration values that can be overridden during installation to customize the deployment.^[23] The templates/ directory holds YAML template files for Kubernetes resources like Deployments, Services, and ConfigMaps, written using Go's templating engine to enable dynamic generation based on the provided values.^[24] Finally, the charts/ subdirectory stores any dependent charts, known as subcharts, allowing for modular composition of larger applications.^[23] Helm values are merged from multiple sources in a specific order of precedence (last source wins for conflicting keys), allowing layered configurations: The sources in order of increasing specificity:

• The chart's own values.yaml file: provides default values.
• If a subchart, values from the parent chart's values.yaml (nested under the subchart name).
• User-supplied values files passed via -f / --values flags to helm install/upgrade (multiple files allowed; later files override earlier ones).
• --set / --set-string parameters on the command line (highest precedence, can override nested values).

For example: helm install my-release ./mychart -f base-values.yaml -f prod-values.yaml --set image.tag=v1.2.3 This enables a best-practice pattern of layered values files:

• Maintain a minimal base.yaml (or chart's values.yaml) with shared defaults.
• Use environment-specific override files (e.g., dev.yaml, prod.yaml) that only specify differing values.
• This reduces duplication and drift across environments.

Values files are plain YAML, and Helm performs a deep merge. To delete a key from defaults, override it to null. (Source: https://helm.sh/docs/chart_template_guide/values_files/) Helm employs the Go templating engine, specifically the Sprig library, to process templates within the templates/ directory, substituting variables and applying logic to produce valid Kubernetes manifests.^[24] This templating system supports functions for conditionals, loops, and value manipulations, ensuring that charts can adapt to different scenarios without manual editing of YAML files. For instance, a Deployment template might use {{ .Values.replicaCount }} to insert the number of replicas from values.yaml.^[24] Charts support dependencies to incorporate external functionality, declared in the dependencies field of Chart.yaml with details like repository URLs and version constraints.^[23] These dependencies are resolved and packaged into the charts/ directory as subcharts during chart building, enabling a parent chart to leverage reusable components like databases or ingress controllers while maintaining isolation through scoped values.^[25] Subcharts inherit global values from the parent but cannot directly access its non-global values, promoting encapsulation and preventing unintended overrides.^[25]

Releases

In Helm, a release represents the deployed instance of a chart within a Kubernetes cluster, encapsulating the resources and configuration applied during installation. The release lifecycle begins with installation, where the helm install command renders the chart's templates and creates the corresponding Kubernetes resources, such as deployments, services, and config maps, in the specified namespace.^[22] This process tracks the release's state, enabling subsequent management operations throughout its lifecycle.^[26] Upgrades modify an existing release by applying changes to the chart or its values using the helm upgrade command, which updates resources incrementally while preserving the release's history for potential reversions. Rollbacks revert a release to a previous revision via helm rollback, restoring the cluster state from a prior successful deployment and ensuring minimal disruption. Uninstalling a release with helm uninstall removes all associated Kubernetes resources and deletes the release record, effectively ending its lifecycle.^[22] These operations leverage chart hooks—predefined lifecycle events like pre-install, post-upgrade, and pre-rollback—to execute custom actions, such as database migrations or validations, at key points.^[26] Since Helm 3, release history and metadata are stored directly in Kubernetes objects within the release's namespace—by default as Secrets, or as ConfigMaps if configured with the --storage-driver=configmap flag. This eliminates the need for a separate server-side component and enhances security by leveraging Kubernetes' native authorization mechanisms.^[14] Both Secret and ConfigMap objects are subject to a Kubernetes-imposed practical size limit of approximately 1 MiB per object, which applies to Helm's storage of compressed and base64-encoded release manifests. There is no difference in size limits between the two drivers.^[27][28] In contrast, Helm 2 relied on Tiller, a server-side component deployed in the cluster that handled release management but introduced security risks due to its elevated privileges; Tiller was removed in Helm 3 to simplify the architecture and align with modern Kubernetes security practices.^[29] This shift allows the Helm client to interact directly with the Kubernetes API, storing each release version as an annotated object for persistence and retrieval during operations like upgrades or rollbacks.^[30] Releases are instantiated from charts, which serve as the packaging blueprint defining the templated resources that Helm deploys.^[22]

Repositories

Helm repositories serve as centralized locations for storing, sharing, and accessing Helm charts, enabling users to discover and deploy pre-packaged Kubernetes applications efficiently. These repositories function as catalogs that index charts, allowing Helm to fetch and install them via simple commands, which streamlines the distribution process across teams and organizations. There are several types of Helm repositories to accommodate different use cases. Local repositories are file-based and stored directly on the user's filesystem, ideal for development or offline environments where charts are managed without network access. Remote repositories, hosted on HTTP/HTTPS servers such as Chart Museum or other OCI-compatible registries, provide scalable, web-accessible storage for sharing charts over the internet or private networks. Additionally, public hubs like Artifact Hub act as community-driven aggregators that index charts from multiple sources, offering a searchable interface for discovering verified and popular packages. Helm provides dedicated commands to manage repositories, facilitating their addition, updating, and indexing. The helm repo add command allows users to register a new repository by specifying its name and URL, for example, helm repo add bitnami https://charts.bitnami.com/bitnami, which configures Helm to pull from that location. To keep repositories current with the latest chart versions, the helm repo update command refreshes the local index cache by downloading updated metadata from remote sources. For creating or maintaining a repository, the helm repo index command generates an index.yaml file that lists available charts, ensuring proper cataloging and versioning information is available for clients. Repositories play a crucial role in chart discovery and versioning by maintaining structured metadata that supports semantic versioning (SemVer), allowing users to specify exact versions or ranges during installation, such as helm install myapp bitnami/mysql --version 9.0.0. This versioning ensures reproducibility and compatibility, as repositories track dependencies and updates, reducing the risk of deploying incompatible charts. Public repositories like Artifact Hub further enhance discovery by providing search filters, ratings, and security scans, helping users identify high-quality charts from trusted maintainers.

Features

Basic Operations

Basic operations in Helm involve fundamental commands for discovering, deploying, monitoring, and removing Kubernetes applications packaged as charts. These operations form the core of Helm's package management workflow, enabling users to interact with charts from repositories or the Artifact Hub without delving into advanced templating or customization.^[31] To find available charts, users can employ the helm search command, which queries repositories or the Artifact Hub for matching packages. The helm search repo subcommand searches within locally added repositories, allowing specification of a query string and optional version constraints to filter results. For broader discovery, helm search hub targets the Artifact Hub, Helm's official chart repository, and supports options like --max-col-width to format output for readability. These search functionalities help identify suitable charts before installation.^[32][33] Installation of a chart is performed using the helm install command, which deploys a specified chart into a Kubernetes cluster as a release. The basic syntax requires a release name and chart reference, such as helm install my-release stable/nginx, but users can customize deployments with flags like --values to apply values from a YAML file for overriding default configurations. Additional options include --namespace to target a specific Kubernetes namespace and --set for inline parameter adjustments, ensuring tailored application deployments.^[34][35] Monitoring installed releases involves the helm list and helm status commands. The helm list command displays all releases in the current or specified namespace, with options like --all-namespaces for a cluster-wide view and --filter for matching specific release names using regular expressions, as well as dedicated flags like --deployed or --failed to filter by status. For detailed inspection of a single release, helm status provides comprehensive information including deployment history, Kubernetes resources, and notes from the chart, aiding in troubleshooting and verification.^[36][37] To remove a deployed release, the helm uninstall command is used, which deletes the associated Kubernetes resources and release history by default. The --keep-history option removes the Kubernetes resources but preserves the release record in Helm's data, useful for auditing purposes, while --namespace ensures operations occur in the correct scope. For more complex lifecycle management, such as upgrades or rollbacks, users can refer to advanced capabilities.^[38]

Advanced Capabilities

Helm provides advanced mechanisms for managing and updating deployments, including the ability to upgrade existing releases to new chart versions or modified configurations using the helm upgrade command, which applies changes such as updating values via the --set flag.^[39] For instance, administrators can perform targeted updates by specifying overrides like --set image.tag=v1.2.3 during the upgrade process, ensuring seamless evolution of Kubernetes applications without full redeployments.^[39] Complementing this, the helm rollback command enables reverting a release to a previous revision, preserving historical states for recovery from failed upgrades or errors, with the revision number specified as an argument to maintain operational stability.^[40] A core advanced feature is Helm's templating system, which leverages the Go template language to generate Kubernetes manifests dynamically from chart templates, allowing for flexible parameterization through values files.^[24] Values can be overridden at runtime during installation or upgrade, such as by providing custom values.yaml files or inline --set options, enabling environment-specific adaptations without altering the chart source.^[41] Template helpers, like {{ .Values.image.tag }}, facilitate access to these values within YAML templates, supporting conditional logic, loops, and functions to create reusable and configurable application definitions.^[24] Helm supports lifecycle hooks to execute custom actions at key points in a release's lifecycle, implemented via annotations in chart resources such as Jobs or Pods.^[26] For example, pre-install hooks run after template rendering but before resource creation, while post-install hooks execute after all resources are successfully deployed, allowing developers to automate tasks like database migrations or validations using annotations like helm.sh/hook: pre-install.^[26] These hooks integrate with Kubernetes resources and can be weighted for ordering, providing precise control over deployment sequences in complex applications.^[26] To ensure chart integrity before deployment, Helm includes linting and validation tools, with the helm lint command performing a series of structural and semantic checks on a chart's files, dependencies, and templates to identify potential issues.^[42] This validation process verifies best practices, such as proper YAML formatting and value usage, helping prevent deployment failures in production environments.^[42]

Installation and Setup

Installing the Helm Client

The Helm client, also known as the helm binary, can be installed on various operating systems using official binary releases from GitHub, automated scripts, or platform-specific package managers. Installation requires a compatible environment, and while the Helm client itself does not depend on kubectl, using Helm to interact with Kubernetes clusters necessitates having kubectl installed and configured separately.^[43]

Linux

For Linux distributions, the recommended method is to download pre-built binaries from the official GitHub releases page at https://github.com/helm/helm/releases. Users select the appropriate architecture (e.g., AMD64), download the tarball (such as helm-v4.0.0-linux-amd64.tar.gz), unpack it with tar -zxvf helm-v4.0.0-linux-amd64.tar.gz, and move the helm binary to a directory in the PATH, like [sudo](/page/Sudo) mv linux-amd64/helm [/usr/local/bin](/page/Filesystem_Hierarchy_Standard)/helm. After installation, verify by running helm version to check the installed version.^[43] Alternatively, use the official installation script for automated setup: download it with curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4, make it executable via chmod 700 get_helm.sh, and execute ./get_helm.sh. This script automatically detects the platform, downloads the binary from get.helm.sh, and verifies its integrity using SHA256 checksums by comparing the downloaded file against an official .sha256 checksum file; if the checksums mismatch, the script aborts the installation. No GPG signatures are provided for direct binary downloads, but the script method ensures checksum validation. Package managers like apt for Debian/Ubuntu involve installing required packages (sudo apt-get install curl gpg apt-transport-https --yes), adding the GPG key (curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null), adding the repository (echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list), updating packages (sudo apt-get update), and installing (sudo apt-get install helm), which inherently verifies signatures via the repository configuration. For Fedora, use sudo dnf install helm; for Snap, sudo snap install helm --classic. Building from source requires Git and a Go environment: clone the repository (git clone https://github.com/helm/helm.git), navigate to it (cd helm), and run make to generate the binary at bin/helm.^[43]

macOS

On macOS, download the binary tarball from GitHub releases, unpack it (e.g., tar -zxvf helm-v4.0.0-darwin-amd64.tar.gz), and move the helm binary to /usr/local/bin/helm using [mv](/page/List_of_POSIX_commands) darwin-amd64/helm /usr/local/bin/helm. Verify with helm version. The installation script method works similarly to Linux, downloading and checksum-verifying the binary via get.helm.sh using curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4. For Homebrew users, simply run brew install helm, which handles download and integrity checks through the package manager. Source builds follow the same process as Linux, requiring Go.^[43]

Windows

For Windows, download the ZIP archive from GitHub releases (e.g., helm-v4.0.0-windows-amd64.zip), extract it, and add the helm.exe binary to the system PATH. Verify by opening a command prompt and running helm version. The installation script is supported via PowerShell or command line, performing SHA256 checksum verification akin to other platforms using curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4. Package managers include Chocolatey (choco install kubernetes-helm), Scoop (scoop install helm), or Winget (winget install Helm.Helm), each managing verification internally. No official GPG signatures are available for binaries, but checksums are used in the script method.^[43] Note that binary releases are tested primarily on Linux AMD64, and package manager methods are community-supported rather than officially maintained by the Helm project. After installing the client, users can proceed to configure repositories for chart access.^[43]

Configuring Repositories

After installing the Helm client, configuring repositories is a key step to access available charts for deployment on Kubernetes clusters. Repositories serve as centralized locations where packaged Helm charts are stored and indexed, allowing users to discover, add, and manage them locally. The configuration process involves using the helm repo subcommands to add, update, list, and remove repositories, with repository details stored in a YAML file at ~/.config/helm/repositories.yaml by default.^[44] To add a repository, use the helm repo add command, which requires specifying a unique name and the repository's URL. For example, the command helm repo add bitnami https://charts.bitnami.com/bitnami adds the Bitnami repository.^[45][46] If the repository requires authentication, such as for private HTTPS servers, include flags like --username and --password; for instance, helm repo add private-repo https://example.com/charts --username myuser --password mypass.^[45] Additional security options include --cert-file and --key-file for certificate-based authentication, or --insecure-skip-tls-verify to bypass TLS verification (though this is not recommended for production).^[45] Once repositories are added, updating their indices ensures the local cache reflects the latest chart versions. The helm repo update command fetches and refreshes the index files from all configured repositories, storing them in ~/.cache/helm/repository; running helm repo update without arguments updates all repositories.^[44] This step is essential before searching or installing charts to avoid using outdated information. For management, the helm repo list command displays all configured repositories, showing their names and URLs, while helm repo remove deletes one or more by name, such as helm repo remove stable.^[44] These commands help maintain a clean list of active sources. Integration with Artifact Hub, a web-based platform for discovering and publishing Cloud Native packages including Helm charts, simplifies access to public repositories. Users can browse Artifact Hub at artifacthub.io to find charts, then add the corresponding repository URL using helm repo add, followed by helm repo update to fetch the index.^[47] This enables seamless incorporation of community-maintained public charts into local Helm configurations.

Usage

Creating and Managing Charts

Helm charts are created and managed using the Helm CLI to facilitate the packaging and deployment of Kubernetes applications. The process begins with generating a basic chart skeleton, which provides a standardized directory structure including essential files like Chart.yaml, values.yaml, and templates for Kubernetes resources. This structure ensures consistency and ease of customization for developers building reusable application packages.^[48] To generate a chart skeleton, users execute the helm create command, specifying a name for the chart directory, such as helm create mychart. This command initializes a new directory with the core files: Chart.yaml for metadata like name, version, and description; values.yaml for default configuration parameters; and a templates/ directory containing placeholder YAML files for Kubernetes manifests, such as deployment.yaml and service.yaml. The generated templates use Go templating syntax to allow dynamic content based on values, enabling parameterization of resources like replica counts or image tags.^[48][49] Editing templates and values involves customizing the YAML files within the chart directory to define the application's Kubernetes resources. Templates are written using Go template functions and Helm-specific constructs like {{ .Values.image.repository }} to inject values dynamically, ensuring the rendered output produces valid Kubernetes manifests. Developers can also add validation schemas to values.yaml using JSON Schema format in a values.schema.json file, which enforces data types and constraints during chart rendering or installation, preventing misconfigurations. For instance, a schema might require the image tag to be a string matching a semantic version pattern. This customization process allows charts to be adaptable for different environments while maintaining declarative, reproducible deployments.^[50][49] Packaging a chart prepares it for distribution by bundling the directory into a versioned tarball archive, typically named after the chart's name and version, such as mychart-0.1.0.tgz. The helm package command handles this by compressing the chart files while excluding the .helmignore-specified items, making it suitable for sharing via repositories or direct installation. Dependency management is integral to this step, as charts can declare external subcharts in Chart.yaml's dependencies section, specifying repository URLs, versions, and aliases. Commands like helm dependency update fetch and update these dependencies into the charts/ subdirectory, ensuring the packaged chart includes all required components without manual intervention. Additionally, helm dependency list displays the current dependencies, aiding in version tracking and auditing.^[51][52][50] Testing charts is essential to validate structure, syntax, and rendering before deployment. The helm lint command performs static analysis on the chart, checking for issues like missing required fields in Chart.yaml, invalid YAML in templates, or deprecated Kubernetes API usage, providing detailed error reports for quick fixes. For dynamic validation, helm template renders the chart's templates locally using provided or default values, outputting the expanded Kubernetes manifests without applying them to a cluster; this allows dry-run verification of the final YAML for correctness and completeness. These tools help maintain chart quality and prevent runtime errors during actual installations.^[42][53] Once created and validated, charts can be installed to produce releases in a Kubernetes cluster, as detailed in subsequent sections on usage.^[50]

Installing and Upgrading Releases

Helm releases are deployed to a Kubernetes cluster using the helm install command, which takes a release name and the path to a chart as its primary arguments.^[31] To simulate an installation without applying changes to the cluster, the --dry-run flag can be used in combination with --debug to output the generated Kubernetes manifests for review.^[34] For instance, running helm install my-release ./my-chart --dry-run --debug allows users to verify the rendered templates client-side or server-side without persisting resources, helping to catch configuration errors before actual deployment.^[34] Namespace specification is handled via the --namespace or -n flag, defaulting to the default namespace if omitted; for example, helm install my-release ./my-chart --namespace production deploys the release into a custom namespace, and the --create-namespace flag can automatically create it if it does not exist.^[34] Upgrading an existing release is performed with the helm upgrade command, which updates the release to a new chart version or modified values while preserving the release name.^[39] Value overrides during upgrades can be applied using --values to load from YAML files or --set for command-line flags, allowing customization such as helm upgrade my-release ./my-chart --set service.type=LoadBalancer; multiple overrides merge with the last one taking precedence.^[39] For atomic-like behavior, the --cleanup-on-fail option ensures that if the upgrade fails, newly created resources are deleted to prevent partial deployments, though it does not roll back existing resources.^[39] Additional flags like --wait and --timeout can be used to ensure resources are ready within a specified duration before considering the upgrade successful.^[39] For charts that produce large manifests, which can exceed size limits in the release storage backend, it is recommended to use the --history-max flag during installation or upgrade as a best practice to limit the number of stored revisions and avoid size limit errors (default 10), for example helm upgrade my-release ./my-chart --history-max 2.^[39] In case of issues post-upgrade, rollbacks are managed via the helm rollback command, which reverts a release to a previous revision number obtained from helm history <release-name>.^[40] For example, helm rollback my-release 1 restores the release to its first revision, incrementing the revision counter upon completion; omitting the revision defaults to the previous one (revision 0).^[40] Options such as --wait and --timeout apply similarly to ensure pod readiness, and --no-hooks can skip hook executions during the process.^[40] Handling multiple releases involves assigning unique names to each installation, enabling the same chart to be deployed repeatedly across the cluster, such as helm install release1 ./my-chart followed by helm install release2 ./my-chart --namespace dev.^[31] Namespaces further isolate releases, with each release scoped to its specified namespace for resource management; tools like helm list --all-namespaces provide an overview of all releases across namespaces.^[31] This approach supports complex environments by allowing independent lifecycles for releases in different namespaces without interference.^[31]

Security and Best Practices

Security Considerations

One significant security improvement in Helm came with version 3.0, released in November 2019, which completely removed the Tiller server component that was present in earlier versions.^[54] Tiller, a server-side component in Helm 2, created an attack surface by requiring elevated Kubernetes permissions to manage releases, potentially allowing attackers to compromise the cluster if Tiller was exploited.^[55] By eliminating Tiller, Helm 3 simplifies operations and enhances security by relying solely on the client-side Helm CLI, which interacts directly with the Kubernetes API using the user's credentials, thereby reducing the risk of unauthorized cluster modifications.^[56] Helm 4.0.0, released in November 2025, introduces advanced features for chart signing and provenance to verify the authenticity and integrity of packages.^[57] These tools leverage public key infrastructure (PKI) and GnuPG-based signing to ensure that charts have not been tampered with during distribution, allowing users to confirm the origin and unaltered state of a chart before installation.^[58] Provenance files, generated alongside signed charts, include verification metadata such as checksums and signatures, enabling automated checks in CI/CD pipelines to prevent the deployment of malicious or corrupted artifacts.^[59] Integrating Helm with Kubernetes Role-Based Access Control (RBAC) is essential for minimizing permissions and enforcing least-privilege principles during operations.^[60] Users should configure RBAC roles and role bindings to grant Helm only the specific permissions needed for tasks, such as creating resources in a particular namespace, rather than using cluster-admin privileges that could expose the entire cluster to risks.^[61] For example, a custom Role can limit Helm to actions like get, list, create, update, and delete on relevant resources, ensuring that even if the Helm client is compromised, the blast radius remains contained.^[62] Deploying untrusted charts poses substantial risks, including the introduction of vulnerabilities, backdoors, or misconfigurations that could lead to privilege escalation or data exfiltration in Kubernetes clusters.^[63] To mitigate these, organizations should lint charts using tools like helm lint to detect syntax errors, deprecated APIs, and potential security issues before installation, while also establishing trust in repositories by verifying their authenticity and scanning for known vulnerabilities.^[60] Additionally, rendering charts with helm template allows inspection of the generated Kubernetes manifests without applying them, helping identify hidden risks in third-party charts from unverified sources.^[64]

Common Pitfalls and Best Practices

One common pitfall in Helm usage is incorrectly overriding values, which can lead to unintended changes in deployments, such as generating new random credentials during upgrades that mismatch persisted application data, causing authentication failures.^[65] Another frequent error involves ignoring dependency updates, particularly when using deprecated repository URLs like those for the "stable" or "incubator" charts, which can prevent charts from fetching the latest dependencies after deprecations took effect in November 2020.^[66] Namespace mismatches also pose a significant risk, especially post-migration from Helm 2 to Helm 3, where releases scoped to specific namespaces may not appear in helm list outputs without explicit flags, leading to overlooked or inaccessible deployments.^[66] Resource conflicts represent another prevalent issue, often arising from discrepancies in Custom Resource Definitions (CRDs) between the Helm chart and the Kubernetes cluster, or from retained Persistent Volume Claims (PVCs) after uninstalling releases, which can block reinstallations with the same release name.^[67][65] Failed hooks, such as pre- or post-rollback jobs for tasks like database migrations, can cause releases to hang in a pending state if they fail to complete, exacerbating conflicts when underlying Kubernetes resources like pods encounter issues such as ImagePullBackOff or CrashLoopBackOff.^[68] Another common pitfall relates to size limitations in Helm's release storage mechanism. Helm stores each release revision in Kubernetes objects—Secrets by default, or ConfigMaps if configured as the storage driver. Both object types are limited to 1 MiB in size due to Kubernetes constraints. Charts producing large manifests, such as kube-prometheus-stack, can exceed this limit after compression and base64 encoding, leading to errors indicating the object is too large during installation or upgrade. Switching from the Secret driver to ConfigMap does not increase the size limit. To mitigate this issue, reduce the number of stored release revisions by setting a low value for the --history-max flag (e.g., --history-max=2) during helm install or helm upgrade commands. For exceptionally large manifests, exploring external storage solutions may be necessary.^[28][27][39] To mitigate these pitfalls, practitioners should adopt version pinning by defining explicit versions in the Chart.yaml file's version and optionally appVersion fields, ensuring consistent deployments across environments.^[69] Integrating Helm with CI/CD pipelines is a recommended best practice, involving steps like packaging charts into repositories before deployment to enable better tracking, reusability, and automated rollbacks with health checks.^[69] Using environment-specific values files allows customization without modifying core charts, promoting a single-chart-multi-environment approach while overriding values judiciously—such as explicitly setting credentials during upgrades to avoid regeneration.^[69][65] For performance optimization, atomic upgrades ensure consistent state changes during releases, paired with dry-run testing via helm template to validate manifests without actual deployment, catching errors early.^[69] Dependency management should involve systematic updates using the dependencies section in Chart.yaml in umbrella charts to group and version sub-charts reliably.^[69][52] Troubleshooting common issues begins with verifying namespaces using flags like --all-namespaces in helm list to resolve mismatches.^[66] For dependency problems, force-update repositories with commands tailored to deprecated sources.^[66] Resource conflicts with PVCs or CRDs can be addressed by manually deleting leftovers before reinstallation or forcing applies via APIs, while ensuring proper permissions for non-root containers.^[65][67] Failed hooks require inspecting job logs and pods for root causes, with options to bypass them using --no-hooks during rollbacks or extending timeouts with --timeout for slower resources.^[68] Overall, these strategies, when combined with brief attention to security risks like unused releases increasing attack surfaces, enhance reliable Helm operations.^[60]