Bitnami RabbitMQ alternative
Replacing bitnamilegacy/rabbitmq

Bitnami RabbitMQ variables and their official equivalents

Bitnami RabbitMQ image to official rabbitmq (use the -management tags for the UI):

What breaks when you switch

• The node's data directory moves from /bitnami/rabbitmq/mnesia to /var/lib/rabbitmq, and the node name must stay the same or the node will not find its own data.
• Clustering settings differ; Bitnami's RABBITMQ_NODE_TYPE and cluster variables do not exist in the official image.
• Official images for current releases need RabbitMQ 4.x, which removed classic mirrored queues. A 3.13 cluster needs a maintained 3.13 image or a queue migration first.

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

The bitnami/rabbitmq chart names each node after its pod and builds the data path from that name. With clustering.addressType set to hostname, the default, RABBITMQ_NODE_NAME is rabbit@<pod>.<release>-headless.<namespace>.svc.cluster.local, and RABBITMQ_MNESIA_DIR is persistence.mountPath followed by the node name. A node that starts under a different name does not find its data. Swapping only the image keeps both, as long as the new image reads the same variables, which the OSSeva image does. Checked against chart 8.32.2 and 14.7.0 (RabbitMQ 3.13).

RabbitMQ versions OSSeva publishes

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

Replication and high availability in the RabbitMQ charts

What happened to the Bitnami RabbitMQ image

How to migrate RabbitMQ off Bitnami safely

1. Find every reference to bitnami/rabbitmq and bitnamilegacy/rabbitmq in running workloads, Helm values files and CI pipelines, including init containers.
2. Record the RabbitMQ 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 RabbitMQ Helm chart

1. Run helm list to record the chart version, then helm get values <release> to save what is deployed.
2. If auth.erlangCookie was empty at install time, copy the current cookie out of the release secret into a Secret you manage and reference it with auth.existingErlangSecret, so the upgrade cannot change it.
3. Override image.registry, image.repository and image.tag, keeping the same RabbitMQ minor version so the rolling restart stays inside one release series.
4. Leave out global.security.allowInsecureImages. Bitnami added that image check in December 2024 (rabbitmq 15.2.0), and every 3.x chart is older.
5. Run helm upgrade with --reuse-values and the override, then run rabbitmq-diagnostics cluster_status on one pod and confirm every node is listed as running.

# values-osseva.yaml
# helm upgrade my-rabbitmq oci://registry-1.docker.io/bitnamicharts/rabbitmq \
#   --version 14.7.0 --reuse-values -f values-osseva.yaml
image:
  registry: registry.example.com   # OSSeva registry or your mirror of it
  repository: rabbitmq
  tag: "<3.13.x tag>"
auth:
  existingErlangSecret: rabbitmq-erlang-cookie   # holds the current cookie
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.