Running a real application on Kubernetes takes far more than a single file.

Kubernetes describes everything you want to run through text files called manifests. A manifest says, for example, “run three copies of this program,” or “expose this program on this port.” A small demo may need only one or two manifests. A real application needs many: one for the program itself, one for its network address, one for its settings, one for its secret passwords, one for its storage, one for permissions, and often more. A typical production application can easily need twenty or thirty files.

Managing that pile of files by hand creates several painful problems. You must apply them in the right order. You must edit the same values in many places, such as the name of the application or the version of the software. If you want to run the same application in a test environment and a production environment, you must copy all the files and change a few details in each copy. Over time, the copies drift apart, and nobody is sure which version is running where.

The questions teams kept asking

Teams found themselves asking the same questions again and again. How do I install this whole application with one command? How do I change one setting without editing ten files? How do I upgrade safely, and go back if the upgrade goes wrong? How do I share my application with other teams, or use one built by someone else? Helm was created to answer these questions in a standard way.

A package manager and templating tool that installs and tracks whole applications on Kubernetes.

Helm is an open-source tool that acts as the package manager for Kubernetes. If you have used a package manager on a computer, such as the software store on a phone or the tool that installs programs on a server, the idea is the same. Instead of downloading and configuring every piece of a program yourself, you ask the package manager to install it by name. It finds the package, applies your choices, installs everything in the right order, and keeps a record of what it did.

Helm packages are called charts. A chart is a collection of files that together describe a Kubernetes application, including templates for the manifests and a set of default settings. When you install a chart, Helm combines the templates with your settings, produces the final manifests, and sends them to the cluster. The resulting installed application is called a release, and Helm tracks each release so that it can upgrade, roll back, or remove it later.

A brief history

Helm began as a project to make Kubernetes applications easier to share and install, and it became one of the most widely adopted tools in the ecosystem. It is maintained under the Cloud Native Computing Foundation, the same organisation that hosts Kubernetes. The first major version relied on a server-side component inside the cluster called Tiller, which caused security concerns because it held broad permissions. The third major version removed Tiller entirely, and Helm now works as a simple client that talks directly to the cluster using the permissions of the person running it.

Five words explain almost everything Helm does.

flowchart LR
    R[Repository
stores charts] --> C[Chart
templates and defaults]
    V[Your values
your choices] --> H[Helm renders]
    C --> H
    H --> M[Final manifests]
    M --> K[Kubernetes cluster]
    K --> REL[Release
tracked by Helm]
        

A chart is just a folder with a predictable layout.

A chart is a directory of files arranged in a standard way. Because the layout is standard, every chart in the world can be understood by the same tool and read by anyone familiar with Helm. Knowing what each part is for makes charts far less mysterious.

flowchart TD
    CH[Chart folder] --> META[Metadata
name and versions]
    CH --> VAL[Default values]
    CH --> TPL[Templates folder]
    CH --> SUB[Subcharts folder]
    CH --> CRD[CRDs folder]
    TPL --> D[Deployment template]
    TPL --> S[Service template]
    TPL --> CM[ConfigMap template]
    TPL --> H[Helper snippets]
        

A small client program that renders manifests and talks to the cluster.

Helm is a command-line program that runs on your computer or in an automation pipeline. When you ask it to install a chart, it reads the chart, combines the templates with your values to create the final manifests, and then sends those manifests to the Kubernetes API server, which is the front door of the cluster. Helm then stores a record of what it did inside the cluster, so it can recognise the release later.

sequenceDiagram
    participant U as You
    participant H as Helm client
    participant R as Chart source
    participant API as Kubernetes API Server
    participant C as Cluster
    U->>H: Install chart with my values
    H->>R: Fetch the chart if not local
    R-->>H: Chart files
    H->>H: Merge values and render templates
    H->>API: Send final manifests
    API->>C: Create the resources
    H->>API: Store the release record
    H-->>U: Report success and notes
        

No server component in the cluster

In the current major version, Helm has no server part running in your cluster. Everything it does happens with your own credentials, exactly as if you had sent the manifests yourself. This is a security improvement, because the permissions Helm uses are the same as the person or pipeline that runs it, and no extra powerful component sits in the cluster waiting to be attacked.

Templates are manifests with blanks that Helm fills in.

A plain manifest contains fixed text, such as the exact name of the application and the exact number of copies. A template is the same manifest but with placeholders where you want flexibility. A placeholder might say “put the image version here,” or “put the number of replicas here.” When Helm renders the template, it replaces each placeholder with the corresponding value and produces an ordinary manifest.

Helm’s templates use a text-templating language with a rich set of built-in functions. These functions can supply a default when a value is missing, insist that a required value is present, convert data structures into the right format, and add indentation. Templates can also contain conditions, such as “only create this resource if ingress is turned on,” and loops, such as “create one entry for each item in this list.”

