When a Helm chart has subcharts, are the parent's resources applied before the subcharts'?

### One release, one sorted list The instinct behind this question is that a dependency should be installed before whatever depends on it — the way a package manager installs libraries before the application. Helm does not work that way. A chart with subcharts still produces exactly **one** release: one release record, one revision number, one stored manifest, one uninstall. The subcharts are not sub-releases and they are not applied as separate steps. Mechanically, Helm builds the full chart tree (the parent plus everything under `charts/`), computes the merged values, renders every template in the tree, and collects the resulting documents into a single flat list of manifests. Only then does the kind sort run — over the whole list at once. The sort key is the manifest's `kind`; nothing in the sort records which chart a manifest came from. So a subchart's `ConfigMap` is applied before the parent's `Deployment`, and the parent's `ConfigMap` is applied before the subchart's `Deployment`, purely because ConfigMap outranks Deployment in the table. ### A worked example Take a batch-job chart that packages a queue-worker plus a small database subchart. The rendered set might contain the parent's ServiceAccount, ConfigMap and Deployment, and the subchart's Secret, Service, PersistentVolumeClaim and StatefulSet. Helm applies: both ServiceAccounts, the Secret, both ConfigMaps, the PVC, both Services, the parent Deployment, then the subchart StatefulSet — interleaved by kind, with the two charts' objects shuffled together. Notice that the database's StatefulSet is submitted *after* the worker Deployment, because StatefulSet sits after Deployment in the table. The dependency relationship in `Chart.yaml` did nothing to prevent that. ### What dependency declaration order does control The `dependencies:` list in `Chart.yaml` is real and it does matter — just not here. It decides which subcharts are fetched and vendored, and it participates in how values are merged and how templates and named templates from the tree are assembled before rendering. It is a *build and render* concern. By the time the kind sort runs, that structure has been flattened away and Helm is looking at a list of manifests with kinds. ### Why Helm chose this Per-chart sequencing sounds better until you consider what it would cost. Applying chart A fully before chart B means either applying without waiting — in which case you have gained nothing over the flat sort — or waiting for chart A's workloads to be ready, which turns every install into a serial pipeline whose duration is the sum of its parts and whose failure modes multiply. Helm instead submits the whole desired state quickly and lets the cluster's controllers converge, which is the Kubernetes-native way to get there: the queue-worker whose database is not ready yet crash-loops or backs off for a few seconds and then succeeds. ### When flat ordering genuinely hurts It hurts when the dependency is not something a workload can retry into. A subchart that installs a CustomResourceDefinition while the parent renders a custom resource using it is the classic case: the CRD must exist and be served before the custom resource is accepted, and a retry does not happen because the *apply* failed, not the pod. The standard answers are to move the definitions into a `crds/` directory, which is installed ahead of the sorted manifests, or to split the dependency into a release of its own that is installed first. For softer cases — an admission or gateway component that must exist before the workload it fronts — the tools are the `helm.sh/hook` annotation family, which lifts a manifest out of the sorted set entirely, or a workload written to tolerate the dependency being absent for the first few seconds. ### The takeaway to say out loud Order in a Helm release is a property of kinds, not of charts. If somebody asks you to "install the subchart first", the honest answer is that the chart format has no way to express that, and the design has to move: separate releases, a `crds/` directory, hooks, or a workload that retries.