Pick a tested configuration and check it yourself

Check why you can trust an entry

Every entry is an image of the exact objects, with a receipt of what was checked. Three words say how far each one is proven.

• Verified. The render matches Helm's own output for the recorded inputs, so a base variant is proven rather than asserted.
• Certified. A whole composition passes its checks, so every part holds together, before anything renders. See how a stack is certified.
• Signed. A signature records who published the image. cub config verify confirms the image is exactly what its receipt says and refuses one with none. The receipt says what was checked, not that the configuration will run on your cluster.

Verify a signed image yourself, or see what this catalog does not claim.

Search the catalog

The catalog holds 113 Helm charts and non-Helm entries in one filterable table: 124 AICR platforms, a Timoni module, a literal configuration OCI, and a plain Kubernetes YAML entry. Use the Format filter to narrow to any one, for example all 124 AICR platforms; the other filters and the text search span every entry.

Already have GPU nodes? aicr snapshot and aicr diff report how their state differs without a recipe or a matching entry. A difference is not automatically a fault. Compare each node with the provider-curated source variant intended for its hardware and workload before deciding what should change. Open the AICR starting paths.

What each catalog entry contains

Every version has a local detail page for its package, configurations, and receipt. The bold version in each row is the one summarized by that row's readiness and evidence. Retained-only version pages prove publication and inspect identity; they do not inherit another version's readiness or live proof.

Every entry carries the same parts, and each one is explained on Config.

• The package. The pinned source and its inputs. See the recipe step.
• The bases. One reviewed starting configuration per tested choice. See what a base variant is.
• The bundle, where the lane permits it. The exact objects kept as a certified OCI image. See when a configuration can be flattened and see the bundle's OCI shape.
• The routes. The CRDs, hooks, and setup work, in order. See what a chart hides.
• The receipt. What was checked, and the digests it names. Check why you can trust it.

Helm charts

• If My Chart Has Hooks, What Happens?
• Hook Lifecycle Strategy
• Helm Chart Presets And Values
• Helm Render Intents
• Extension Slots
• Helm Pain Points
• Coming from Helm? How your habits map to cub
• Seven-Stage Helm Lifecycle
• How The Harness Works
• Target Prerequisites
• Prometheus High-Fanout Example
• NGINX Configuration Files

How the catalog handles required setup

The chart page names any CRDs, hooks, setup jobs, generated Secrets, or other target resource a chart needs, before you choose a configuration. See what your chart's hooks, CRDs, and setup work become.

Read each result correctly

The Catalog can give you a source and exact objects without a cluster. Destination and live answers appear only when the required target or deployment evidence exists.

A missing prerequisite is reported as blocked or not-run. It is a different result from a configuration that failed, and we keep the two labelled apart.

Each row also carries a flattening verdict, in the "Flattens as plain YAML?" column. See what each verdict means and how many bases fall in each lane. A row's hook or CRD signal links to what your chart hides.

Why the catalog offers several configurations

A Helm chart can expose hundreds of values. The catalog provides tested starting configurations for common choices, such as existing Secrets, high availability, or separately managed CRDs.

We call each starting configuration a base variant. Its page records the Helm values, rendered YAML, required setup, and evidence for that choice.

Useful choices differ by chart. Redis, Argo CD, and kube-prometheus-stack do not need the same starting configurations.

How the values for each configuration are chosen

We do not guess. The default configuration is the chart's own defaults, with the image pinned by digest. When a chart's default is unsafe, we keep it visible as an honest example and add a recommended one beside it: Redis default writes a password into a rendered Secret, so the catalog also ships reuse-existing-secret, which names the Secret you supply and puts no credential in the render.

Every value in a configuration is recorded with where it came from: a chart default, a catalog policy such as pinning the image, or a generated value like a password. And every configuration's render is compared against Helm's own output, so a base variant is verified, not asserted. New configurations are added when a real choice needs one, gated by that comparison.

Here is what this does and does not prove. The catalog proves these named configurations. It does not prove every possible values file. Your own values still need to be rendered and checked, which is what Is my configuration right? is for.

See where Helm values, later ConfigHub changes, install work, and live state belong.

Every maintained entry uses the same configuration processing model. The generated alignment report shows which records have complete flattening, ownership, and destination-route evidence and which still have gaps.

Verify an entry yourself

The catalog reports what a configuration does rather than certifying it as secure for your cluster. It gives you the exact objects, their source, and the checks recorded against them. Verify a signed package yourself with the immutable reference and the two annotations from its catalog record.

cosign verify \
  --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com \
  --annotations confighub.com/package-path=packages/bitnami/redis/25.5.3 \
  --annotations confighub.com/package-sha256=<package-sha256> \
  europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3@sha256:<manifest-digest>

Each chart-version page fills in the recorded digests. Some evidence is partial by design. A digest proves integrity inside a known trust chain and says nothing outside one. A scan finding still needs a human decision. A clean render tells you the objects are well formed, while cloud identity, storage, and runtime policy at the target remain unchecked.

Behind every claim is a count you can read and a command you can rerun. Read the current counts, see what each test covers, and check one claim yourself.

What stays available

The catalog retains 140 exact package versions across 113 components. 140 have a dated registry receipt; the oldest current receipt is from 2026-08-26. A new review adds a version. It does not silently replace an older package.

We have caught 2 cases where an upstream publisher changed the bytes behind an existing version string. The catalog keeps the reviewed bytes and records both digests so you can see the change. Read those cases.

A chart is listed only after its license evidence is recorded. Normal refreshes are additive. If a legal or factual correction is required, the change must be named rather than hidden. Read the retention policy.

What this catalog does not claim

The catalog proves the named configurations it lists. It does not prove every possible values file, and it does not certify a chart as secure for your cluster. Your own values still need to be rendered and checked, which is what Is my configuration right? is for.

A green result on one test does not mean the next test passes. A signature proves origin and integrity, not safety, so scans, policies, and live evidence carry the safety claims. A row marked watch, blocked, or refused stays that way until a receipt changes it. Read what is not ready yet, or what this project refuses to claim.

Take an entry into a stack or into ConfigHub

Open the chart page and follow its first command. Inspect the generated objects and required setup before you decide where they should run.

Choosing several components for a platform? Build a small Kubara platform from tested Catalog entries, or compose a stack from certified parts. Upload any entry into ConfigHub to release, promote, and govern it, or deploy it directly with the reconciler you already run.

Is my configuration right? · Try it: Redis in ten minutes · Run it with Flux, Argo CD, or kubectl · Your assistant · Worked examples