One chart, many environments, thanks to layered settings.

Every chart ships with a file of default values. These defaults describe a working installation with sensible choices. You rarely want to edit the chart itself. Instead, you supply your own values, either in a file of your own or as small overrides on the command line. Helm combines all of them, and the more specific ones win over the general ones.

Keeping values safe and correct

A chart can include a schema that describes which values are allowed and what type each must be. When a schema is present, Helm checks your values against it before doing anything, and rejects mistakes such as a text where a number is expected. This turns confusing failures deep inside the cluster into clear messages at the start.

Four actions cover the whole life of an application.

flowchart LR
    I[Install
revision 1] --> U1[Upgrade
revision 2]
    U1 --> U2[Upgrade
revision 3]
    U2 --> RB[Rollback to 2
revision 4]
    RB --> U3[Upgrade
revision 5]
    U3 --> X[Uninstall]
        

How an upgrade decides what to change

When you upgrade a release, Helm does more than blindly resend everything. It compares three things: the manifest from the previous revision, the current live state of the resources in the cluster, and the newly rendered manifest. This three-way comparison lets Helm notice changes made by the chart and also respect certain manual changes made directly in the cluster, producing a more sensible update than a simple overwrite.

Helm keeps its records inside the cluster, next to the application.

For Helm to upgrade or roll back a release, it must remember what it installed. In the current version, each revision of a release is stored as an object inside the cluster, by default as a Secret in the same namespace as the release. The record includes the chart, the values that were used, and the manifests that were rendered. Because the records live in the cluster, any person or pipeline with access to the namespace can see and manage the release, and no separate database is needed.

Why the records deserve protection

The stored record includes the values you supplied and the final manifests. If those contained passwords or keys, the record contains them as well. Treat access to the release records as access to those secrets, and restrict who can read secrets in the release namespace accordingly.

Charts are shared the same way software packages are.

A large part of Helm’s popularity comes from the huge number of charts already written by others. Popular software such as databases, message brokers, monitoring stacks, and ingress controllers is available as ready-made charts. You add a repository, search it, and install a chart by name, instead of writing manifests yourself.

flowchart TD
    A[Publisher writes a chart] --> B[Package and sign the chart]
    B --> C[Publish to a repository or registry]
    C --> D[User searches or names the chart]
    D --> E[Helm downloads the chart]
    E --> F[Values applied and release installed]
        

Charts can be built from other charts, like boxes inside boxes.

Many applications need supporting software, such as a database or a cache. Instead of copying those manifests into your chart, you can declare the other chart as a dependency. Helm downloads the dependency, places it in the charts folder as a subchart, and installs it together with your chart as one release. You can also pass values down to the subchart, and you can switch a dependency on or off with a simple condition.

flowchart TD
    P[Parent chart
my application] --> S1[Subchart
database]
    P --> S2[Subchart
cache]
    P --> T[Own templates
web service and settings]
    V[Your values] --> P
    V -->|values under the subchart name| S1
    V -->|values under the subchart name| S2
        

Umbrella charts

An umbrella chart is a chart with little or no templates of its own that exists only to bundle several other charts into one installable unit. It is a common way to deploy a whole platform made of many services with a single release, and to control all of their versions in one place.

Running special tasks at specific moments in a release.

Some applications need extra steps at particular times: a database migration before an upgrade, a cleanup job before deletion, or a smoke test after installation. Helm supports this through hooks, which are ordinary Kubernetes resources marked to run at a certain point of the release lifecycle. Because they are resources like any other, a hook is often a short-lived job.

sequenceDiagram
    participant H as Helm
    participant M as Pre-upgrade hook job
    participant K as Cluster
    H->>M: Run migration job
    M->>K: Update the database structure
    M-->>H: Job completed
    H->>K: Apply upgraded application resources
    K-->>H: Resources ready
    H->>K: Run post-upgrade hook if defined
        

Three ways to deploy, each with a different philosophy.

Helm is not the only way to deploy to Kubernetes. Applying manifests directly with the standard command-line tool is the simplest approach. Kustomize is another popular tool that customises plain manifests using overlays and patches rather than templates. Each has strengths, and many teams use more than one.

flowchart TD
    Q1{Need to package and share the application?} -->|Yes| H[Use Helm]
    Q1 -->|No| Q2{Need light changes per environment?}
    Q2 -->|Yes| K[Use Kustomize]
    Q2 -->|No| P[Plain manifests are enough]
    Q3{Installing third-party software?} -->|Yes| H
        

Situations where a package manager pays for itself.

Automating releases so that people do not type commands at midnight.

