Why does Helm 4's --server-side=auto leave a release installed by Helm 3 applying client-side?

## Two defaults, not one The sentence "server-side apply is the default in Helm 4" is true and incomplete, and the incompleteness is the whole question. There are two different defaults: - **`helm install --server-side`** is a **boolean** that defaults to `true`. A release created by a Helm 4 client is applied server-side from revision 1. - **`helm upgrade --server-side`** and **`helm rollback --server-side`** take a **string**, and the default is `auto`. `auto` does not mean "decide cleverly per resource"; it means **inherit the apply method of the previous revision**. The consequence follows directly. Take a Redis chart with a StatefulSet and a PersistentVolumeClaim, installed as `redis-cache` under Helm 3 and now sitting at revision 7. You replace the CLI with Helm 4 and run `helm upgrade redis-cache ./redis -n payments` with no apply flags. Revision 7 was written client-side, so `auto` resolves to client-side, and revision 8 is written the same way. Nothing about the write path changed just because the binary did. ## Why the two paths differ **The client-side three-way strategic merge** is the Helm 3 path. Helm computes a patch by comparing three documents: the manifest stored in the previous release record, the manifest just rendered, and the live object read from the API server. That third input is what lets Helm notice a field a human added by hand and decide whether to keep it. The decision is made *in the client*, and the cluster sees only the resulting patch. **Server-side apply** moves that decision into the API server. The client sends the full intended object and a field-manager identity; the API server records, per field, which manager owns it. Ownership is real state stored in the object's `metadata.managedFields`. If two managers set the same field to different values, the apply is rejected as a conflict unless the caller explicitly asks to override it — and Helm 4 has a distinct flag for exactly that override, separate from the flag that replaces resources outright. Those are genuinely different models, which is why Helm does not switch a live release between them behind your back. ## What flipping actually costs When you do pass `--server-side=true` on an upgrade of a long-lived release, the first apply is where any surprises land: - Fields that were set by something else — another controller, a mutating admission step, or an engineer's `kubectl edit` — now have an owner recorded, and Helm's claim on them can conflict. - Fields Helm previously set and then stopped rendering behave differently: under server-side apply, removing a field from your applied configuration relinquishes it, which is a cleaner model than the client-side one but not an identical one. - Objects that carry a large last-applied-configuration annotation from years of client-side applies do not clean themselves up just because you switched. None of that is a reason to stay client-side forever. It is a reason to schedule the flip as its own change: one release at a time, on a workload whose blast radius you can afford, with the rendered output previewed and the live object diffed before and after. ## Ambiguity worth naming "Ownership" is the sharpest overloaded word here, and an interviewer may be testing whether you notice. There are three distinct mechanisms and this question touches two of them: **release ownership**, the `app.kubernetes.io/managed-by: Helm` label plus the `meta.helm.sh/release-name` and `meta.helm.sh/release-namespace` annotations that tell Helm an object belongs to a particular release; and **field ownership**, the server-side-apply field-manager bookkeeping described above. (The third, Kubernetes `ownerReferences` and garbage collection, is a different thing again and Helm does not use it to track release membership.) Switching apply method changes the second and leaves the first alone: the release still owns the same objects, it just negotiates individual fields differently. ## How to check where a release stands The honest answer is that you check the object, not the flag. `kubectl get <kind> <name> -o yaml --show-managed-fields` shows whether an apply-mode field manager is recorded for the fields your chart renders. Combined with `helm history`, that tells you which revisions were written by which client. The practical operational rule for a fleet move is simpler: assume every release that predates the CLI upgrade is client-side until you have deliberately moved it, and record the flip in the same place you record any other production change. ## The trap answer The answer to avoid is "Helm 4 uses server-side apply, so my old release is now server-side too." It is a reasonable inference from the release notes and it is wrong, and the failure it produces is subtle rather than loud: you plan around field-ownership semantics that are not actually in effect, and the drift behaviour you observe after a manual `kubectl edit` is the old three-way-merge behaviour instead.