Should I upgrade to CircleCI Server Bitnami Legacy Repository Cutover now?
Decide whether to patch statefulset image references, upgrade CircleCI Server, or accept outage risk when Kubernetes nodes restart and old docker.io/bitnami paths fail.
Blockers
- CircleCI Support lists 4.7.8 as a preferred remediation on an actively supported branch.
- CircleCI Support lists 4.8.2 as a preferred remediation on an actively supported branch.
- The 4.8.2 changelog says postgresql, mongodb, redis, and rabbitmq charts moved from Bitnami-hosted to CircleCI-hosted, and mongodb and redis images also moved to CircleCI-hosted.
- vendor/bitnami — EOL 2025-09-29
Who this is for
- enterprise
- compliance
- low-ops
Candidates
Upgrade CircleCI Server to the latest supported point release
As of 2026-04-01, CircleCI Support says the preferred remediation is to upgrade CircleCI Server to the latest point release on actively supported branches: 4.7.8 or 4.8.2. CircleCI states these releases update the Helm charts so the environment is no longer dependent on the old Bitnami repository paths. CircleCI's 4.8.2 changelog specifically says the postgresql, mongodb, redis, and rabbitmq charts moved from Bitnami-hosted to CircleCI-hosted, and mongodb and redis images also moved to CircleCI-hosted. This is the most durable path because it aligns the installation with CircleCI's maintained release stream rather than preserving archived image references.
When to choose
Use this when the cluster is still Helm-managed and you can schedule a normal Server upgrade window. It is the best choice for enterprise plus low-ops environments because CircleCI marks upgrade as a preferred solution and it reduces dependence on temporary archive paths.
Tradeoffs
Strongest long-term fix and best supportability, but it requires standard Server upgrade testing and following CircleCI's minor-version upgrade path.
Cautions
Do not skip unsupported minor-version jumps. CircleCI's upgrade-path guidance says minor versions cannot be skipped, even if some patch versions can be.
Keep current Server version but repoint image pulls through Helm to CircleCI-hosted registry
As of 2026-04-01, CircleCI documents a second preferred option: modify `values.yaml` so affected services use `cciserver.azurecr.io` and run `helm upgrade`. The support article shows this as an alternative to a full version upgrade when immediate image-path remediation is needed. This preserves Helm as the source of truth, which is operationally cleaner than editing live StatefulSets. CircleCI also says air-gapped installations that already copy images locally are not impacted, so a local mirrored approach fits the same operational goal.
When to choose
Use this when you need a fast registry cutover without immediately changing CircleCI Server minor or patch version. It is the best workaround when change control is tighter around application upgrades than around Helm values changes.
Tradeoffs
Lower blast radius than a full Server upgrade and remains declarative, but it is still a workaround rather than moving onto the latest maintained release.
Cautions
Apply the change through Helm rather than manual cluster edits, or future reconciles may revert it. Check official docs for the exact values and air-gapped copy procedure for your installed version.
Manually patch StatefulSets to docker.io/bitnamilegacy as a temporary stopgap
As of 2026-04-01, this has already occurred: Bitnami removed old versioned paths from `docker.io/bitnami` and moved archived images to `docker.io/bitnamilegacy`. CircleCI documents manual StatefulSet patching to the Bitnami Legacy repository as an acceptable but non-ideal fallback. Bitnami's own migration notice says the legacy catalog receives no further updates or support and should only be used for temporary migration purposes. Bitnami also states some images based on long-deprecated distros such as `debian-8`, `debian-9`, `debian-10`, `centos-7`, and `ol-7` were not copied.
When to choose
Use this only when you cannot complete a Helm-based registry change or a CircleCI Server upgrade before the next node recycle. It is appropriate as an outage-avoidance bridge, not as a steady-state operating model.
Tradeoffs
Fastest way to restore pulls for existing versioned tags, but it keeps you on archived images with no updates and creates drift from Helm-managed configuration.
Cautions
A later Helm upgrade can overwrite the live patch. Verify every exact image tag exists in `docker.io/bitnamilegacy` before relying on this path.
Do nothing and accept restart-triggered outage risk
As of 2026-04-01, this is no longer a pre-deadline planning scenario. CircleCI Support warns that if Kubernetes nodes restart after September 29, 2025 without updated image references, pods can fail to pull from the original repository and enter `ImagePullBackOff`. CircleCI further says this can stop Redis, PostgreSQL, MongoDB, and related data services, resulting in complete service disruption for CircleCI Server. This option has no cost advantage documented in official sources; it is simply accepting operational failure risk.
When to choose
Use this only if the installation is already air-gapped and therefore not affected, or if the environment is disposable and an outage is acceptable. For any production CircleCI Server deployment, this is not a reasonable operating choice after the cutoff.
Tradeoffs
No immediate engineering work, but the downside is possible full service disruption on any node or pod reschedule that requires a fresh image pull.
Cautions
Do not assume the cluster is safe just because it is currently running. The failure is commonly triggered on restart, reschedule, or replacement when a fresh pull is required.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to CircleCI Server Bitnami Legacy Repository Cutover now?"