Helm: Kubernetes Package Manager

2026-03-21 • 14 min read • DevOps

You've deployed your application to Kubernetes. You've written the manifests for your Deployment, Service, ConfigMap, Secret, and all the other resources. It works. Now you need to deploy the same application to a different environment, or share it with your team. How do you manage all those YAML files?

Meet Helm—the package manager for Kubernetes. Helm lets you define, install, and upgrade even the most complex Kubernetes applications with a single command.

Why Helm?

Without Helm, managing Kubernetes applications means:

  • Copying and pasting YAML files between environments
  • Manually editing values for each environment
  • Tracking which version of each manifest is deployed where
  • Rolling back changes by hand when something goes wrong

Helm solves these problems by treating your Kubernetes manifests as a distributable package—a chart. With Helm you can:

  • Package — Bundle all your manifests into a single deployable unit
  • Configure — Use templating to customize deployments per environment
  • Release — Track versions and roll back when needed
  • Share — Use charts from the community or your organization

Core Concepts

Charts

A chart is a collection of files that describe a Kubernetes resourceset. It includes:

  • Chart.yaml — Metadata about the chart (name, version, dependencies)
  • values.yaml — Default configuration values
  • templates/ — Kubernetes manifest templates
  • charts/ — Dependency charts (optional)

Releases

A release is a running instance of a chart in a Kubernetes cluster. You can have multiple releases of the same chart in the same cluster (like deploying different versions for testing and production).

Repositories

A repository is a place where charts are stored and shared. Helm Hub (hub.helm.sh) is the central repository for community charts. You can also use private repositories.

Installing Helm

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

# Or via package manager
sudo apt-get install helm    # Debian/Ubuntu
brew install helm            # macOS

# Verify
helm version

Your First Chart

Let's create a simple chart for a web application.

# Create a new chart
helm create myapp

# This creates the following structure:
# myapp/
#   Chart.yaml
#   values.yaml
#   charts/
#   templates/
#   .helmignore

Chart.yaml

The Chart.yaml contains the chart's metadata:

apiVersion: v2
name: myapp
description: My web application
type: application
version: 1.0.0
appVersion: "1.0.0"

values.yaml

Default values that can be overridden at install time:

replicaCount: 2

image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: "latest"

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  className: ""
  annotations: {}
  hosts:
    - host: myapp.local
      paths:
        - path: /
          pathType: Prefix

resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

Templates

Templates use Go templating to generate Kubernetes manifests:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Chart.Name }}
    version: {{ .Values.image.tag }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
        version: {{ .Values.image.tag }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Installing and Upgrading

# Install a chart
helm install myapp ./myapp

# Install with custom values
helm install myapp ./myapp --set replicaCount=3

# Install from a repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install myapp bitnami/nginx

# Upgrade a release
helm upgrade myapp ./myapp

# Upgrade with new values
helm upgrade myapp ./myapp --set replicaCount=5

# Rollback to previous release
helm rollback myapp

Managing Values

Helm provides multiple ways to override values:

# Using a values file
helm install myapp ./myapp -f production.yaml

# Using --set (highest priority)
helm install myapp ./myapp --set replicaCount=10

# Combining files and --set
helm install myapp ./myapp -f production.yaml --set replicaCount=10

# Show computed values (including defaults)
helm show values ./myapp

# Get values from an existing release
helm get values myapp

Debugging Charts

# Dry run (see what would be created)
helm install myapp ./myapp --dry-run

# Dry run with debug (see template rendering)
helm install myapp ./myapp --dry-run --debug

# Lint a chart for errors
helm lint ./myapp

# Template locally (without installing)
helm template myapp ./myapp

Dependencies

Charts can depend on other charts. Add to Chart.yaml:

dependencies:
  - name: postgresql
    version: "12.x.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

Then update and install dependencies:

# Update dependency charts
helm dependency update ./myapp

# This creates charts.lock and downloads charts to charts/

# Install with dependency
helm install myapp ./myapp

Release Management

# List releases
helm list

# List releases in a namespace
helm list -n mynamespace

# See release history
helm history myapp

# See full release details
helm get all myapp

# Uninstall a release
helm uninstall myapp

Helmfile and GitOps

For managing multiple releases across environments, Helmfile provides a declarative way:

# helmfile.yaml
repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: myapp
    chart: ./myapp
    values:
      - values/production.yaml
    secrets:
      - secrets/production.yaml.gpg
Helm + Helmfile + GitOps = Reproducible deployments across environments

Common Charts to Know

  • bitnami/nginx — Web server
  • bitnami/postgresql — Database
  • bitnami/redis — Cache
  • prometheus-community/prometheus — Monitoring
  • grafana/grafana — Dashboards
  • ingress-nginx/ingress-nginx — Ingress controller
  • cert-manager/cert-manager — TLS certificates

Best Practices

  • Use semantic versioning for chart versions
  • Template everything — Avoid hardcoded values
  • Use named templates for repeated blocks
  • Validate with --dry-run before installing
  • Store charts in Git — Treat them as code
  • Use environments — Separate values files per environment

What's Next?

Once you're comfortable with Helm:

  • Operator Framework — Build operators that use Helm internally
  • Flux/ArgoCD — GitOps with Helm charts
  • Carvel ytt — Alternative templating for Kubernetes

Helm turns dozens of YAML files into a single deployable package. It makes Kubernetes accessible to teams, enables reproducible deployments, and lets you focus on shipping rather than managing manifests.

Learn More

// Comments

Leave a Comment