In Helm 4, what does --post-renderer accept, and what broke from Helm 3?

This is one of a short list of Helm 4 changes that will actually break a working pipeline, so it is worth knowing precisely rather than approximately. ## What changed In Helm 3, `--post-renderer` took a **path to an executable**. Anything that could read standard input and write standard output qualified: a shell script, a Python file, a compiled binary. Teams typically checked one into the repository next to their values files and passed a relative path from the deploy job. In Helm 4, `--post-renderer` takes the **name of an installed plugin** whose declared type is `postrenderer/v1`. Helm resolves the name against the plugins installed on the machine, in the directory that `HELM_PLUGINS` points at, and invokes the plugin. A file path is no longer a valid value; passing one fails because no plugin by that name is installed. ## Why it is a real break Most Helm 4 changes are additive or aliasing — `--atomic` still works as a deprecated alias of `--rollback-on-failure`, `--force` still works as an alias of `--force-replace`. The post-renderer change is different: there is no alias and no compatibility path. A pipeline whose deploy step reads ```bash helm upgrade --install chat-fanout ./chat-fanout --post-renderer ./hack/patch.sh ``` simply stops working when the runner's Helm binary is upgraded to 4.x, and the failure appears at deploy time on whichever environment upgrades first. ## Migrating The transformation itself does not have to change. The stdin/stdout contract is identical: Helm still writes the whole rendered manifest stream in, still takes the replacement stream out, still aborts on a non-zero exit. What changes is packaging and lookup. You wrap the existing executable as a plugin whose type is `postrenderer/v1`, install it, and reference it by its plugin name: ```bash helm upgrade --install chat-fanout ./chat-fanout --post-renderer platform-patch ``` The plugin's own manifest, its runtime choice and its signing are the plugin system's concern rather than the post-renderer flag's; what matters here is the type declaration that makes Helm willing to accept the name after `--post-renderer`. ## The operational consequence people miss Under Helm 3, the post-renderer travelled with the repository. Clone the repo, run the deploy, the script was there. Under Helm 4 it travels with the **machine**: it must be installed wherever `helm` runs. That has several practical effects. Your CI image now needs a provisioning step that installs the plugin, and that step needs a pinned version, otherwise two agents can produce different manifests from the same chart and the same values. Engineers running `helm upgrade` from a laptop need the same plugin at the same version, or they will produce a different desired state than the pipeline does. And an ephemeral runner that installs plugins on every job pays that cost on every job, and fails the deploy when the plugin source is unreachable. The upside is the reason for the change. A named, installed, versioned plugin is something you can distribute, pin, audit and verify, in a way that a loose script referenced by a relative path never was. It also removes a sharp edge from Helm 3, where the value of `--post-renderer` was a path resolved on the machine running the command, so what actually ran depended on the working directory and on `PATH`. ## What did not change Everything about the semantics. The post-renderer still runs after templating and before Helm splits, stores and applies; it still must return the entire stream; its output is still what lands in the release record; and nothing about its use is persisted with the release, so a later upgrade that omits the flag still silently drops the patch. If you are migrating, that last point is the one to protect with a wrapper or a pipeline step, not with discipline.