To install Helm in Minikube, install the Helm CLI on your host with the official script or a package manager, then point it at your running cluster. Helm reads the same kubeconfig kubectl already uses, so nothing gets installed inside Minikube itself. Run helm version, then deploy a chart with helm install.
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4, chmod 700 get_helm.sh and ./get_helm.sh. Verify with helm version, then install a chart: helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo. Nothing is deployed to the cluster until you install a chart.The most common misconception about Helm is that you must install a server component into the cluster first. You do not, and have not since 2019. Getting that straight saves you from a mountain of outdated tutorials.
get-helm-4, not get-helm-3. Helm 3 is on a wind-down: a final limited feature release is due 9 September 2026, security patches continue to roughly February 2027, and after that nothing. Install Helm 4 unless you have a specific reason not to.What Helm is, and why there is no Tiller
Helm is a package manager for Kubernetes. A chart bundles templated manifests plus a values.yaml of defaults. You install it with your own values, Helm renders the templates and applies the result, and records what it did as a “release” you can upgrade or roll back.
Helm 2 had a cluster-side component called Tiller that held release state and applied manifests for you. It was a security problem: Tiller ran with broad permissions and there was no clean way to scope them per user. Helm 3 deleted it in 2019. Release state moved into Kubernetes Secrets in the release’s namespace, and the CLI applies changes using your own kubeconfig credentials and RBAC. Helm 4 kept that model.
So there is nothing to helm init, no service account to create, no --tiller-namespace flag. If a guide tells you to run helm init, everything else in it is suspect too.
Step 1: Get a cluster running first
Helm needs a reachable cluster first. Start Minikube and confirm kubectl can talk to it:
minikube start --driver=docker
kubectl get nodes
kubectl config current-contextkubectl config current-context should print minikube. Helm uses that same context, so whatever kubectl is pointed at is where your charts will land. If you do not have a cluster yet, start with our guides to installing Minikube on Ubuntu or installing Minikube on Windows 10.
Step 2: Install the Helm CLI
Helm is a single static binary. Pick the route that matches your machine.
| Method | Command | Notes |
|---|---|---|
| Official script (Linux, macOS) | ./get_helm.sh from get-helm-4 | Always the newest stable Helm 4 |
| apt (Debian, Ubuntu) | sudo apt-get install helm | Needs the Helm repository added first, with a key fingerprint check |
| snap | sudo snap install helm --classic | One line, auto-updates, least control over version |
| Homebrew (macOS) | brew install helm | The path of least resistance on a Mac |
| Chocolatey (Windows) | choco install kubernetes-helm | Note the package name is not “helm” |
| Scoop (Windows) | scoop install helm | Good if you already use Scoop for kubectl |
The script route, straight from the official Helm install docs:
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4
chmod 700 get_helm.sh
./get_helm.shscripts/get-helm-3 is installing a version that stops receiving even security patches in early 2027. The current script is get-helm-4. Same goes for the old curl ... | bash one-liners: download the script, look at it, then run it.Step 3: Verify
helm version
helm envhelm version prints the client version and git commit. There is no server version to report, which is the Tiller point made concrete. helm env shows the cache, config and data directories.
Step 4: Add a chart repository
Charts come from two kinds of source: classic HTTP repositories with an index.yaml, and OCI registries. Helm 4’s own quickstart leads with OCI, which is where the ecosystem has moved.
# Classic HTTP repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm repo list
# OCI registry, no repo add needed
helm show chart oci://registry-1.docker.io/bitnamicharts/nginxThe Bitnami change you need to know about
Bitnami used to be the default answer for “which chart should I use”. That changed on 28 August 2025. Broadcom restructured the catalog:
- The free
docker.io/bitnamiregistry now carries only a limited subset of hardened images, and only on thelatesttag. Bitnami describes these as intended for development. - Older and versioned image tags moved to
docker.io/bitnamilegacy. Those images receive no updates, fixes or support, and Bitnami says they exist only as a temporary migration fallback. - The full catalog of 280-plus apps with versioned, continuously rebuilt images sits behind a paid Bitnami Secure Images subscription.
- Charts are published to an OCI registry at
oci://registry-1.docker.io/bitnamicharts/<chart>and reference hardened Photon-based images now, not the old Debian ones.
In practice, a Bitnami chart pinning a versioned image tag will fail to pull unless you subscribe or redirect the image repository at bitnamilegacy. That is why so many working helm install commands broke in late 2025. Check the Bitnami charts repository first. These charts need Kubernetes 1.23+ and Helm 3.8+, which Minikube satisfies easily.
Step 5: Search and install your first chart
# Search Artifact Hub across every public repository
helm search hub podinfo
# Inspect before installing
helm show chart oci://ghcr.io/stefanprodan/charts/podinfo
helm show values oci://ghcr.io/stefanprodan/charts/podinfo
# Install it
helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfoGet into the habit of helm show values before helm install. It prints the chart’s full default configuration, the only reliable way to know what knobs exist. In anything repeatable, pin the version with --version and whatever helm show chart reported. A dry run renders the manifests without touching the cluster:
helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo --dry-run
helm template my-podinfo oci://ghcr.io/stefanprodan/charts/podinfoStep 6: List, upgrade, roll back, uninstall
helm list
helm list --all-namespaces
helm status my-podinfo
# Change something
helm upgrade my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo --set replicaCount=3
# See every revision
helm history my-podinfo
# Go back one revision, or to a specific one
helm rollback my-podinfo
helm rollback my-podinfo 1
# Remove it
helm uninstall my-podinfohelm rollback works because Helm stores each revision’s rendered manifests in a Secret in the release namespace; see them with kubectl get secret -l owner=helm. It simply reapplies an old manifest set, so anything outside Helm’s control, notably PersistentVolumeClaim data, does not travel back with it. helm uninstall deletes the release history too unless you pass --keep-history.
Step 7: Override values
Two ways to change a chart’s configuration, and you will use both.
# Inline, for one or two values
helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo --set replicaCount=2 --set service.type=NodePort
# From a file, for anything real
helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo -f values.yaml
# Both, and -f files later in the list win over earlier ones
helm install my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo -f base.yaml -f minikube.yaml --set replicaCount=1A minimal values.yaml for a Minikube cluster:
replicaCount: 1
service:
type: NodePort
resources:
requests:
cpu: 50m
memory: 64MiUse --set for experiments and a file for anything you run twice. Values files belong in version control; a 400-character --set chain does not. Check what a release got with helm get values my-podinfo.
Step 8: Reach the chart’s service from your host
This is where Minikube differs from a cloud cluster, and it catches everyone once. Minikube has no cloud load balancer, so a chart whose service defaults to type: LoadBalancer sits at <pending> forever. Three ways out, in the order I reach for them locally:
# 1. Port-forward. Simplest, no cluster changes.
kubectl port-forward svc/my-podinfo 9898:9898
# 2. NodePort via a values override, then ask minikube for the URL
helm upgrade my-podinfo oci://ghcr.io/stefanprodan/charts/podinfo --set service.type=NodePort
minikube service my-podinfo --url
# 3. Keep LoadBalancer and run a tunnel in a separate terminal
minikube tunnelminikube tunnel creates a network route on your host to the cluster’s service CIDR. It needs elevated privileges, so it prompts for a password, and it must stay running in its own terminal. Close it and your LoadBalancer IPs stop answering.
Troubleshooting
“Kubernetes cluster unreachable”
Helm found no working cluster in your kubeconfig. Nine times out of ten, Minikube is stopped. Work through it in order:
minikube status
kubectl cluster-info
kubectl config current-context
kubectl config get-contexts
# Wrong context?
kubectl config use-context minikube
# Custom kubeconfig location?
echo $KUBECONFIG
helm list --kubeconfig ~/.kube/configThe other common cause is a kubeconfig left behind by running sudo minikube start. Helm, running as you, reads a stale or empty ~/.kube/config. Delete the cluster and recreate it without sudo.
A PVC stuck in Pending
Many charts request persistent storage. On Minikube the storage-provisioner addon handles that, and it is enabled by default, so a Pending PVC usually means something else. Diagnose in this order:
kubectl get pvc
kubectl describe pvc <name>
kubectl get storageclass
minikube addons list | grep storageThe events at the bottom of describe tell you the truth. Three usual culprits: the chart asked for a storageClassName that does not exist here, so override it to standard; it requested more space than the node has free, so lower it in your values file; or it asked for ReadWriteMany, which Minikube’s default provisioner does not offer on a single node. Drop that to ReadWriteOnce.
Image pull failures
Since the Bitnami change this is the most frequent Helm-on-Minikube failure. Find out what image the pod actually wants:
kubectl get pods
kubectl describe pod <name> | tail -20
kubectl get events --sort-by=.lastTimestampAn ImagePullBackOff on a docker.io/bitnami/<something>:<version> tag means that versioned tag is no longer in the free registry. Your options are to subscribe to Bitnami Secure Images, temporarily point image.repository at bitnamilegacy while you migrate, or switch to a different chart. Unauthenticated Docker Hub pull rate limits are the other frequent cause, and docker login on the host does not help because the pull happens inside the Minikube node.
Helm 3 to Helm 4 upgrade wrinkles
Helm 4 ships intentionally backward-incompatible changes to CLI flags, CLI output and the Go SDK. Charts are mostly fine, since apiVersion: v2 charts are still supported. Scripts and CI pipelines are where it bites, especially anything parsing Helm’s stdout.
Frequently asked questions
Do I need to install Helm inside Minikube?
No. Helm is a client-side binary that runs on your machine and talks to the Kubernetes API using your kubeconfig. Nothing is deployed into the cluster until you install a chart, and release state lives in ordinary Kubernetes Secrets. The old Tiller server component was removed in Helm 3 back in 2019.
Which Helm version should I install in 2026?
Helm 4. It shipped in November 2025 and the current line is 4.2.x. Helm 3 gets a final limited feature release in September 2026 and security patches only for a few months after that. Only stay on Helm 3 if a specific tool you depend on has not caught up.
Can I still use the Bitnami charts on Minikube?
Yes, with a caveat. The charts are still published and maintained at oci://registry-1.docker.io/bitnamicharts, but since August 2025 the free image registry only carries a limited hardened subset on latest tags. If a chart pins a versioned tag, the pull will fail unless you have a Bitnami Secure Images subscription or you redirect to bitnamilegacy.
How do I see what a chart will create before installing it?
Use helm template <name> <chart> to render every manifest to stdout without contacting the cluster, or helm install --dry-run to render with cluster context but change nothing. Pair either with helm show values to see the full list of configurable defaults first.
Why is my chart’s service stuck on pending?
The chart created a LoadBalancer service and Minikube has no cloud provider to assign an external IP. Either run minikube tunnel in a separate terminal, or override the service type to NodePort and use minikube service <name> --url. For a quick look, kubectl port-forward is faster than both.
Does helm rollback restore my data?
No. Rollback reapplies a previous revision’s manifests. It does not touch the contents of a PersistentVolumeClaim, and it will not undo a database migration your application ran. Treat rollback as a way to recover a broken configuration, not as a backup strategy.
Wrapping up
Installing Helm is a three-line job. The real work is elsewhere: knowing Tiller has been gone for years, that the script is now get-helm-4, and that Bitnami’s free catalog is not what it was. Those three facts prevent most of the confusion people hit on their first afternoon with Helm.
Practice the full loop on a throwaway chart first: install, helm list, upgrade with --set, helm history, roll back, uninstall. Ten minutes of that on Minikube beats an hour of reading, and it costs nothing to break.

