How to Use Helm: The Beginner's Guide (First Chart, the Values Rule, First Release, and the Rollback Lesson)

CodexFuse Team · 2026-10-29T15:54:33.912Z · 10 min read

Helm is the package manager for Kubernetes. Install it, deploy your first chart, master the values rule, build your own chart, and upgrade or roll back releases — one beginner guide.

If you have ever deployed an app to Kubernetes by hand, you know the pain: a deployment file, a service file, a configmap, an ingress, a secret — five or six YAML files that have to agree with each other, and you get to repeat that dance for every environment. Learning how to use Helm replaces that folder of files with one command. Helm is the package manager for Kubernetes: it bundles everything an app needs into a versioned package called a chart, then installs, upgrades, and rolls back that package for you. This beginner's guide runs the whole loop in one sitting: install Helm, deploy your first chart, master the values rule, build your own chart, upgrade it, and roll it back when something goes wrong.

A working Kubernetes cluster is the only real prerequisite here — a local Docker-based lab with kind or minikube is plenty for everything below. If your cluster lives on rented machines instead, our guide to what VPS hosting is explains the server layer underneath the nodes.

How do you use Helm? The 60-second answer

To use Helm, you install the Helm CLI, add a chart repository, and run helm install to deploy a packaged app as a release. Customization happens through a values.yaml file, upgrades through helm upgrade, and broken deployments are undone with helm rollback. That loop — install, customize, upgrade, roll back — is the entire job.

1. Install Helm — grab the binary with your package manager or the official install script, then confirm with helm version.
2. Add a chart repository — helm repo add followed by helm repo update downloads the catalog of available charts.
3. Find a chart — helm search repo looks through the catalog; Artifact Hub is the searchable index of public charts.
4. Install it as a release — helm install my-app repo/chart-name creates a named, trackable instance of the chart.
5. Customize with values — override defaults with --set key=value for one-liners or -f my-values.yaml for files.
6. Upgrade — helm upgrade my-app repo/chart-name (or --install to create-or-upgrade in one step) ships a new version.
7. Roll back — helm rollback my-app 1 returns the release to an earlier revision if the upgrade misbehaves.

What is a Helm chart, and what is a release?

A chart is the package: a folder of Kubernetes templates plus default settings. A release is what you get when Helm installs a chart into your cluster — a live, named instance it can track, upgrade, and roll back. One chart can produce many releases: the same nginx chart becomes your dev site, your staging site, and your production site, each with different values.

Helm calls itself the Kubernetes package manager for a reason: the mental model is apt-get or Homebrew, but for cluster workloads instead of programs. Charts are versioned, so you can pin exactly which package version every environment runs.

How do you install Helm?

You install Helm the way you install any developer tool: a package manager on your machine, or the project's official install script. On macOS that is brew install helm, on Windows choco install kubernetes-helm or winget install Helm.Helm, and on Linux the official script from the Helm docs (curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash, as shown in the community hands-on guide on dev.to). After installing, run helm version — you want a 4.x release.

Version choice matters more than usual right now. Helm 4 shipped on November 12, 2025, and the current line is 4.3.x (4.3.1 landed October 15, 2026), while Helm 3 is on security-fixes-only support that ends February 10, 2027, after which it gets no updates at all, including security patches. New beginners should install the 4.x line; charts written for Helm 3 (apiVersion v2) work unchanged on Helm 4, so almost nothing you learn will be version-locked.

How do you install your first chart?

You add a repository, refresh its catalog, search it, and install. Repositories are the "app stores" of the Helm world, and helm repo add registers one by name so you can refer to its charts with a short prefix like ingress-nginx/ingress-nginx.

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo ingress-nginx
helm install my-ingress ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace

Then inspect what Helm did:

helm list
helm status my-ingress
kubectl get pods -n ingress-nginx

helm list shows every release Helm manages; helm status tells you that release's health and history. The ingress-nginx chart above is a good first demo because its repository is actively maintained — its index is live as of this writing.

The Bitnami warning every 2026 tutorial skips

