See what happens to your chart's hooks, CRDs, and setup work.

1. Know the phases, the dispositions, and who runs the work

A certified image renders your chart's ordinary objects without running its Helm hooks. For each hidden requirement it records a route: a lifecycle phase, who runs it, and whether it is automatic.

The phases are pre-render, preflight, pre-apply, post-apply, observe, and refuse. Each route also carries one of five reader-facing dispositions. observed means a passing receipt exists for that exact chart, version, preset, and target scope, and routed means the method is recorded but not run. per-target means the right method depends on your cluster. blocked means a prerequisite or evidence is missing, and refused means it was deliberately not run. The linked machine-readable sources use a finer vocabulary, including not-run and recipe-needed, so a per-chart view may show states beyond these five.

Every lifecycle action packet today is automatic: false. ConfigHub does not yet choose or run a chart-specific hook route for you. The certified-bundle routes in section 7 are a separate model, where a declarative, idempotent route such as CRD ordering can be automatic. The pattern stays observe, then execute, then emit a receipt: read the disposition, supply what it needs, and run only the action that is actually supported. The route becomes observed once a passing receipt covers that scope.

Who runs it today is you, your cluster or controller, or, not yet, the product itself.

This follows what hook support means and the hook lifecycle strategy. Both name the same evidence with their own vocabulary, so read this page first and those two for the deeper detail.

2. Read the short answer and your practical choices

Short answer: the catalog renders your chart's objects without running its Helm hooks. Then, for each chart, it records what still has to happen.

That may be a setup step, a CRD ownership choice, a GitOps action where evidence exists, a target-specific decision, a blocker, or a refusal. The answer is chart-specific because Helm hooks are chart-specific.

These choices are how the catalog handles most real cases. It does not need one generic hook mechanism that treats every chart the same way. It needs accurate chart-specific answers, recorded inputs, and receipts where support is claimed.

Read the full guide for the source of this section.

3. See what a route tells you, then do the six steps

• Where it goes. A lifecycle phase: pre-render, preflight, pre-apply, post-apply, observe, or refuse.
• Who runs it. You, your cluster or controller, or, not yet, the product.
• Whether it is automatic. The route record says which exact implementation ran. A direct script result does not prove the Argo CD or Flux version of the same step. Top-level automatic stays false until every delivery path named by the claim has its own receipt.
• What is needed next. The target facts to supply, and the evidence required before the route can be called supported.

The machine-readable form is the lifecycle route actions: an agent reads actions.json and turns a row into a preflight, action, and observe plan. The route contract behind it is lifecycle routes. The per-chart view, each chart's routes, disposition, and whether a skill applies, is per-chart hooks, shown as colored cards.

1. Choose the chart preset. Start from the chart page, not a generated package folder.
2. Read the chart extras. Look for hooks, CRDs, setup jobs, webhooks, generated Secrets, and target facts.
3. Check the disposition. observed has a receipt for the supported scope. routed, blocked, or per-target means the work is named but still needs setup, target input, or more evidence.
4. Supply the required target facts such as Secrets, CRDs, storage, hosted zones, or cloud accounts.
5. Run only the actions that are supported for that chart and target. A placeholder command is not a support claim.
6. The behavior becomes observed for your scope once a passing receipt covers it.

A known route is not an executed one. Every lifecycle action packet stays automatic: false today, while the declarative certified-bundle routes in section 7 can be automatic. The value now is clear chart-specific guidance: you, a reviewer, or an agent can see where each hidden behavior goes and what it needs, instead of reverse-engineering Helm during an install.

Making the product execute observed or routed steps is separate, continuing work (issue 688).

4. Follow the worked examples through hooks and CRDs

Kube Prometheus Stack: the install order, and what stays manual

For the default preset, where the package owns the CRDs, the install order is fixed:

1. Apply the CRDs.
2. Wait until Kubernetes reports that every CRD is established.
3. Prepare the admission-webhook certificate Secret.
4. Apply the ordinary Kubernetes objects.
5. Check the webhook and workloads after the apply.
6. Record the result.

The order matters. A live CRD test showed that applying a custom resource before its CRD is established fails on a new cluster. Applying the CRD first, waiting, and then applying the custom resource works.

The no-crds render leaves CRDs out of the chart object set, but the installer package still carries the ten checked CRDs as a separate prerequisite. Its direct script keeps compatible CRDs that are already present, or applies the packaged copies on a new cluster, then waits before applying the workload.

These are the receipted routes for that same install order, by delivery path:

The Argo CD sync-wave order and the Flux dependsOn chain in that table are generated by the catalog's staged OCI packaging for the no-crds base. The direct-apply sequence above it is advice: you run those steps yourself with kubectl.

ConfigHub does not yet select the Kube Prometheus Stack route automatically. A person or automation still chooses the delivery mechanism and confirms that the chart version, target Kubernetes version, CRDs, and webhook behavior match the recorded plan. Direct apply has fresh-install evidence for both bases and 85.3.3-to-86.1.0 upgrade evidence for the default package route; Argo CD and Flux add fresh-install and the same upgrade for no-crds.

Read the full Kube Prometheus Stack walkthrough, including the apply check and every cited receipt.

Argo Workflows: install the right CRDs before the workloads

Argo Workflows is a useful example of work that Helm normally performs outside the rendered release. The chart's default configuration keeps its full CRDs out of the ordinary manifest output.

