A deprecated Helm chart is one whose newest published version has the deprecated flag set in Chart.yaml. It still installs and runs, but the maintainer is signalling that it will not move forward. Treat it as a planned migration: find where you use it, check for a replacement, and set a date.
How deprecation works
The Helm documentation describes an optional deprecated field in Chart.yaml. If the latest version of a chart in a repository is marked as deprecated, the chart as a whole is considered deprecated. A chart name can be reused later by publishing a newer version that is not deprecated.
The documented workflow for deprecating a chart is to mark it in Chart.yaml and bump the version, release the new version in the chart repository, and remove the chart from the source repository. So the signal lives in the newest version only. If you pin an older version, you may never see the flag unless you look at the latest one.
Why it is a security topic
Deprecation is not a vulnerability. It is a maintenance signal. A chart that is no longer updated stops receiving changes for new Kubernetes API versions, new default hardening, and updated images. Over time, the gap grows.
There are also two edge cases:
- A chart name can be reused by a new, non-deprecated version. Check that a revived name is still maintained by the same people before trusting it again.
- A deprecated chart's own dependencies are still downloaded by dependency update. They may be unmaintained too.
How to find them
- List your releases and the chart and version each uses.
- For each chart, fetch the latest version's Chart.yaml and read the deprecated field. You can pull a chart archive and inspect it.
- Check each chart's dependencies block, including subcharts, for the same flag.
- Note which of your charts come from repositories that have stopped serving updates.
In version control, search for Chart.yaml files and the dependencies list. A scheduled job that compares your pinned versions against the latest and reports deprecated ones turns this into a routine.
Choosing a response
| Situation | Suggested action |
|---|---|
| A named replacement exists | Plan a migration, test in a staging cluster |
| No replacement, simple chart | Vendor the chart into your repository and own it |
| No replacement, complex chart | Plan to replace the workload or adopt a maintained alternative |
| Deprecated but stable and low risk | Document the decision with a review date |
Vendoring means you own security updates. Be honest about whether your team can do that. Also scan the images the chart uses, because those continue to age even if the chart does not change.
Migration care
Moving between charts is not a version bump. Resource names, labels and persistent volume claims may differ. Test the change, back up data, and read the new chart's upgrade notes. Using a values schema in a wrapper chart can catch bad inputs early. See can values.schema.json stop risky Helm settings.
Where a scanner fits
Deprecation will not show up as a CVE, so pair it with vulnerability data. Safeguard's dependency scanning and SBOM generation can inventory charts and the images behind them, and continuous monitoring flags new findings in what you already run. Check your scanner's Helm coverage. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a component that was clean at deploy time can gain findings later, which is the situation with an unmaintained chart's images.
Quick check
Does a deprecated chart stop working?
No. The flag is metadata in Chart.yaml. The chart still installs, but the maintainer is signalling it will not be developed further.
Where is the deprecation flag checked?
On the latest version of the chart in the repository. The Helm documentation says if the latest version is marked deprecated, the whole chart is considered deprecated.
Sources
Last reviewed: 19 October 2026.
