bitnami/rabbitmq

What this page gives you

Every chart page follows the same order. Choose a configuration, inspect its objects and setup work, then read the tests that have run. Open the worked examples.

What To Use

existing-secret configuration: 9 rendered objects · 1 image · 2 target prerequisites · 0 hook or setup routes · 6/6 checks passing. These counts come from the linked test records.

Use the public catalog entry, then check the exact configuration and its tests before making a production claim.

Four Separate Questions

Inspecting a source, producing objects, checking a destination, and checking a live result are different jobs. A Catalog match is useful for comparison but is not required. A missing destination or deployment is shown as not run or blocked, not as a failed configuration.

Open the complete assessment, source, lifecycle, and evidence record.

Where This Chart's Settings Come From

Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.

Read the full values-versus-ConfigHub rule. For the staging commands behind each prerequisite, open the prerequisite action packets.

What This Chart Contains

Shipping a chart as plain rendered YAML is faster and simpler, and it silently drops anything Helm was going to do afterwards. This section reports what a scan of the packaged chart found, across 45 files.

A flattening-safety verdict has decided this version: default:unsafe-to-flatten; existing-secret:unsafe-to-flatten; static-passwords:unsafe-to-flatten. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship.

A construct being present does not make a chart unflattenable. Most are switched on or off by values, and a verdict records which ones the base you choose actually reaches. Read the catalog-wide evidence for how common each one is.

What The Starting Configuration Records

A base variant is a starting configuration we have already rendered and checked. Pick the one whose trade-off you want; the table below shows what each one changes. How the values for each are chosen.

The existing-secret base-variant record connects those Helm inputs to the Kubernetes objects, remaining requirements, hooks, CRDs, checks, and OCI status. Open it when you need the complete starting record rather than only the rendered YAML.

Open the full rendered YAML to read the actual manifest output. The render record and setup section explain the inputs, tests, CRDs, hooks, and other work around it.

If new Helm values create a useful starting configuration, record another base variant with its own inputs and checks. If one environment changes a field after rendering, record that change in a ConfigHub variant.

How render intents work · All generated render intents · All base variant records

Try This Chart

Start with existing-secret. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.

cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-rabbitmq:16.0.14@sha256:fbdec937aa01df18d8cedc10a9dbd9b76f78cb209de1e6133f2118e92930fba9 --json

cub installer pull 'oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-rabbitmq:16.0.14@sha256:fbdec937aa01df18d8cedc10a9dbd9b76f78cb209de1e6133f2118e92930fba9' --work-dir ./package-review
less ./package-review/package/records/README.md

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/rabbitmq/16.0.14 --annotations confighub.com/package-sha256=1add13b1e9dc72f00b442b70ad31d86e00401dd102811b3935710af7255bb0da europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-rabbitmq:16.0.14@sha256:fbdec937aa01df18d8cedc10a9dbd9b76f78cb209de1e6133f2118e92930fba9

cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites

After You Render It

The first command writes files and does not apply them. Read the objects and setup requirements, then choose the next job.

Available Configurations

Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.

Checks: Each card names what was checked and says whether it passed, needs review, was blocked, was not run, or was not needed.

3 matrix rows for bitnami/rabbitmq@16.0.14 · open the full matrix

Local Configuration Checks

We ran cub check v0.7.3 against the exact rendered objects for every configuration below. The result is advisory: read each finding and decide whether it matters for your target.

What this does not check: hook execution, CRD readiness, target Secrets and cloud services, admission behavior, workload health, or rollback. The linked Catalog review covers chart-specific source and operating questions. ConfigHub validation and approval are separate managed controls.

Read all shared check results and the mapping to Catalog rules.

Images This Chart Pulls

Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.

First-Run Caveats

Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.

Open the all-chart adoption caveats · Helm to cub migration · cub deployment path

Advice And Current Status

Use this section to see which chart-specific guides apply, what you must provide, and what work remains.

The source data lives in chart skills and chart evidence router.

What Has Been Tested

Choose the question you care about. Not checked means this catalog has no version-specific result; it is not a pass.

How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, Local live, GitOps/OCI live, Live Helm-vs-ConfigHub, Two-cluster kind.

What You Must Provide

exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; install-vs-upgrade render divergence captured per revision; cluster lookups lifted into declared target facts

Hooks, CRDs, And Setup Work

Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.

What each base needs before apply

These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.

If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.

Before Production

A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.

Source And Evidence Files