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 valuestemplates/— Kubernetes manifest templatescharts/— 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
- Kubernetes Blog - Container orchestration
- Docker Blog - Container basics
- Homelab Blog - Self-host Kubernetes
// Comments
Leave a Comment