What is the difference between `helm search repo` and `helm search hub`?

### Two commands, two corpora The word "search" hides a hard boundary. One command searches *your* configured world; the other searches *the public* world. They share a verb and almost nothing else. **`helm search repo`** iterates the cached `index.yaml` files for every repository listed in your `repositories.yaml`, matching your term against chart names, keywords and descriptions. Three consequences follow directly: 1. **It is offline.** No request leaves the machine. On a plane, or on an air-gapped build host, it still works. 2. **It is exactly as fresh as your cache.** If you have not run `helm repo update`, a version published this morning is not in the results, and a chart deleted from the repository last week still is. Search freshness and install resolution are the same freshness, which is at least consistent: what search shows you is what install will find. 3. **It sees your private repositories**, because those are entries in your own config. The `NAME` column it prints - for example `monitoring/monitoring-stack` - is a real, installable coordinate: repository alias, slash, chart name. That string is what `helm install`, `helm upgrade`, `helm pull` and `helm template` all take. **`helm search hub`** makes a live HTTP call to Artifact Hub, the public index of published Helm charts (and other cloud-native artefacts). It searches across thousands of repositories that other people run, whether or not you have ever added any of them, and you can point it at a self-hosted Artifact Hub instance if your organisation runs one. What comes back is a listing: a URL to the chart's page on the hub, the chart version, the app version, and a description. ### The trap in the output That `URL` column is the single most common misreading. It is a *web page*, not a chart coordinate and not a repository URL. `helm install my-rel https://artifacthub.io/packages/helm/...` will not work. The workflow after a hub search always has a step in the middle: open the listing, find the repository URL the publisher documents, `helm repo add` it, `helm repo update`, and only then `helm search repo` or `helm install` against the coordinate you now own. (If the publisher distributes over a registry instead, you reference the chart directly by its `oci://` URL, which is its own topic - no repository to add and nothing for `search repo` to see.) ### The flags that matter on the repo side Searching for a version you know exists and getting nothing back is usually one of three things: - **Only the newest version is shown by default.** `--versions` expands the output to every version of every matching chart in the index. When you are deciding what to pin an 18-chart umbrella to, this is the flag you want. - **Pre-releases are hidden.** Anything like `4.12.0-rc.1` is excluded unless you pass `--devel`. This is the same rule that governs which version an unpinned install picks, so it is worth internalising once. - **Matching is looser than you think.** Search matches descriptions and keywords as well as names, so a broad term over a big internal repository returns noise; `--regexp` lets you anchor the pattern, and `-o json` makes the result parseable in a script. An empty result from `helm search repo` also has a fourth cause that is not about flags at all: no repositories added. On a fresh CI runner the search legitimately returns nothing because `repositories.yaml` is empty. ### Which one is actually asked for In day-to-day operations, `search repo` is the one you use constantly - to check what versions exist before pinning, to confirm the alias you typed is real, to see whether the version a colleague published has reached your cache. `search hub` is a discovery tool: "is there already a community chart for this?" It is the command people forget exists, and an interviewer asking about it is usually probing whether you understand that Helm's search has *no* central registry behind it by default - your searchable universe is exactly the set of repositories you chose to add. That is the real conceptual point behind the pair. Helm has no built-in notion of a global namespace of charts. A repository alias is a local nickname you invented; the same chart may be `monitoring/monitoring-stack` on your laptop and `internal-mon/monitoring-stack` on your colleague's, and neither name means anything to anyone else. Artifact Hub exists precisely because Helm itself does not provide that global view.