Helm fits naturally into automated delivery. A pipeline builds a container image, updates the chart version or values, and runs a single install-or-upgrade action against the cluster. The chart and the values live in version control, so every release can be traced back to a commit, reviewed by teammates, and reproduced later.

flowchart LR
    C[Developer commits code] --> B[Pipeline builds image]
    B --> V[Update values with new image version]
    V --> L[Lint and render the chart]
    L --> T[Deploy to staging release]
    T --> A[Run tests]
    A --> P[Deploy to production release]
        

The push model and the pull model

In a push model, a pipeline runs Helm and pushes changes into the cluster. This is easy to understand, but the pipeline needs credentials to the cluster. In a pull model, often called GitOps, a controller running inside the cluster watches a Git repository and applies the chart itself whenever the repository changes. The cluster pulls the desired state, and nobody needs to push into it from outside.

A few options turn a hopeful upgrade into a controlled one.

By default, Helm sends the manifests and reports success as soon as the API server accepts them. That does not mean the pods started or became healthy. To make upgrades safer, Helm offers options that wait for resources to become ready and automatically undo a failed upgrade.

Traps that cause upgrade failures

Helm is light, but big charts and many releases bring their own limits.

Helm itself does little work: it renders text and talks to the API server. Rendering even a large chart takes moments. The real costs appear elsewhere. Large releases produce large records that must be stored and read on every operation. Charts with hundreds of resources take longer to apply and to wait for. Repositories with thousands of chart versions produce large index files that slow searches.

A chart is code that creates resources in your cluster, so trust matters.

A chart can create almost anything in a cluster: workloads, permissions, network rules, and even resources that grant wide access. Installing a chart from a source you do not trust is like running a program from the internet with your own permissions. Security with Helm therefore starts with knowing what you install and who is allowed to install it.

Most Helm problems are visible if you look at the rendered output and the release status.

When something goes wrong, there are usually only three places it can have gone wrong: the values were not what you expected, the template rendered something different from what you intended, or the cluster rejected or could not run the result. Working through them in order finds the cause quickly.

Habits that make charts easy to use and safe to change.

flowchart TD
    L[Library chart
company standards] --> A[Application chart A]
    L --> B[Application chart B]
    L --> C[Application chart C]
    A --> RA[Release in staging and production]
    B --> RB[Release in staging and production]
    C --> RC[Release in staging and production]
        

Mistakes that make charts fragile and releases painful.

A short checklist for confident use of Helm.

How teams use Helm in everyday operations.

Helm is the package manager for Kubernetes. It bundles the many files of an application into one package called a chart, lets you customise it with values, installs it as a release, and keeps a history so you can upgrade or roll back.

A chart is the package, the blueprint. A release is one installed instance of that chart in a cluster. You can install the same chart many times, each as a separate release with its own name and values.

No. The current major version is client-only. The older Tiller component was removed, and Helm now works with the permissions of the person or pipeline that runs it.

By default, as secrets in the same namespace as the release, one record per revision. It can be configured to use configuration maps or a database instead.

Chart defaults have the lowest priority, then parent chart values, then your values files with later files winning, and finally individual overrides given on the command line, which win over everything.

No. Rollback reapplies earlier manifests, but it does not reverse changes to data or database structure. Take backups and design migrations with this in mind.

They solve different problems. Helm packages, shares, and tracks applications using templates. Kustomize customises plain manifests with overlays. Many teams use both, for example rendering a chart and patching the result.

Hooks run special resources, usually jobs, at particular moments such as before an upgrade or after an install. They are used for migrations, cleanups, and checks, and they need their own cleanup policy.

The chart change modified a field that Kubernetes does not allow to change after creation, such as a workload selector. The object must be deleted and recreated deliberately, or the change must be reverted.

No. Definitions in the CRDs folder are installed on first install but are not upgraded or removed later, to avoid deleting custom objects by accident. Handle definition changes with a separate process.

Not automatically. A chart can create powerful resources. Review the rendered output, prefer trusted publishers, pin versions, and verify signatures where available.

GitOps controllers can render and apply Helm charts from a Git repository automatically. The chart and values live in Git, and the controller keeps the cluster in line with them, correcting drift.

Helm is the package manager for Kubernetes. It solves the problem of managing many separate manifest files by bundling them into charts, letting you customise them with values, and installing them as tracked releases. Each install, upgrade, and rollback creates a numbered revision, so you always know what changed and can return to an earlier state with a single action.

Helm is light and flexible, but it rewards care. Charts should be simple, versions should be pinned, secrets should stay out of plain files, and pipelines should render, lint, wait for readiness, and be ready to roll back. It does not run your application or undo your data, and it sits alongside tools such as Kustomize and GitOps controllers rather than replacing them. Used thoughtfully, Helm turns complicated deployments into repeatable, reviewable, and reversible routines.