What does `helm version` report, and what does it tell you about the cluster?

### What the command actually prints `helm version` reports build information about one thing: the executable you just ran. The output carries the semantic version, the Git commit it was built from, the tree state at build time, and the Go version used to compile it. `--short` collapses it to a single line, and `--template` lets a script pull out one field rather than parsing the whole struct. Notice what is absent: a server line. In Helm 2 the command printed both a client and a server version, because Helm 2 had a cluster-side component that did the actual work. That component was removed in Helm 3, and Helm 4 did not reintroduce it. Modern Helm is a single binary that renders charts locally and talks to the Kubernetes API directly, with release state stored in the namespace as ordinary Secrets. There is no Helm process running in your cluster whose version could be reported — which is exactly why candidates who learned Helm 2 are still surprised by the one-line output. ### Why the client version is worth knowing anyway "Only the client" is not the same as "unimportant". The client is the whole implementation, so its version determines behaviour that a chart author cannot control from inside the chart: - **The write path.** Helm 4 makes server-side apply the default for installs, while Helm 3 used a client-side three-way merge. Two engineers running different majors against the same release are not doing the same thing. - **Flag semantics.** `--wait` is boolean in Helm 3 and strategy-valued in Helm 4, where omitting it means Helm does not wait for workloads at all. A script written for one and run under the other behaves differently without erroring. - **Template functions.** Helm 4 adds a duration function family that simply does not exist in Helm 3, so a chart using it renders on one machine and fails on another. - **Removed commands.** `helm list -a` was removed in Helm 4, so a script carrying that flag fails outright rather than degrading. All of which makes `helm version` a reasonable first line of any bug report, and the version of the binary in a CI image something to pin rather than to install as "latest". ### What to check when you actually want a cluster fact If the question behind "what version are we on" is really about the cluster, `helm version` is the wrong command entirely. The facts that exist on the cluster side are: - **The Kubernetes API server's version**, which the API server reports itself. This is what determines whether an API group a chart renders still exists, and Helm asks the API server for it when rendering against a live cluster. - **The release records** in the target namespace, which say what is installed, at which revision, from which chart version — information you read with the release-inspection commands, not with `version`. Keeping those separate is the point of the question. A candidate who answers "`helm version` shows the client and the server" has a mental model in which something Helm-shaped is running in the cluster, and that model produces wrong conclusions elsewhere: it suggests there is a component to upgrade, a component to secure, a component whose logs explain a failed release. None of those exist. ### In practice Print `helm version --short` at the top of every deploy job's log. It costs one line, it makes the "which client did this" question answerable months later, and on the day a runner image quietly moves from one major to another it is the difference between a five-minute diagnosis and a long afternoon.