What does `helm pull --version` fetch, and when would you pull a chart instead of installing it straight from the repository?

### What pull actually does `helm pull` is the download half of `helm install` with the cluster half removed. It resolves a chart coordinate against your cached repository index, finds the download URL for the requested version, and writes the packaged `.tgz` to disk. No Kubernetes API server is contacted, no release record is created, no templates are rendered. The options are small and worth knowing exactly: - **`--version`** selects which published version to fetch. Without it you get the newest non-prerelease version the cached index knows about. - **`--devel`** allows pre-release versions such as `4.12.0-rc.1` to be considered. - **`--untar`**, optionally with **`--untardir`**, expands the tarball into a chart directory rather than leaving it packed. - **`-d` / `--destination`** chooses where the file lands. - **`--repo <url>`** pulls from a repository URL directly, without an entry in your configuration - which also means without a cached index or an alias. - **`--prov`** fetches the provenance file alongside the package, and **`--verify`** checks it; verification itself is a separate subject from repository consumption. The same auth and TLS flags a private repository needs are accepted here too, which is what makes `--repo` plus credentials a workable pattern for automation that should not persist configuration. ### Why you would pull rather than install **To read the thing before you run it.** A chart from a repository is opaque until you look inside. Pulling and untarring gives you the actual `templates/`, the real default `values.yaml`, and the dependency declarations - for a monitoring-stack chart with three subcharts, that is the only honest way to see what a single install will create. (`helm show values` and `helm show chart` answer narrower versions of the same question straight from the repository without unpacking.) **To diff two versions.** Pull 4.10.6 and 4.11.2 side by side and read the difference. Release notes describe intent; the packaged chart is what will actually be applied. This is the standard homework before an upgrade to a chart you do not own. **To mirror or vendor.** An air-gapped environment, or a build that must be reproducible next year, cannot depend on a repository still serving a version. Pulling the exact `.tgz` and storing it in an internal artefact store fixes the byte-for-byte input. The same move helps when an upstream repository is slow or flaky: your pipeline stops making a network call to someone else's server on every deploy. **To render offline.** `helm template ./monitoring-stack` against a pulled directory produces manifests for review, policy checking or a diff, with no repository access at all. ### The pinning half, which is the part that bites Omitting `--version` is a decision, not a default you can ignore. Helm resolves the coordinate to the newest non-prerelease version present in your cached index **at the moment the command runs**. Two things follow. First, an unpinned install or pull is not reproducible. The same pipeline, unchanged, deploys chart 4.10.6 in the morning and 4.11.2 in the afternoon because someone published in between. Nothing in your repository changed; nothing in review shows a difference; the deployed application did change. For a PDF-signing service where a chart bump alters resource requests or a probe path, that is an unattributable incident. Second, the resolution is against the *cached* index, so an unpinned command on a stale cache picks the newest version you happen to know about - which makes the behaviour depend on when each machine last refreshed. Two engineers running the identical command get different charts. Pinning removes the whole class of problem: an exact `--version` either resolves or fails loudly, and failing loudly is the good outcome. `--version` accepts a constraint expression as well as an exact string, so a range is possible; a range is a *policy*, not a pin, and it reintroduces the moving target if you use it in a deploy path. Range semantics themselves are a general versioning topic. One boundary worth being precise about: pinning `--version` pins the chart artefact you fetch. Whether that chart's own bundled dependencies are equally fixed is a property of how the chart was packaged, not of your pull command. On an 18-chart umbrella, that distinction is the difference between "we know what we deployed" and "we know what the top of it was called". ### The everyday sequence In practice the reviewed workflow is: search for the versions that exist, pull the specific one, read or diff it, then install that same exact version - never a bare coordinate that resolves to whatever is newest at deploy time.