Most older Helm tutorials start with helm repo add bitnami https://charts.bitnami.com/bitnami. Do not copy that line blindly. Bitnami moved its charts to OCI distribution in November 2024, and in August 2025 it stopped publishing new container images and Helm charts as it shifted to paid Bitnami Secure subscriptions — the free catalog went read-only and legacy. The OCI format still works (helm install my-nginx oci://registry-1.docker.io/bitnamicharts/nginx), but those charts are frozen in time and their defaults can point at image tags that no longer receive updates.

For a beginner lab this is fine; for anything real, pick charts whose maintainers still publish — the ingress-nginx chart above, or charts found on Artifact Hub with recent activity. For databases in particular, community-maintained operators (CloudNativePG for PostgreSQL, for example) are the current recommendation now that the Bitnami database charts are frozen.

What is the values rule?

The values rule is the one habit that separates comfortable Helm users from confused ones: --set is for one-line overrides on the command line; -f is for values files you keep in version control. A chart's values.yaml holds every setting the chart exposes — replica counts, image tags, service types. You never edit the chart's own copy; you supply your own file and let Helm merge them, with your file winning.

# Peek at what a chart exposes before you change anything
helm show values ingress-nginx/ingress-nginx > my-values.yaml

# Then install with your file
helm install my-ingress ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  -f my-values.yaml

One-off tweaks still use --set: helm install my-app ./mychart --set replicaCount=3. But the moment a command line has three --set flags, write a file instead — Helm 4 even lets you split complex values across multiple YAML documents, which keeps per-environment files readable. Because values files are just YAML, a quick pass through a YAML validator before you deploy saves you from the indentation errors that break half of all first-time installs.

How do you build your own chart?

