Learn Cloud Native

Sign up to receive our newsletter

What is Helm in Kubernetes?

Helm is an open source package manager that automates the deployment of software for Kubernetes in a simple, consistent way. Helm makes it easy to package applications for Kubernetes and deploy them using just a few commands. Although Helm is not part of Kubernetes itself – instead, it’s a third-party utility – it is one of the handiest tools you can use when working with Kubernetes.

Keep reading for everything you need to know about Helm, including what it’s used for, how to create Helm charts, common Helm commands, and more.

How Does Helm Work?

With Helm, you can create a special file – called a Helm chart – that contains the data required to deploy an application on Kubernetes. You can then use Helm’s CLI tool (or, in some cases, a Web-based UI) to install the Helm chart onto a Kubernetes cluster of your choice.

Thus, Helm is similar to Linux package management tools like apt and dnf. It’s also comparable in some ways to app stores, in the sense that it lets you select and install applications quickly and easily.

Why Is Helm Used?

Helm is not the only way to install applications on Kubernetes. If you don’t want to use Helm, you can manually create a Pod specification, which defines (among other things) the container or containers that you want to deploy. You can then apply the specification with kubectl to deploy your application.

That approach requires a fair amount of effort, however. You also have to repeat the process whenever you want to update your application, and you have to shut down a deployment manually if you want your application to stop running.

In addition, with manual application deployments, there is no easy way to share applications with third parties. Anyone who wants to install your application into their Kubernetes cluster would need to pull the app’s container images and YAML specifications separately, then apply them.

Helm addresses all of these challenges by making it possible to define resources for Kubernetes applications using YAML, then automatically deploy them into a cluster. Helm also accepts flags that can selectively install parts of an application, and it maintains a revision history in the namespace to simplify rollbacks.

Thus, Helm not only saves time for Kubernetes admins, but it also helps developers to distribute Kubernetes applications more efficiently, and it makes it easier to automate application updates and upgrades.

What Is a Helm Chart and Template?

As noted above, a Helm chart is a directory that contains one or more templates that describe Kubernetes resources. (Helm charts can also contain additional files, such as a help text file that Helm displays to user when they run a chart.) A template is a Kubernetes manifest that defines an application deployment or other type of workload. For example, a very basic template file might look like this:

apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World"
Code language: JavaScript (javascript)

Charts can also identify dependencies, which Helm will install along with a given Helm chart.

Helm Storage

You can host Helm charts locally if you want by storing them directly on your computer. However, it’s more common to store Helm charts in repositories, making them easy to access. Helm repositories allow users to download charts using a process similar to downloading container images from a container registry.

Helm Charts vs. Operators

It’s important not to confuse Helm charts with operators, which perform a similar but distinct function in Kubernetes.

Operators are application-specific controllers that use the Kubernetes API to create and manage resource configurations in Kubernetes. Although operators can be used to install applications – in fact, many of them use Helm behind the scenes -, their main use case is for managing special, complex configurations in a Kubernetes cluster and also managing the lifecycle of the application they are responsible for – including among these the cluster components themselves. They’re more or less analogous to a high level automation language that you would use to modify the configuration of a server abstracting the technical details.

In contrast, Helm’s main purpose is to install and manage individual applications, not your Kubernetes environment itself. That’s why Helm charts are more like Debian or RPM packages than configuration scripts.

Common Helm Commands

The Helm commands you can expect to use most often are straightforward commands for installing or managing Helm charts. The following are some common examples.

Add a Helm Repository

The easiest way to use Helm charts from a repository is to add the repository to your local environment with a command like:

helm repo add example-repo
Code language: JavaScript (javascript)

List Available Charts

To determine which Helm charts are available for you to install on your cluster, first update your chart list with:

helm repo update

Then use this command to list available charts:

helm search repo

Install a Helm Chart

helm install application-name chart

Uninstall a Helm Chart

helm uninstall release-name

Note that a Helm “release” is an existing instance of a Helm chart that you have installed and have running in your cluster. That’s why we specify the release name, not the chart name. This information is stored in the Kubernetes namespace and therefore is independent of the directory or server you might be using to connect to the cluster.

To find the release name, see the next command in the list.

List Helm Releases

To list Helm releases running in your cluster, use:

helm list
Code language: PHP (php)

Upgrade a Helm Chart

To upgrade a Helm chart to a new version, run:

helm upgrade release-name chart-name

Helm Deployment Example

To gain an even closer look at how to use Helm charts and take advantage of Helm automation, let’s walk through a real-world example of installing and configuring an application using Helm. Specifically, we’ll install Falco (the open source security tool) with Helm.

Installing Falco is dead-simple. We simply pull and install the chart from the Falco repository:

helm install --name cncf-falco stable/falco

This will get you up and running with Falco. But what if you want to customize the configuration? The best way to do this is to automate the configuration tweaks at install time. We can do that using a command like:

helm install --name cncf-falco --set falco.jsonOutput=true --set falco.jsonIncludeOutputProperty=true --set falco.programOutput.enabled=true --set falco.programOutput.program=""jq '{text: .output}' | curl -d @- -X POST []("" stable/falco
Code language: PHP (php)

This configures Falco to send a message to Slack every time it detects anomalous behavior.

To make the process even simpler, you could store the configuration data inside a YAML file like this:

falco: jsonOutput: true jsonIncludeOutputProperty: true programOutput: enabled: true program: "jq '{text: .output}' | curl -d @- -X POST []("
Code language: JavaScript (javascript)

And then point Helm to that file (named “values.yaml” in the following example) at install time:

helm install --name cncf-falco -f values.yaml stable/falco

And that, in a nutshell, is the beauty of Helm: it lets us simplify and automate an installation and setup process that would otherwise involve dozens of commands and files.

Best Practices for Helm Security

While Helm is great at automating complex Kubernetes installation routines, it can create major security risks if you use it irresponsibly. Take these steps to minimize your risk:

  • Use only trusted Helm charts: Just as you shouldn’t download untrusted container images, you should only deploy Helm charts from organizations and repositories that you trust.
  • Know which Helm charts you’ve used: Keep track of which Helm releases are running in your cluster. It can be easy in large clusters with multiple admins to forget which Helm charts were installed, which can in turn create security risks because you don’t know which software you’re running (or which vulnerabilities it may be subject to).
  • Uninstall unused releases: If you’re no longer using a Helm release, uninstall it. Unnecessary releases not only waste resources, but they also increase your attack surface.
  • Upgrade Helm and Helm charts: Remember to upgrade not just Helm itself (meaning the Helm utility) but also any Helm releases you’ve deployed on your cluster.


By making it simple to install and manage packages, Helm makes a Kubernetes admin’s life considerably easier. That’s especially true for organizations that take full advantage of Helm’s automation features, including not just the ability to install software but also to upgrade and customize it.