Helm charts kept stale exporter images after Bitnami's move to bitnamilegacy

What happened

A post on dev.to documents a failure mode from Bitnami's image relocation that is easy to miss: Helm installs of PostgreSQL and Redis can keep running after a migration while their metrics exporters still point at the abandoned source.

According to the post, Bitnami's announcement moved historical images to docker.io/bitnamilegacy, a repository that receives no updates or support and is intended only as a transition. The author's deployments used Helm charts, which wire up not just the database container but also a metrics exporter and, optionally, an init container that adjusts volume permissions — all from Bitnami defaults.

The author repointed the main image repository to bitnamilegacy so existing versions kept running, treated the migration as complete, and later discovered a follow-up fix was still required: the PostgreSQL and Redis metrics exporters had not been switched over. The eventual patch was two small settings, one per chart's values file, setting metrics.image.repository to the legacy exporter image. The stated lesson: edited values do not guarantee that every container the chart actually produces has changed.

Verifying against rendered output

To re-check the mistake, the author reproduced it with a locally kept PostgreSQL chart 16.4.1 and Redis chart 20.6.2, noting these are historical reproduction conditions rather than recommendations for new deployments.

The values file set global.security.allowInsecureImages to true. Per the post, that chart version rejects substitute images it does not recognise, and this setting skips the source-identification check. It is not a security attestation, and it fixes no vulnerabilities.

Rendering the chart with helm template and grepping the output for image lines showed the gap clearly. With only the main image changed, the PostgreSQL container resolved to bitnamilegacy/postgresql while the metrics exporter still resolved to bitnami/postgres-exporter and the permissions init container to bitnami/os-shell. After the corrected values, all three pointed at bitnamilegacy. The Redis chart got the same treatment across its main container, exporter and init container — rendered and checked, though not exercised at runtime.

The author also kept chart versions and image tags fixed, changing only repositories, to isolate what was actually moving — and notes that whether those tags still cold-pull from Docker Hub was not re-tested.

Adding pgvector on the same base

A separate requirement, the pgvector extension for PostgreSQL, led to a custom build. Rather than swapping to another PostgreSQL distribution, which would require re-checking the entrypoint, environment variables, data directory and run user the chart expects, the author built on the same Bitnami base to keep the change small.

The Dockerfile is a two-stage build. A build stage installs build tools and git, clones pgvector v0.8.6, and compiles it with PG_CONFIG pointed at the Bitnami PostgreSQL installation; OPTFLAGS is emptied to stop -march=native from baking build-machine CPU instructions into the extension, which the post notes is pgvector's own portability guidance, not a cross-architecture guarantee. The final stage starts from the same base and copies only the compiled extension files, so the toolchain never reaches the shipped image.

Verification ran in a network-isolated container against a fresh test volume: data written by the original image remained readable, SHOW data_directory was unchanged, and the extension reported version 0.8.6 with a cosine distance of 1.000 between two orthogonal test vectors. The author is explicit about limits: no cross-major-version migration or production data was involved, and the result does not mean arbitrary PostgreSQL images are interchangeable.

What self-building does not fix

The post's closing argument is the sharpest part: running apt-get update in a build stage patches nothing in the final image, because the final stage still starts from the unmaintained legacy base. The custom image adds a capability; it does not restore maintenance. The remaining work includes tracking base and extension versions, matching the chart's startup conventions, and handling image retention and pinning — with digests, source commits and build dependencies required for anything approaching reproducible builds. Moving to a genuinely maintained image remains a separate task that a successful startup does not complete.

Why it matters

Bitnami images are the default substrate of countless Helm charts, so a catalog change upstream becomes quiet operational work downstream. Two practical warnings stand out. First, a chart contains several image repositories — main container, exporters, init containers — and a partial migration looks successful until it isn't; verify rendered output rather than edited values. Second, bitnamilegacy is explicitly unsupported, so building features on top of it leaves deployments on an unpatched base, and "it starts fine" is not the same as "someone maintains this."