When would you ship a Helm chart's CRDs as a separate chart rather than in crds/?

### Three placements, not two For `digestflow` — a chart wrapping a vendor email-digest builder image, driven by a values-generated config file, installed by 9 teams across 23 clusters — the `DigestSchedule` definition can live in exactly three places, and the decision is a governance decision more than a packaging one. **In the app chart's `crds/`.** Applied once at install, skipped if present, never upgraded, never deleted. Simplest possible story: one artifact, no ordering to get wrong, and a second release in another namespace installs cleanly because the existing definition is left alone. The price is that the schema is effectively frozen after the first install on each cluster, and every installer needs cluster-scoped write permission on definitions. **In the app chart's `templates/`.** Now it is an ordinary release resource: templated, upgraded, deletable. Three consequences follow immediately. Uninstall takes the definition and every custom resource of that kind with it, unless `helm.sh/resource-policy: keep` is on the manifest. Only one release can own a cluster-scoped object, so a second install of the same chart in another namespace fails on ownership — `--take-ownership` exists as an escape hatch but it is an admission that two releases are fighting over one object. And a custom resource rendered by the same release can race the registration of its own kind. This placement is defensible only when a chart is installed exactly once per cluster. **In a chart of its own.** The definitions go in that chart's `templates/` with `resource-policy: keep`, so they get versioning and a genuine upgrade path, while the object is owned by one release that everybody agrees is the owner. This is the shape almost every mature multi-tenant platform converges on. ### What should push you to split - **Several releases share the definitions.** Nine teams installing `digestflow` in nine namespaces are nine releases and one CustomResourceDefinition. A shared object with a single owner needs an artifact of its own; the alternative is nine releases each believing they own it, or eight of them skipping it silently. - **The schema will keep moving.** If the definition changes every couple of releases, `crds/` guarantees a permanent, silent skew on every cluster that has ever installed the chart. That failure mode is invisible until someone's field goes missing. - **A different identity writes cluster-scoped objects.** Where app teams are confined to their namespaces, a definitions chart installed by a platform identity plus `--skip-crds` on the app install is a clean split of privilege — and it removes the cluster-scoped grant from every application pipeline. - **Lifecycle divergence.** Definitions must outlive the app: uninstalling `digestflow` from a namespace must never remove `DigestSchedule` objects that another namespace still uses. Separate artifacts make that structural rather than annotation-dependent. ### What it costs Two artifacts, two pipelines, and an **ordering contract** you now have to enforce: the definitions chart must be installed and current before an app release that depends on it. That contract will be violated. Design for it — have the app chart check that the kind exists before rendering anything that uses it and stop with a clear message, rather than emitting objects that fail obscurely. Version skew is the second cost, and the mitigation is a documented compatibility statement plus a check in the pipeline, not hope. Third is discovery: newcomers who install one chart and wonder why nothing works. That is a documentation and defaults problem, and it is why some publishers ship both — `crds/` for the fresh-cluster convenience case and a separate definitions chart as the supported path for fleets. ### The decision I would actually write down Single team, one release per cluster, a schema that rarely moves: keep `crds/`. It is the fewest moving parts, and the install-once behaviour is a feature rather than a limitation at that scale. Multi-tenant, many releases per cluster, or a schema under active development: split. Definitions get their own chart, their own version, and an owner named in the platform's documentation. Application charts are installed with `--skip-crds` so that no application pipeline holds cluster-scoped write permission, and the promotion pipeline installs or upgrades the definitions chart first. What I would not do is put a CustomResourceDefinition in an app chart's `templates/` for a chart that more than one team installs. It looks like it gives you upgrades for free, and it hands you an ownership collision and a deletion hazard the first time two teams install it in one cluster. ### What an interviewer is listening for Not a preference, but the reasoning: who owns cluster-scoped state, what the blast radius of a mistake is, whether the ordering contract is enforced or merely written down, and an honest account of what the split costs in artifacts and coordination.