Most infrastructure software you’d run in Kubernetes, monitoring stacks, ingress controllers, databases, already has a published chart. This guide covers finding one, checking what it actually installs before you commit to it, and overriding its defaults for your environment.

Search without adding a repository first

helm search hub prometheus

helm search hub queries Artifact Hub, the CNCF’s index of charts (and other cloud-native packages) from many different repositories, without needing that repository added locally first. It’s the quickest way to see what’s out there and who publishes it. Browsing artifacthub.io directly gives you the same catalog with a better interface for comparing options, reading a chart’s README, and checking how recently it was updated. (This search used to go through a separate “Helm Hub”; that service was retired in 2020 and folded into Artifact Hub, so helm search hub has queried Artifact Hub for years now.)

Add a repository and search what’s added

Once you’ve picked a source, add it and search locally:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm search repo prometheus-community

helm repo add registers a chart repository by name; helm repo update refreshes Helm’s local index of what each added repository offers. helm search repo (note: repo, not hub) only searches repositories you’ve already added, which is what you’ll use day to day once you know where your charts come from. helm repo list shows everything currently registered.

Inspect a chart before installing it

Never install a chart blind, especially one with broad permissions or that manages storage:

helm show chart prometheus-community/prometheus
helm show readme prometheus-community/prometheus
helm show values prometheus-community/prometheus

show chart gives you the metadata (version, maintainers, dependencies). show readme is the publisher’s own installation and configuration notes, usually the fastest way to learn what a chart expects. show values prints its entire default values.yaml, which is the real reference for what you can override, more complete than any README.

Install with your own overrides

helm install monitoring prometheus-community/prometheus \
  -n monitoring --create-namespace \
  --set server.retention=15d \
  --set alertmanager.persistentVolume.size=10Gi

--create-namespace saves a separate kubectl create namespace step. Everything from the environment-specific values guide applies here too: for anything beyond a quick test, write your overrides into a values file and pass it with -f rather than accumulating --set flags, so what you installed is reproducible from a file in version control.

# monitoring-values.yaml
server:
  retention: 15d
alertmanager:
  persistentVolume:
    size: 10Gi

helm upgrade --install monitoring prometheus-community/prometheus \
  -n monitoring --create-namespace -f monitoring-values.yaml

Pin a version deliberately

Without --version, helm install uses the latest chart version available, which can change between when you write a values file and when you actually run the command:

helm search repo prometheus-community/prometheus --versions
helm install monitoring prometheus-community/prometheus --version 25.8.0 -n monitoring

Pinning a version is standard practice for anything beyond a local experiment, for the same reason you’d pin a container image tag rather than floating on latest: it’s the difference between a deploy you can reproduce and one you can only hope was the same as last time.