You run helm create, edit two files, and install from the folder. helm create mychart scaffolds a working example chart — Chart.yaml (the chart's name and version), values.yaml (its defaults), and a templates/ folder of Kubernetes manifests written in Go-template syntax that reads those values.

helm create mychart
# render the templates locally to see what Helm will send the cluster
helm template mychart ./mychart
# check the chart for common mistakes
helm lint ./mychart
# install your chart as a release
helm install my-app ./mychart

Because chart authoring means writing a lot of YAML by hand, keep a YAML formatter open beside your editor — it catches the indentation mistakes that break templates. Three distinctions beginners mix up: helm template only renders the YAML (nothing touches the cluster), helm lint checks the chart's structure, and helm install actually deploys. The other classic confusion is chart version vs. appVersion: the chart version is the version of the package (you bump it every time you change the chart), while appVersion is the version of the application inside (the nginx version, say). They move independently, and mixing them up makes upgrades lie to you.

How do you upgrade and roll back a release?

You upgrade with helm upgrade and undo with helm rollback, and Helm remembers every step in between. Each install or upgrade creates a new revision of the release, and helm history lists them so you can see exactly when things changed and whether each change succeeded.

# change a value, then ship it
helm upgrade my-app ./mychart -f prod-values.yaml

# the create-or-upgrade form CI pipelines live on
helm upgrade --install my-app ./mychart -f prod-values.yaml

# see the release's history
helm history my-app

# something broke? go back to revision 1
helm rollback my-app 1

Rollback is Helm's killer feature over plain kubectl apply: reverting a bad deploy is one command, not a panicked re-application of yesterday's files from memory. When you are done experimenting, helm uninstall my-app removes everything Helm created — pods, services, configmaps — cleanly.

Should you use Helm or Kustomize?

Use Helm when you want to package and share applications; use Kustomize when you want to customize the same manifests per environment without a packaging step. They overlap on the customization job, but their philosophies differ, and plenty of teams use both — Kustomize to shape raw manifests, Helm to package the result.

The beginner rule of thumb: if you would search for an existing package (a database, an ingress controller, a monitoring stack), reach for Helm. If you are writing the manifests yourself and dev differs from prod by a handful of fields, Kustomize is the lighter tool. Knowing the difference matters because Helm 4's packaging lane and Kustomize's patching lane solve different halves of the same deployment problem.

What changed in Helm 4?

Helm 4 (November 2025) is the first major release since Helm 3 dropped Tiller in 2019, and it modernizes how Helm talks to the cluster. If you are starting now, learn the new defaults; if you inherit Helm 3 scripts, test them before trusting them.

The practical takeaway: your Helm 3 charts and releases migrate to Helm 4 without rewrites, but audit your scripts for the renamed flags and your pipelines for executable post-renderers — those are the two breaking changes that bite.

Sources

• Helm official docs — "Helm 4 Overview" (helm.sh/docs/overview/): server-side apply default for new releases, kstatus integration, WebAssembly plugin runtime, OCI digest installs, multi-document values, --atomic → --rollback-on-failure and --force → --force-replace renames, post-renderers as plugins, v2 charts working unchanged. Fetched 2026-10-29.
• Dev News Daily — "Helm 3.22.1 ships with under four months of security support left: what Helm 4 asks of you" (devnews.news): Helm 4.3.1 and Helm 3.22.1 shipped October 15, 2026; Helm 3 security support ends February 10, 2027; Helm 4.0.0 released November 12, 2025. Fetched 2026-10-29 via search.
• Bitnami blog — "Bitnami Helm charts moving to OCI" (blog.bitnami.com, October 2024): charts defaulted to OCI on November 18, 2024; index.yaml kept as an OCI artifact for helm repo add backward compatibility; tgz charts frozen; new installs use oci://registry-1.docker.io/bitnamicharts/… Fetched 2026-10-29.
• Kadet Hub — "Bitnami PostgreSQL chart alternatives" (kadet-hub.org, October 21, 2026): since August 28, 2025 Bitnami publishes no new container images or Helm charts; versioned tags moved to the read-only bitnamilegacy repository; CloudNativePG as the low-friction PostgreSQL alternative. Fetched 2026-10-29 via search.
• WebCodingCenter — "Helm 4 – Packaging BookNest with Helm" (webcodingcenter.com, updated ~October 2026): Helm 4.0.0 shipped November 12, 2025; 4.3.0 and 3.22.0 shipped together September 9, 2026; server-side apply vs client-side three-way merge table; --wait watcher; flag renames. Fetched 2026-10-29 via search.
• Dev.to (Latchu) — "Helm for Beginners — What, Why, and First Hands-On Task on GKE Cluster" (dev.to, November 2025): official get-helm-3 install script command, helm repo add/update/search/install flow, helm list/status/uninstall lifecycle. Fetched 2026-10-29 via search.
• Dev.to (DevCorner) — "Helm Installation and Usage Guide for Kubernetes (Step-by-Step)" (dev.to): helm repo add bitnami flow, helm search/install/upgrade/uninstall, helm show values customization, helm history/rollback, helm create chart anatomy. Fetched 2026-10-29 via search.

Frequently Asked Questions

Do I need Helm 4, or is Helm 3 still fine?

Install Helm 4. Helm 3 is on security-fixes-only support that ends February 10, 2027, after which it receives no updates at all. Helm 4 runs Helm 3-era (apiVersion v2) charts unchanged, so you lose nothing by starting on the new line.

Is Helm still worth learning if I use Argo CD or Flux?

Yes — they are not rivals. Argo CD and Flux deploy things to your cluster; Helm packages the things into versioned, templated releases. Helm 4's server-side apply default was designed to make Helm and GitOps tools coexist on the same resources without field-ownership fights.

What is the difference between a chart and a release?

A chart is the package (templates plus default values); a release is that package installed in your cluster under a name. One chart can produce many releases — dev, staging, and prod can all run the same chart with different values files.

Why did my Helm install fail pulling a Bitnami image?

Bitnami froze its free catalog on August 28, 2025 and moved images to a read-only legacy repository. Charts published before the freeze reference image tags that no longer update. For a lab it is harmless; for anything real, use charts whose maintainers still publish, and override image tags explicitly.

Does Helm replace Kustomize?

No. Helm packages and versions applications; Kustomize patches plain manifests per environment without templating. Use Helm for distributable apps and third-party software, Kustomize when dev and prod differ by a handful of fields. Many teams use both.