During install and upgrade, a Helm hook downloads eight CRD files from GitHub and applies them before the controller and server start. It uses forced server-side apply because the full schemas are too large for client-side apply.

The catalog's default package base keeps that behavior without an install-time download:

• The package contains the eight full CRD files used by argo-workflows@1.0.14.
• Each source URL and SHA-256 digest is recorded in the base variant.
• The generated no-account script applies the CRDs with kubectl apply --server-side --force-conflicts before the controller and server objects.
• Running the same step before an upgrade refreshes the CRDs in the same phase as Helm's pre-upgrade hook.
• The script waits for every CRD to become established before it applies the workloads.

This is a chart-specific replacement for one Helm hook, not a claim that one generic hook translator can safely handle every chart. The live comparison used two clean kind clusters, matched all eight CRDs by SHA-256, and matched the 19 ordinary chart objects. Read the receipt.

Read the full Argo Workflows walkthrough, including the smaller minimal-crds base.

Three more dispositions, in brief

5. Decide who owns each CRD

CRDs show up in three shapes across the catalog. A chart can ship its own CRDs and apply them itself, the way the Argo Workflows default base does. A chart can split CRDs into a separate no-crds base and leave the target cluster or another controller to own them, the way Kube Prometheus Stack does. Or a subchart inside an umbrella chart can carry an object that only works once the platform around it exists.

Kubara's generated umbrella charts assume the whole platform exists: they guard their ServiceMonitor behind the Prometheus-operator CRD, and cert-manager's ClusterIssuer is a custom resource that needs its CRD established first. So the bring-up order is CRDs, then controllers, then custom resources.

A CRD-guarded object is one the chart only applies once its CRD already exists, the way a ServiceMonitor needs the Prometheus-operator CRD and a ClusterIssuer needs the cert-manager CRD. Install the CRD, wait for Kubernetes to report it established, and only then apply the guarded object.

A hard chart carries one or more signals from the catalog's own matrix: CRDs, webhooks, cluster RBAC, stateful storage, generated values, cluster lookups, or Helm hooks. Kube Prometheus Stack and cert-manager carry several at once, which is why they anchor the harder-chart examples.

The required-setup vocabulary stays the same across the catalog. A target prerequisite, also called a target fact, is something the cluster must already provide. A lifecycle route is the recorded way a hook-like requirement gets handled. A disposition is one of the five words above. See how target prerequisites are staged.

Across the catalog, an Argo CD sync wave or a Flux dependsOn chain is generated only where a staged OCI package proves the ordering. Everywhere else, a CRD-first sequence like the one above is advice for you to encode yourself.

6. Stage target prerequisites before you apply

Some charts need cluster resources or facts that are not in the rendered YAML. For easy charts, matching Helm's own rendered objects is enough to start. Serious charts also depend on things that must already be true in the target cluster.

This repo calls those requirements target prerequisites. For example:

• CRDs must already exist before a CRDs-off base is applied.
• A Secret must exist when the chart is configured to reuse one.
• A webhook certificate may be generated by a controller after apply.
• An APIService may only become healthy after the backing service is ready.
• A Helm startup check may need to become a post-apply observation.

Before deploying a base, check the per-chart catalog page and the variant file. The chart page links the render intent that keeps the declaration, rendered objects, lifecycle routes, and Argo CD or Flux handling together.

If the base lists target prerequisites:

1. Stage them before applying the base, or choose a base that includes them.
2. Keep the prerequisite source visible in the pull request or ticket.
3. Run the relevant live check after apply.
4. Do not call the install production-supported until the target scope has a production support decision.

The routing rule sorts a change or requirement into one place:

Read the full guide, including the cert-manager, Vertical Pod Autoscaler, and OpenTelemetry Operator examples.

7. See how a bundle carries routes with the objects

A flatten-with-routes verdict names the companion artifacts a bundle must ship. Those are routes, and they travel inside the bundle, so the knowledge of how to apply the configuration never depends on whoever happened to flatten the chart.

A route names the quirk class it discharges and states what breaks without it. It carries a declaration rather than a command: it says what must hold, not how one tool achieves it. The executedBy block lists the runtimes that can execute it and how each expresses it, and it carries automatic, which defaults to false and is earned by observation.

The first route is traefik's CRD ordering. Its verdict requires an ordering declaration for 25 CRDs: definitions first, with a wait for establishment, then everything else. Ordering is declarative and idempotent, so this route is marked automatic; a route that runs a Job is not, and stays manual until observed.

Schema: BundleRoute. The full spec also covers the Space guide and the boundaries that ship beside every route.

Hooks under GitOps

A Helm hook becomes a named piece of work, not an inherited Argo or Flux hook. For one chart the right answer may be a preflight check. For another it may be an Argo sync action, a Flux-compatible step, a target fact, or a blocker. The catalog should say which answer applies and what evidence exists.

Read the full GitOps adopter guide, and see routing hooks transparently for the pathway behind it.

8. Understand each tracked requirement, chart by chart

Use this table when a term is unfamiliar. Use the matrix when you need the exact status for one chart version and configuration.

9. Check what remains before deployment

A matching render is only the first check. The cluster may still need CRDs, a Secret, webhook readiness, storage, cloud identity, or a controller.

A recorded route does not mean it runs automatically. The chart page must say who runs it and link the result when that path has been tested.

A watch or blocked result needs action. Follow the stated setup, decision, or evidence link before deployment.