Library charts & reuse

Shared templates across charts.

Advanced12 min · lesson 9 of 12

When many charts share the same boilerplate — a standard Deployment shape, a common label block, your org’s security defaults — you factor it into a library chart. A library chart (type: library in Chart.yaml) ships only named templates, no installable resources of its own; other charts declare it as a dependency and include its templates. It is the chart-level answer to “write the golden pattern once, reuse it everywhere.”

Chart.yaml (consumer)

dependencies:
  - name: common
    version: "1.x.x"
    repository: "oci://registry.internal/charts"
---
# a library chart declares itself:
#   apiVersion: v2
#   name: common
#   type: library     # cannot be installed directly; only included

using a library template

{{- include "common.deployment" (dict "top" . "port" 8080) -}}
# the library owns the Deployment shape + your security defaults
# (runAsNonRoot, dropped caps, resource limits) so every app inherits them

Encoding standards centrally

The security payoff is real: put runAsNonRoot, dropped capabilities, read-only root filesystem, and resource limits into the library’s templates, and every chart that uses it is hardened by default — doing the secure thing becomes less work than doing the insecure thing. Version the library like any chart so consumers upgrade deliberately, and a fix to the shared pattern propagates to all of them.

A library change ripples to every consumer

Because many charts include the library’s templates, a change there affects all of them on their next dependency update — powerful for rolling out a hardening default, risky if a change breaks a consumer. Version the library semantically, let consumers pin it, and test a bump against representative charts before releasing; treat it as the shared, high-blast-radius code it is.

Hooks & release lifecycleLinting, testing & schemas