A Helm post-renderer is any executable that reads all rendered Kubernetes manifests on standard input and returns the final manifests on standard output. Whatever it prints is what Helm installs. That makes it a powerful place to patch a chart, and a place that deserves the same review as the chart itself.
What the documentation says
Helm describes post rendering as a way for chart installers to manipulate, configure or validate rendered manifests before installation. The stated motivation is to let people with advanced needs, for example using kustomize, change a chart without forking it or asking the maintainer to expose every option. It needs Helm 3.1 or later.
The only interface is standard input, standard output and the exit code. A non-zero exit code signals failure. You attach one with the post-renderer flag on install, upgrade and template. If you need several, chain them in a script or with a pipe.
Why that matters for security
The post-renderer sits after templating and before the cluster. Three consequences follow.
It can change anything. A renderer can add a sidecar, remove a securityContext, or change an image. The Helm docs explicitly mention injecting common tools and sidecars as a use case. That is useful when it is your platform team doing it on purpose, and dangerous when it is hidden.
It can hide changes from chart review. Someone who reviews a chart's templates and values sees the input. If a post-renderer rewrites the output, the reviewed chart no longer equals what runs.
It is code you execute. Like a plugin, it is a program on the machine that runs the install. A renderer fetched from a mutable location widens your supply chain.
Helm 4 and hooks
The documentation notes a change in Helm 4: chart hooks are sent to post-renderers along with regular templates, by default in one combined stream. Helm 3 never sent hooks. There are options to send them separately or to leave hooks untouched. If your renderer assumed only templates, check how it behaves with hooks, because it may now modify or choke on them.
A review checklist
- Keep the renderer in version control, in the same repository as the deployment configuration.
- Pin any tool it calls, such as a specific kustomize version.
- Add a CI step that runs helm template with the renderer and saves the output.
- Scan that final output, not just the chart. This is the manifest the cluster will see.
- Diff the output between releases, so a renderer change shows up in review.
- Fail closed. A renderer that errors should stop the install, and the docs confirm a non-zero exit signals failure.
The same idea applies to kustomize patches over charts: the rendered output is the truth. See review rendered kustomize output, not just the patch.
Where a scanner fits
Scanning rendered output catches issues the source files hide. Safeguard's policies and pull request gates can hold a change that fails your rules, and SBOM generation can record the images that final manifests reference. Check how your scanner takes rendered input, since a template with placeholders is not the same as a real manifest. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice what the gate evaluates, and picture feeding it rendered manifests rather than templates.
Quick check
Can a post-renderer change a chart's images?
Yes. It returns the final manifests, so it can change any field, including images and security settings. Review its output the way you would review the chart.
Does a post-renderer replace forking a chart?
It is designed as an alternative to forking, per the Helm documentation. You still own the renderer, so keep it versioned and reviewed.
Sources
Last reviewed: 19 October 2026.
