// OSSEVA FOR BITNAMI USERS
Bitnami images are no longer free. Your manifests may not have noticed.
The public docker.io/bitnami catalogue lost its versioned tags on 29 September 2025. Images that still pull are frequently resolving to a legacy archive that receives no security updates — which means the pipeline that did not break is the one to worry about.
Trusted globally by enterprises
What happened, and when
- 28 August 2025
Staged shutdown begins
Broadcom begins winding down the public docker.io/bitnami catalogue, with scheduled brownouts — deliberate short outages intended to surface dependencies before the permanent change.
- 29 September 2025
Public catalogue deleted
The public Bitnami catalogue on Docker Hub is removed. Older non-hardened Debian-based images are moved to a Bitnami Legacy archive which, with few exceptions, receives no further updates — including no security updates.
- Now
Free tier is development-only
A limited free tier remains: community images published only at the latest tag, meant for development. That is precisely what cannot be used in a reproducible production deployment.
- 31 August 2026
Folded into Broadcom TrueSource
Bitnami Secure Images becomes part of TrueSource Trusted Artifacts, alongside clean-room SLSA Build Level 3 builds of the Java, Python and Node.js ecosystems.
Replacement paths, image by image
None of these is a tag swap. Bitnami images carry their own environment-variable conventions, file paths and user IDs, so the migration is a configuration change. The notes below are where teams most often get caught.
| Bitnami image | Replacement | What bites |
|---|---|---|
| bitnami/postgresql | Official postgres image on Docker Hub, or a distro-maintained build. CloudNativePG for Kubernetes operators. | Config differs: Bitnami uses POSTGRESQL_* env vars and /bitnami/postgresql paths; the official image uses POSTGRES_* and /var/lib/postgresql/data. |
| bitnami/redis | Official redis image, or valkey/valkey for the BSD-licensed fork. | Bitnami's REDIS_PASSWORD handling and its default config file location are not replicated by the official image. |
| bitnami/kafka | apache/kafka (official, from Kafka 3.7), or build from the Apache distribution. | Bitnami's KAFKA_CFG_* env-var mapping is Bitnami-specific. The official image expects standard properties. |
| bitnami/rabbitmq | Official rabbitmq image, including the -management tags. | Plugin enablement and the definitions-import path differ. Check RABBITMQ_PLUGINS against enabled_plugins. |
| bitnami/mysql / mariadb | Official mysql or mariadb images. | Bitnami's replication env vars have no direct equivalent; replication must be configured explicitly. |
| Bitnami Helm charts | Charts remain available, but their default image references pointed at the deleted catalogue. | Override image.registry and image.repository, or move to an operator-based install. |
Why teams were on Bitnami in the first place
This is the part that determines whether swapping to official images actually solves your problem. A large share of Bitnami usage was not about convenience — it was about getting a maintained build of a version the upstream project had stopped publishing. Teams pinned to Bitnami precisely because it kept shipping updated images for older releases.
If that is why you were there, the official image does not replace it. The official image tracks current versions. Moving to it means taking the version upgrade you were avoiding, on someone else's schedule. That is the real project hiding inside what looks like a registry change.
Frequently asked questions
Are Bitnami images still free?
Only a limited development tier. Versioned tags in the public docker.io/bitnami catalogue were deleted on 29 September 2025. What remains free is a community subset published only at the latest tag, meant for development, which is not usable for reproducible production deployments. Production-grade images with version control require a Bitnami Secure Images subscription, now part of Broadcom TrueSource.
My deployment still pulls a Bitnami image and it works. Am I affected?
Probably yes, and this is the dangerous case. Older images were moved to a Bitnami Legacy archive rather than deleted outright, so pulls can still succeed while the image receives no further security updates. A manifest that keeps working is not evidence that it is maintained — check whether the tag you pull resolves to the legacy archive.
What did this actually break?
Two things, mostly. Build and deploy pipelines referencing docker.io/bitnami tags that no longer resolved, which failed loudly and got fixed. And manifests that silently pinned to legacy archive images, which did not fail and are still running unpatched. The second category is larger and is the one worth auditing.
Can we just switch to the official images?
Usually, but it is a configuration migration rather than a tag swap. Bitnami images use their own environment-variable conventions, file paths and non-root user IDs. The official images use upstream conventions. Expect to rewrite env blocks, volume mounts and sometimes securityContext. Test in a non-production namespace first — the failure mode is frequently a permissions error on a mounted volume.
What about the Bitnami Helm charts?
The charts themselves remain available, but their default values referenced the catalogue that was deleted. You can override the registry and repository values to point at replacement images, though chart templates still assume Bitnami's env-var conventions, so overriding the image alone is often not sufficient. For several workloads a purpose-built operator is a better destination than a patched chart.
Does OSSeva provide replacement container images?
Yes, for the technologies we support. OSSeva publishes signed, CVE-patched images for RabbitMQ, PostgreSQL, Redis, Kafka, ActiveMQ, Solr, NiFi and the rest of our covered set, including for versions upstream no longer patches. That last part is the relevant difference: the reason many teams were on Bitnami was to get a maintained build of an older version, and that is exactly what the legacy archive stopped providing.
Need the old version patched, not the new version deployed?
Most Bitnami migrations stall on the same thing: the reason you were there was to run a version upstream had abandoned. We patch those, so the registry change and the upgrade become two separate projects.