A Helm library chart is a chart with type: library that provides shared templates and functions to other charts. It cannot be installed itself and renders nothing on its own. Because every consumer inherits its output, it needs named owners and careful versioning.
Definition from the Helm docs
Helm's chart documentation says the default chart type is application. Setting type: library makes a chart non-installable, and its resource objects are not rendered. The purpose is to supply utilities and functions to other charts. The type field arrived with apiVersion: v2, which is for charts that require Helm 3 or later.
A consuming chart lists the library under dependencies in Chart.yaml, with a name, a version and a repository, and helm dependency update downloads it into charts/.
Why teams build them
Platform teams use library charts to give every service the same deployment shape: labels, resource limits, probes, security context and service accounts. The goal is that app teams write a few values and get a consistent, reviewed object.
That consistency is also the risk. A library template is code that is rendered into many teams' workloads. A change to a default security setting changes all of them on their next chart upgrade.
Ownership
| Concern | Suggested approach |
|---|---|
| Who can change templates | Named owners via CODEOWNERS, with a required review |
| Who decides breaking changes | The platform team, with notice to consumers |
| How consumers receive changes | Pinned chart dependency versions, bumped by pull request |
| How changes are tested | Render tests against a few representative consumer charts |
See CODEOWNERS and release files for protecting the directory.
Versioning and pinning
Treat the library's template helpers and expected values as its public interface. Renaming a helper breaks every chart that calls it. Use SemVer for the chart version, and publish release notes. See version vs appVersion.
Consumers should pin the dependency to a specific version in Chart.yaml, not float. After running helm dependency update, commit the resulting lock file so the exact dependency is recorded. Details are in bumping a chart dependency.
Review steps for a library change
- Read the diff to the named templates, not just the values.
- Render a sample consumer chart before and after and compare the output. Look for loosened security context, added privileges, new volumes or changed service types.
- Check that new behaviour is opt in, not on by default, unless the change is a deliberate tightening.
- Confirm the version bump matches the change.
- Announce the change to consumers with the action they must take, if any.
A note on security defaults
If the library sets a safe default, such as running as non root, consumers inherit that without effort. If an app needs an exception, make the exception explicit in its own values, visible in review, rather than editing the library. That keeps the strong default for everyone else. For exception handling patterns, see how to handle exceptions to IaC security rules.
Where Safeguard fits
Safeguard policies and gates can require checks and reviewers on pull requests to a shared chart repository, and compliance and evidence automation can keep the approval trail. It does not render or scan Helm templates for misconfigurations.
Quick check
Can I helm install a library chart?
No. Per the Helm documentation, a chart with type library is non-installable and its resource objects are not rendered.
Do consumers get library changes automatically?
Only if they float the dependency version. If they pin it, they receive changes when they bump the pin and update the lock file.
Sources
Last reviewed: 19 October 2026.
