Lesson 6 · This repo's library-chart architecture

Library charts & the copy model

How one libs/util chart generates almost every object in the repo — and the unusual way it's shared.

Your win: explain what a library chart is, how it differs from a subchart dependency, and this repo's deliberate choice to copy the library into every chart rather than depend on it — including the trade-off.

Library charts — templates, no output

A library chart (type: library) defines only named templates. It renders nothing on its own; other charts pull in its helpers.1 It's how you write a Deployment template once and reuse it across ~25 services instead of copy-pasting YAML — the DRY answer to Lesson 1's problem.

Anchor — libs/util is the library deployments/helm/libs/util/Chart.yaml is type: library. It holds every workload template — _deployment.tpl, _statefulset.tpl, _service.tpl, _keda.tpl, _pdb.tpl, _secret.tpl, and the orchestrator _app.tpl (util.app, _app.tpl:7). Every Course-2 object you learned is defined here, once. A service chart's job is just to call util.app with its values.

Normally, you'd use a dependency. This repo doesn't.

The standard way to consume a library chart is a Helm dependency: declare it in Chart.yaml's dependencies:, run helm dependency update to fetch it into charts/, and include its templates.2 This repo takes a different route.

Anchor — the copy mechanism Service charts have no dependencies: block. Instead, deployments/helm/update_deps.sh physically copies the library templates into each chart:
rm -rf templates/util; cp -a libs/util/templates/. templates/util (update_deps.sh:14-19), looped over every chart (:22-58).
So backend/bob/templates/util/_deployment.tpl is a generated, byte-for-byte copy of the library file. It's checked into git — which is why the K8s course kept saying "the templates/util/ copies aren't the source; cite libs/util."
Why copy instead of depend? (the wisdom question) Trade-offs. Copying means: each chart is self-contained (no dependency update / network fetch at deploy — matters for Skaffold speed and reproducibility), and the rendered templates/util/ is visible in git diffs. The cost: the copies can drift if someone edits a copy instead of the source, so you must re-run update_deps.sh (there's a make update-deps target, Makefile:326) after any library change. Notably, unlike the generated DAGs and DB schema — which are CI-guarded by a git diff --exit-code drift check — the copied templates/util/ appears not to have an equivalent CI gate, so keeping it in sync is a discipline, not an enforced invariant (Lesson 12). A dependency would be tidier but adds a fetch step and hides the templates. There's no universally "right" answer — ask the deployments/ owners why they chose it here; that's the real-world wisdom.

Real dependencies do exist — for third-party charts

Anchor — the exceptions Where the repo needs an upstream chart it can't copy, it uses a normal dependency: backend/zeus/Chart.yaml:26-30 declares a real dependency on sftpgo 0.19.0 from charts.sagikazarmark.dev (vendored as charts/sftpgo-0.19.0.tgz + a Chart.lock). Platform charts do the same for KEDA, Kafka, Spark, Airflow, Appsmith. So the rule is: copy our own library, depend on other people's charts.
Read this next

Helm docs — Library Charts + Subcharts & Dependencies

What type: library means, and the normal dependency mechanism this repo deliberately bypasses for its own library.

→ helm.sh — Library Charts
→ helm.sh — Subcharts & Global Values

Check yourself (from memory)

Q1. A library chart is one that…

type: library = shared named templates only. Repo: libs/util holds every workload template.

Q2. How does this repo share libs/util with service charts?

update_deps.sh does cp -a into each chart's templates/util/ — not a dependency.

Q3. When does this repo use a real Helm dependency?

Copy our own library; depend on other people's charts (sftpgo, KEDA, Kafka, Airflow…).
Library chart vs subchart, and why this repo copies instead of depends.
recall, then click to reveal
A LIBRARY CHART (type: library) defines only named templates, renders nothing — write a Deployment template ONCE, reuse across services. Repo: libs/util holds every workload template + the util.app orchestrator; a service chart just calls it. NORMALLY you consume a library via a Chart.yaml dependencies: block (helm dependency update → charts/). THIS REPO INSTEAD COPIES it: update_deps.sh does cp -a libs/util/templates/. → templates/util in every chart (checked into git). TRADE-OFF: self-contained + reproducible + visible in diffs, BUT copies can DRIFT (fixed by re-running the script + a CI check). REAL deps are used only for THIRD-PARTY charts (zeus→sftpgo, platform keda/kafka/airflow). Rule: copy our library, depend on others'.
Want to see the drift-check in CI, or how a normal dependencies: + helm dependency update flow would look here? Ask me.

1. Helm — Library Charts.

2. Helm — Subcharts & Global Values.