See one example
On 2026-08-08 an anonymous fetch of the pinned Bitnami packages returned HTTP 403 for four of six. 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.
| Bitnami chart | Verified successor | License | Shape |
|---|---|---|---|
redis | redis (CloudPirates) | Apache-2.0 | plain chart |
nginx | nginx (CloudPirates) | Apache-2.0 | OCI chart |
postgresql | CloudNativePG operator, with its companion cluster chart | Apache-2.0 | operator |
mongodb | Percona Operator for MongoDB | Apache-2.0 | operator |
rabbitmq | rabbitmq (CloudPirates) | Apache-2.0 | OCI chart |
mysql | Oracle MySQL Operator for Kubernetes | UPL-1.0 | operator |
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.
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.
Do this next
Open the successor for the component you lost, read its exact objects and prerequisites, then plan the values remap.