Did your Bitnami chart stop pulling?

See one example

On 2026-09-17, all six pinned Bitnami charts in the Catalog still pulled anonymously from Docker Hub, with the exact reviewed bytes. Their old direct download links returned HTTP 403 for four of six. Two charts, mysql 14.0.3 and rabbitmq 16.0.14, name image tags that no longer exist under bitnami, only under bitnamilegacy. Those charts install, and their pods cannot pull the image. The receipt shows only that the bitnamilegacy copies resolved, not whether they are patched or will stay available. The other four run an image tagged latest, which resolves today but is not pinned.

The catalog keeps the reviewed bytes it already locked, and it names a successor for each component. Every candidate and every source status was measured live and re-verified by a second pass.

Each successor is a real catalog entry with its own rendered objects, license, and prerequisites. The chart shape often differs from Bitnami, so values need remapping; migration stays separate reviewed work per component, not a silent swap.

What "reviewed" covers is recorded per entry, and it is not the same for every one. The source was fetched anonymously and its bytes locked, the objects it renders are retained, and the flattening question is decided. Delivery through a ConfigHub server, promotion and live runs are recorded separately, and several successors have no such record yet. Each listing says which, so read the entry before you cite it.

Every listing for an affected chart also carries a successors block, so an agent reads the replacement from the same data rather than from this page.

Check your own chart before you install

Render your chart with the values you use, then ask whether every image it names still pulls. This works for any chart, not only the six in the table. Install the cub CLI, then add the Workshop plugin.

cub plugin install confighub/cub-workshop@v0.6.61
helm template orders oci://registry-1.docker.io/bitnamicharts/rabbitmq --version 16.0.14 -f my-values.yaml > render.yaml
cub config check render.yaml --images --exit-code

For this chart the check reports images that pull anonymously: 0 of 1 and names docker.io/bitnami/rabbitmq:4.1.3-debian-12-r1 as NOT FOUND. The fetch receipt below records the same result. With --exit-code, the check exits 1 when a registry confirms an image is missing, so a build can stop the install. Exit 2 means an authentication or network failure left the check incomplete, which is not the same as missing. This needs plugin version 0.6.41 or later.

Move your values to the successor

A successor reads different keys. Run your current values against it, and every key it has no place for comes back IGNORED.

cub config values oci://registry-1.docker.io/cloudpirates/rabbitmq --version 0.21.13   --values my-values.yaml --exit-code

Rename each key that comes back IGNORED, and run the check again until it exits 0. A suggested key can be only part of the answer, so read the successor's own values before you accept it.

When the successor is an operator, as for PostgreSQL, MongoDB and MySQL, your database becomes a custom resource rather than chart values. Expect the values check to show that nothing carries over, and plan the move as a migration rather than a rename.

Exit 0 does not finish the move. The values check cannot see a behavior the old chart turned on by default and the successor leaves off. Compare what the two renders install; this needs plugin version 0.6.46 or later.

cub config diff render.yaml successor.yaml --summary

The summary counts each kind of object in both renders. With these values, the Role, RoleBinding, ServiceAccount, PodDisruptionBudget and NetworkPolicy each go from 1 to 0. When the old render has a kind the new one lacks, find the successor setting that turns that behavior on, or decide you do not need it. For RabbitMQ, the Role and RoleBinding carry peer discovery, which joins replicas into one cluster. Matching counts do not prove matching behavior.

Then run the --images check on the successor's render. Each successor's chart page names the chart's upstream source, its images and whether they are pinned by digest.

Keep the result for the next change

Add --out values-report.json --render-out successor.yaml to the values check to keep the report and the exact successor objects beside your remapped values. The next session starts from those files, as the ignored-values page shows. Keep the render private and out of Git, because it can contain Secrets.

Know when ConfigHub helps

Most teams switch staging first and production later. Files are enough for the first environment. For the second, ConfigHub keeps the reviewed successor and your remapped values as one configuration, and promotes that same switch to production as a recorded change, rather than a second remap by hand.

It also keeps your deliberate edits to the successor as recorded changes and carries them through its next version, with a history you can roll back and an approval before the switch ships. Why do development and production differ? shows one checked promotion. ConfigHub Server explains what needs an account or a server you run yourself.

Check the record

Open the successor survey. It records the measured source status for every candidate, the ranked alternates behind each pick, and the license and publisher of each one.

Open the fetch receipt. For each pinned chart it records the direct download, the OCI pull and its archive hash, and whether the chart's default image still resolves under bitnami and under bitnamilegacy.

Do this next

Check your own render, open the successor for the component you lost, and move your values with the values check. Before you repeat the switch in production, keep it in ConfigHub so production gets the same reviewed change.

Find a successor in the Catalog