Helm Package Manager for Kubernetes

Charts, releases, and repositories

Three concepts underpin everything in Helm:

A chart is a collection of files that describe a set of Kubernetes resources. It contains YAML templates with placeholder variables, a values.yaml file with defaults for those variables, a Chart.yaml file with metadata like name and version, and optionally a README and schema validation. Charts can be packaged as .tgz archives and shared via a repository.

A release is an instance of a chart installed in a Kubernetes cluster. If you install the same chart twice — once as staging-nginx and once as prod-nginx — you have two releases, each independent with its own configuration and upgrade history.

A repository is an HTTP server hosting packaged charts and an index file. The original stable repository was https://charts.helm.sh/stable but has been deprecated. Modern charts are hosted on Artifact Hub or on dedicated repositories maintained by each project.

Installing Helm and adding repositories

Helm is a single binary. On macOS install it with Homebrew; on Linux download it from the official release page or use the install script; on Windows use Chocolatey or the binary directly.

# macOS
brew install helm

# Linux (install script)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Verify
helm version

Add repositories before you can search for or install charts from them:

# Add the ingress-nginx chart repo
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

# Add Jetstack (for cert-manager)
helm repo add jetstack https://charts.jetstack.io

# Update your local repo cache
helm repo update

# Search for charts
helm search repo ingress-nginx
helm search hub cert-manager   # searches Artifact Hub

Installing and upgrading releases

Install a chart into your AKS cluster with helm install. The first argument is the release name; the second is the chart reference (repo/chartname or a local path).

# Create the namespace first
kubectl create namespace ingress-nginx

# Install ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.replicaCount=2 \
  --set controller.nodeSelector."kubernetes\.io/os"=linux

# Check release status
helm status ingress-nginx -n ingress-nginx

# List all installed releases across all namespaces
helm list --all-namespaces

To install cert-manager, which requires CRDs (Custom Resource Definitions) to be installed first:

# Install CRDs separately
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.crds.yaml

# Install cert-manager chart
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.14.4

When a new chart version is available or you want to change configuration, use helm upgrade:

# Upgrade to a new chart version
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --version 4.10.0 \
  --reuse-values

# Upgrade and change a value
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.replicaCount=3 \
  --reuse-values

—reuse-values carries forward all previously set values, so you only need to specify what changes. Without it, Helm resets to chart defaults for any value you do not explicitly provide.

Configuring charts with values.yaml

Every chart has a values.yaml file that defines the configurable parameters and their defaults. You override these by providing your own values file or using —set flags.

For production, create an environment-specific values file and commit it to source control. This makes your exact configuration reproducible and reviewable:

# prod-values.yaml
controller:
  replicaCount: 3
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  service:
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
  config:
    proxy-body-size: "50m"
    use-forwarded-headers: "true"

# Install using a values file
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  -f prod-values.yaml

# Combine a file with individual overrides
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  -f prod-values.yaml \
  --set controller.replicaCount=4

To see what values a chart accepts before installing it:

# Show the full default values.yaml for a chart
helm show values ingress-nginx/ingress-nginx

# Show only the chart metadata
helm show chart ingress-nginx/ingress-nginx

Rollbacks and release history

Helm stores the history of every upgrade for each release. If an upgrade breaks something, you can roll back to any previous revision.

# Show the history of a release
helm history ingress-nginx -n ingress-nginx

# Output looks like:
# REVISION  STATUS     CHART                    DESCRIPTION
# 1         superseded ingress-nginx-4.9.0       Install complete
# 2         superseded ingress-nginx-4.9.0       Upgrade complete
# 3         deployed   ingress-nginx-4.10.0      Upgrade complete

# Roll back to the previous revision
helm rollback ingress-nginx -n ingress-nginx

# Roll back to a specific revision
helm rollback ingress-nginx 1 -n ingress-nginx

# Verify after rollback
helm status ingress-nginx -n ingress-nginx

Rolling back a Helm release does not automatically roll back PersistentVolumeClaims or other stateful resources that were created by the chart. Data resources require separate handling.

Helm vs plain kubectl apply

For simple single-service applications, managing a handful of YAML files with kubectl is entirely reasonable. Helm adds value when the complexity grows.

Use kubectl for your own simple workloads. Use Helm when you are installing third-party software, managing applications that span many resource types, or deploying to multiple environments where configuration differs.

Uninstalling a release

helm uninstall removes all Kubernetes resources that were created by the release and deletes the release history:

# Uninstall a release
helm uninstall ingress-nginx -n ingress-nginx

# Keep history for auditing (resources still deleted)
helm uninstall ingress-nginx -n ingress-nginx --keep-history

# Dry run — show what would be deleted
helm uninstall ingress-nginx -n ingress-nginx --dry-run

Resources not created by Helm — such as PersistentVolumeClaims that were created dynamically by StatefulSets — are not deleted by helm uninstall. You must delete those manually.