Alright, let’s talk about the one thing that makes Helm actually useful: repositories. Think of them as the app stores for your Kubernetes cluster. Without them, you’re just some weirdo hand-crafting YAML files in a dark room, which, don’t get me wrong, is a valid life choice, but it’s not why we’re here. We’re here to get stuff deployed.

A Helm chart repository is, at its heart, a very simple web server that hosts two things: the packaged charts themselves (the .tgz files) and a single, constantly updated index file named index.yaml. This index is the menu. It tells Helm what charts are available, their versions, and where to download them from. When you run helm repo add or helm repo update, you’re essentially telling Helm, “Hey, go check that website’s menu and see what’s new.”

Adding a Repository: helm repo add

Adding a repo is how you tell Helm about a new place to find charts. The canonical example is Bitnami’s repository, which is a fantastic source of well-maintained charts. The syntax is simple, but the magic is in the URL.

helm repo add bitnami https://charts.bitnami.com/bitnami

Boom. You’ve just told Helm, “From now on, when I say ‘bitnami’, I mean that URL.” Helm will go to https://charts.bitnami.com/bitnami/index.yaml, fetch the index, and store it locally. You can call it whatever you want; bitnami is just an alias. You could have called it my_awesome_charts if you were feeling particularly unhelpful to your future self.

Why does this matter? Because you can (and should) add your own private repositories! Any HTTP server that can serve an index.yaml and some .tgz files qualifies. This includes cloud storage (S3, GCS), GitHub Pages, or a simple NGINX server. The Helm CLI doesn’t care, as long as it can GET the files.

Updating Your Local Index: helm repo update

Here’s the first “gotcha.” When you add a repo, Helm downloads the index once. Charts get updated all the time. If you added the Bitnami repo a week ago, your local copy of its menu is a week out of date. Helm, brilliant but literal, will happily try to install a version of a chart that might as well be on papyrus.

helm repo update is your “go check for new menu items” command. It goes out to all the repositories you’ve added and re-fetches their index.yaml files. You should run this religiously before you install or upgrade anything. It’s the equivalent of apt update or brew update. It doesn’t change any deployed software; it just updates your local knowledge.

helm repo update
# Hang on, let me ask the internet what's new...

Searching for Charts: helm search repo

Now for the fun part: finding stuff. Once you’ve added and updated your repos, you can see what’s available. The most common command is helm search repo, which searches all the repositories you’ve added.

Want to see what MySQL options you have?

helm search repo mysql
# This will show you 'bitnami/mysql', 'my_awesome_charts/mysql', etc.

Want to see EVERYTHING from the Bitnami repo? You can use a wildcard.

helm search repo bitnami/*

The output shows you the chart name, its version, and a description. The version in this list is the latest version available in the repository. It’s not what you have deployed; it’s what you could deploy.

The Quiet Pitfall: Repository Order and Naming Conflicts

Here’s a sneaky one that will bite you eventually. Let’s say you add two repos:

helm repo add company-charts https://charts.mycompany.com
helm repo add bitnami https://charts.bitnami.com/bitnami

Now, both repos happen to have a chart named common-library. It’s a dumb name, but the developers were tired. When you run helm install my-app company-charts/common-library, Helm knows exactly what you mean.

But what if you get lazy and just run helm search repo common-library? Helm will show you both charts. The problem arises if you try to install with just the short name: helm install my-app common-library. Which one does it choose?

The answer is: it’s undefined. Helm will pick one essentially at random based on the order it queries the repos. This is a fantastic way to accidentally deploy the wrong thing. Always use the fully qualified name (repo/chart) in your commands. The few keystrokes you save are not worth the potential multi-hour outage.

Best Practices from the Trenches

  1. Update, Always Update: Make helm repo update a muscle memory action before any install or upgrade. Put it in your scripts. Yell at your colleagues who don’t do it.
  2. Use Fully Qualified Names: Never rely on the short name. bitnami/redis is clear; redis is a gamble. Don’t gamble with your cluster.
  3. Manage Your Repos: Use helm repo list to see what you’ve configured. Use helm repo remove <name> to clean up old repos you don’t use anymore. A clean repo list prevents mistakes and makes searching faster.
  4. Understand Your Source: Adding a repo is a trust operation. You’re telling Helm to go run code from that URL. Don’t just add random repositories you find on the internet. Know who maintains them. Bitnami? Great. “Cool-Charts-4-Free.xz”? Probably not great.

Repositories are the simple, beating heart of Helm. Master adding, updating, and searching them, and you’ve unlocked 90% of the value of the tool. The other 10% is trying to figure out why your values.yaml file isn’t overriding that one deeply nested configMap key. But that’s a problem for another section.