← Back to DevOps

Helm: Kubernetes Package Manager Explained

Helm is a package manager for Kubernetes that simplifies deploying and managing applications. It uses charts—pre-configured Kubernetes templates—to bundle your app's configuration, making multi-step deployments repeatable and version-controlled.

What Is Helm?

Helm solves a real problem: writing raw YAML manifests for Kubernetes is tedious, error-prone, and hard to maintain. With hundreds of configuration files needed for a typical application, managing them manually across environments becomes a nightmare.

Think of Helm as apt or npm, but for Kubernetes. Instead of writing manifests by hand, you define your app once in a reusable template called a chart, then deploy it anywhere with a single command. Helm handles the templating, variable substitution, and versioning automatically.

The project was originally developed by Deis and is now maintained by the Cloud Native Computing Foundation (CNCF). It's become the de facto standard for Kubernetes package management, with thousands of production charts available in public repositories.

Core Components of Helm

Helm Charts

A chart is a collection of files that describe a Kubernetes application. It's essentially a templated package containing:

• Chart.yaml — Metadata about the chart (name, version, description)
• values.yaml — Default configuration values that users can override
• templates/ — Kubernetes manifest files with placeholder variables
• charts/ — Dependencies (other charts your app needs)
• README.md — Documentation

Charts are portable. You can share them across teams, versions, and environments. A single chart can deploy to dev, staging, and production with different values files.

Helm Releases

A release is an instance of a chart running in your cluster. When you deploy a chart, Helm creates a release with a unique name. You can have multiple releases of the same chart—each with different configurations and names.

Helm tracks releases and maintains release history, so you can rollback to previous versions instantly if something breaks.

Helm Repositories

Repositories are remote stores of charts. Think of them as app stores for Kubernetes. The most popular ones include:

• Bitnami Helm Repository — Production-grade charts for databases, web servers, monitoring tools
• Official Helm Charts — Maintained by the Helm project and CNCF
• ArtifactHub — Searchable index of thousands of public charts

You can also create private repositories for internal charts using tools like ChartMuseum or Harbor.

How Helm Works: The Workflow

The Helm workflow is straightforward but powerful. Here's what happens when you deploy a chart:

1. You specify a chart and values file
2. Helm renders the templates by substituting variables from values.yaml
3. The rendered YAML is sent to Kubernetes API
4. Kubernetes creates the resources (pods, services, deployments, etc.)
5. Helm stores the release record in the cluster

The beauty here is separation of concerns. Developers define the chart once. Operations teams provide environment-specific values. DevOps engineers manage deployments with single commands.

Installing a Chart

Let's deploy a real example. Say you want to run Nginx:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-nginx bitnami/nginx --values custom-values.yaml

That's it. Three commands deploy a production-ready Nginx with all best practices baked in. Without Helm, you'd write 50+ lines of YAML manually.

Upgrading and Rolling Back

Need to update your app to a new version? Helm makes it seamless:

helm upgrade my-nginx bitnami/nginx --values custom-values.yaml

Helm applies only the changes, leaving other resources untouched. And if the upgrade fails, rollback is one command:

helm rollback my-nginx 1

Creating Your Own Helm Chart

For custom applications, you'll want to create your own charts. Helm provides scaffolding:

helm create my-app

This generates a basic chart structure. Let's say your app needs a Deployment and Service. Your templates/deployment.yaml might look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port }}

Notice the template syntax: {{ .Values.replicaCount }} gets replaced with actual values from values.yaml. This single template now works for dev, staging, and production—just change the values file.

Values File Example

replicaCount: 3

image:
  repository: myapp
  tag: "1.2.0"

service:
  port: 8080
  type: LoadBalancer

When to Use Helm

Helm isn't necessary for everything. Consider using it when you have:

• Multiple environments — Dev, staging, production with different configs
• Dependency management — Your app relies on databases, caches, or other services
• Versioning requirements — You need to track and rollback application versions
• Team collaboration — Different teams managing deployments and configuration
• Third-party applications — Using community charts from repositories

For simple single-environment deployments or learning Kubernetes, raw YAML or kustomize might be sufficient.

Helm Alternatives

While Helm dominates, alternatives exist:

• Kustomize — Overlays and patching without templating. Built into kubectl
• ArgoCD — GitOps-focused, uses Git as source of truth for deployments
• Flux — Another GitOps tool with tight Kubernetes integration
• Jsonnet — More powerful templating but steeper learning curve

Many teams use Helm charts deployed through ArgoCD or Flux for CI/CD workflows that enforce GitOps practices.

Best Practices for Helm

Don't just use Helm—use it well. Here's how:

• Version your charts — Bump the version in Chart.yaml with each release. Use semantic versioning
• Document values — Add comments explaining what each value does and its valid range
• Use linting — Run helm lint before committing to catch YAML errors early
• Test upgrades — Use helm upgrade --dry-run to preview changes before applying
• Manage secrets properly — Don't hardcode passwords in values.yaml. Use external secret management
• Pin chart versions — In production, lock to specific chart versions to avoid surprises

Helm and GitOps

Modern DevOps teams integrate Helm with GitOps platforms. You store Helm charts and values in Git, then tools like ArgoCD automatically detect changes and apply them to clusters. This approach gives you:

• Complete audit trail of what changed and when
• Pull request reviews before deployment
• Automatic rollback capability
• Declarative infrastructure as code

Check out our ArgoCD guide to see how Helm integrates with GitOps workflows.

Getting Started with Helm

Ready to use Helm? Start here:

1. Install Helm 3 from helm.sh
2. Add a repository — helm repo add bitnami https://charts.bitnami.com/bitnami
3. Search for charts — helm search repo nginx
4. Deploy — helm install my-release bitnami/nginx
5. Check status — helm status my-release

For deeper learning, explore the Kubernetes deployment strategies article and understand how Helm integrates with your deployment pipeline.

Helm 3 vs Helm 2

Helm 2 is deprecated. If you're still on it, upgrade immediately. Key differences:

• Tiller removed — Helm 3 eliminated the server-side Tiller component, simplifying security
• No more roles — You don't need special RBAC permissions for Helm itself
• Better release management — More reliable tracking of deployments
• Three-way merge — Smarter upgrades that account for manual changes