In Helm 4, how does helm template differ from helm install --dry-run=client and --dry-run=server?

### Three previews, three different amounts of reality When someone says "let me dry-run it first", they could mean any of three things in Helm, and the three catch different classes of bug. **`helm template`** renders the chart locally and prints YAML. No release is created, nothing is applied, and by default no cluster is contacted. It catches template bugs only: a missing value, a mis-scoped dot, a helper that produced the wrong string. **`helm install --dry-run=client`** takes the same chart through the install code path but stops before writing. It behaves like a real install right up to the apply: the client goes through its normal cluster connection, so in practice it wants a reachable cluster and a valid kubeconfig, and the render sees the target cluster's discovered API versions rather than a built-in default list. What it does not do is send the manifests anywhere for checking — the API server never sees them, so it cannot tell you whether the fields you wrote exist. **`helm install --dry-run=server`** does send them. The manifests go to the API server as a server-side dry run: the request is fully processed — decoded, defaulted, validated against the schema for that resource, and run through admission — and then discarded instead of being persisted. That is the only one of the three that will tell you that you wrote `contaienrs`, that a required field is missing, that a value is the wrong type, or that a cluster-wide admission policy will reject the object. Nothing is created; there is nothing to clean up afterwards. ### The Helm 4 detail that trips people up In Helm 3, `--dry-run` was a boolean: you passed it or you did not. **In Helm 4 it takes a value — `client` or `server`** — so an interview answer that says "just add `--dry-run`" is describing the old CLI. Write the value explicitly and the intent is unambiguous to the next reader as well as to Helm. `helm template` accepts `--dry-run` too, which is how you get the API server to look at an otherwise offline render. Helm 4 also marks `--validate` — the older flag that meant "check the rendered manifests against the API server" — as **deprecated in favour of `--dry-run=server`**, and the two are **mutually exclusive**: passing both on `helm template` is rejected rather than silently resolved, because they are two switches for the same decision and Helm refuses to guess which one you meant. ### Choosing between them Use `helm template` when the question is "what YAML does this chart produce?" — it is fast, offline, scriptable, safe on a laptop with no cluster credentials, and it is the right thing to run in a pipeline stage that has no business holding cluster access. Use `--dry-run=client` when you want the install path itself exercised — release naming, values plumbing, capability discovery against the real target — without a write. Use `--dry-run=server` when the question is "will the cluster accept this?" A render can be flawless YAML and still be nonsense to Kubernetes; only the API server knows its own schema and only the cluster knows its admission rules. This is the check worth wiring into a pipeline before a production upgrade, and it needs a credential with enough access to make the request. ### What a green dry run still does not promise A server-side dry run validates each object in isolation, at this moment, in a cluster whose current state may not be the state at apply time. It does not tell you that a hook Job will succeed, that a workload will become ready, that quota will still allow the objects when the real apply runs, or that an object depending on something the dry run did not actually create will behave. Admission decisions can also depend on the request being a genuine write. Treat a green dry run as "the shapes are right and nothing rejected them out of hand", not as a guarantee about the rollout. ### Practical habit Render offline while you iterate on the chart, because the loop is a second long and needs nothing. Switch to a server-side dry run once the YAML looks right, because that is the cheapest way to learn about a typo'd field or a policy rejection before it becomes a half-applied change. Keep the values flags identical between the two runs — the whole value of the comparison is that only the amount of cluster involvement changed.