In Helm 4, what does --server-side default to on helm install versus helm upgrade?

Server-side apply is the write path in which the client sends the whole object it wants to exist and the API server performs the merge, recording which manager set which field. Helm 4 made that its default way of writing rendered manifests, in place of the client-side patch that Helm 3 constructed itself. The flag that controls it is `--server-side`, and its most surprising property is that it is not the same *kind* of flag on every command. ## install: a boolean that is already true On `helm install`, `--server-side` is a plain boolean whose default is `true`. Nothing needs to be passed: a Helm 4 install applies server-side out of the box, and the opt-out is the explicit `--server-side=false`. That is the whole story for a brand-new release, and it is why teams that adopted Helm 4 on a greenfield cluster often never think about the flag at all. ## upgrade and rollback: a string whose default is "auto" On `helm upgrade` and `helm rollback` the same flag name takes a **string**, and its default is `"auto"`. `auto` is not a synonym for `true`. It means *use whatever apply method the previous revision of this release used*. Helm records the method a revision was written with, and `auto` reads it back and reuses it. The values `true` and `false` are also accepted on those commands and force the choice regardless of history. ## Why inheritance instead of a flat default A release is long-lived; the CLI that drives it is not. If the first Helm 4 upgrade of an existing release silently switched the write path, a routine chart bump would become an ownership renegotiation across every object in the release. Under server-side apply the API server begins tracking which manager owns each field, and every field some other actor already owns is a candidate for a conflict that stops the upgrade. Inheriting keeps the version bump boring: your first Helm 4 upgrade of a Helm 3 release writes exactly the way the previous one did, and you choose a separate, deliberate moment to change the write path. ## The consequence people trip on Because `auto` is sticky, a release installed under Helm 3 stays on the client-side three-way merge indefinitely, even after every operator in the team has been on Helm 4 for months. Two releases sitting side by side in the same namespace can be written by two different mechanisms, and they will behave differently the first time somebody hand-edits a field on a live object or another controller writes to one. "We are on Helm 4, so we are on server-side apply" is therefore false for exactly the releases that have been around longest, which are usually the ones that matter. The same stickiness applies in reverse: once a revision has been applied server-side, `auto` keeps later upgrades — and rollbacks — server-side. ## Flipping a release over To move an existing release, pass `--server-side=true` on an upgrade. That is the moment every accumulated hand-edit and every field owned by another controller can surface as a conflict, so rehearse it: `--dry-run=server` sends the request to the API server for validation without persisting a revision, which is the closest you get to a preview of the switch. Keep the chart identical across that upgrade so the apply mode is the only variable; if it fails, you know why. After it succeeds, the recorded method carries forward on its own. ## Do not confuse it with the force flags Three Helm 4 flags live near each other and are routinely muddled. `--server-side` chooses the write path. `--force-conflicts` overrides field-manager conflicts *within* server-side apply — it does not enable server-side apply and it is meaningless without it. `--force-replace` (whose deprecated alias is the bare `--force`) is an entirely different idea, and Helm rejects `--force-replace` and `--force-conflicts` together because they are mutually exclusive. A candidate who says "`--force` makes Helm win the server-side conflict" has merged three mechanisms into one. ## What it does not change The apply mode changes how the object reaches the cluster; it does not change Helm's own bookkeeping. Each revision is still stored as a release record with the rendered manifest inside it, history and rollback still read that record, and the release's identity, namespace and revision numbering are untouched. Reading `--server-side=auto` as "Helm decides intelligently what is best for this object" is the other common misreading: `auto` is a lookup of one recorded fact about the previous revision, nothing more.