Bitnami MongoDB alternative
Replacing bitnamilegacy/mongodb

Bitnami MongoDB variables and their official equivalents

Bitnami MongoDB image to official mongo:

What breaks when you switch

• The official image only creates the root user. Bitnami's app-user variables have to become a script in /docker-entrypoint-initdb.d.
• Replica set variables (MONGODB_REPLICA_SET_*) have no official equivalent.
• Official images for MongoDB 5.0 and later need a CPU with AVX, and the image warns at start-up when it is missing.

bitnami/mongodb Helm chart values the drop-in image reads

With architecture set to replicaset, the bitnami/mongodb chart runs its own setup script before mongod starts. The script sources /opt/bitnami/scripts/mongodb-env.sh, exports MONGODB_REPLICA_SET_MODE as primary or secondary, and then executes /opt/bitnami/scripts/mongodb/entrypoint.sh. In 10.x and early 11.x releases the role comes from the pod name. Later releases, including 12.x and 13.x, ask the running members for the current primary with mongosh. The official mongo image has none of those scripts. The OSSeva image keeps them. Checked against chart 10.31.5 (MongoDB 4.4) and 13.18.5 (MongoDB 6.0).

MongoDB versions OSSeva publishes

Each line below has a patched OSSeva image. The second column shows which bitnami/mongodb chart releases defaulted to that line, which tells you the chart major to stay on during the swap.

Replication and high availability in the MongoDB charts

What happened to the Bitnami MongoDB image

How to migrate MongoDB off Bitnami safely

1. Find every reference to bitnami/mongodb and bitnamilegacy/mongodb in running workloads, Helm values files and CI pipelines, including init containers.
2. Record the MongoDB version each deployment pins. Versions past upstream end of life are not covered by the free open source images.
3. Take a backup and test a restore before touching a stateful workload.
4. Mirror the replacement container images into your own registry, and scan them before you deploy.
5. Move one replica or one environment at a time, and confirm the data path, file ownership and credentials on the new image.
6. Remove every remaining legacy reference so nothing falls back to the archive on the next deploy.

Your options

Repoint the Bitnami MongoDB Helm chart

1. Run helm list to record the chart version, then helm get values <release> to save what is deployed.
2. Keep that chart major: 13.x for 6.0, 12.x for 5.0, 9.x to 11.x for 4.4.
3. Override image.registry, image.repository and image.tag on the same MongoDB minor version. The arbiter and hidden members pick up the same image.
4. Leave out global.security.allowInsecureImages. Bitnami added that image check in December 2024 (mongodb 16.4.0), and every chart for MongoDB 6.0 and earlier is older.
5. Run helm upgrade with --reuse-values and the override, then run rs.status() in mongosh and confirm every member reports a healthy state.

# values-osseva.yaml
# helm upgrade my-mongodb oci://registry-1.docker.io/bitnamicharts/mongodb \
#   --version 13.18.5 --reuse-values -f values-osseva.yaml
image:
  registry: registry.example.com   # OSSeva registry or your mirror of it
  repository: mongodb
  tag: "<6.0.x tag>"
global:
  imagePullSecrets:
    - registry-credentials

This works only with an image that keeps Bitnami's layout. With the official image, rewrite the chart or move to an operator. See replacing bitnamilegacy images for the full inventory and rollout steps.