RabbitMQ Cluster Operator vs Helm Chart: Which to Use on Kubernetes

For production RabbitMQ on Kubernetes, use the RabbitMQ Cluster Kubernetes Operator, with the Messaging Topology Operator alongside it. The operator keeps managing the cluster after install, including rolling restarts that wait for quorum queues, while a Helm chart renders manifests once and leaves every later change to you. The most widely used chart, Bitnami's, has also stopped tracking RabbitMQ: since Bitnami's 2025 catalog change its default image exists only in an archive that receives no updates. Helm and the operator are not mutually exclusive, and the sections below cover when each fits. Versions and dates were checked on 9 October 2026.

What the RabbitMQ Cluster Operator manages

The Cluster Operator is maintained by the RabbitMQ team under the Mozilla Public License 2.0. Version 2.23.0 shipped on 9 September 2026 and deploys RabbitMQ 4.3.4 by default. You declare one RabbitmqCluster resource and the operator creates and reconciles the StatefulSet, services, secrets and configuration behind it. The RabbitMQ documentation lists three ways to install it: the release manifest applied with kubectl apply, the kubectl rabbitmq plugin from krew, and Bitnami's packaged chart from an OCI registry.

Defaults worth knowing before the first production cluster:

• Graceful termination. A preStop hook checks the quorum status of quorum queues before a pod stops, and terminationGracePeriodSeconds defaults to 604800, one week, so the hook has time to finish.
• No PodDisruptionBudget. The operator does not create one. Add it yourself, or a node drain can take two members at once.
• One replica by default. Set three, and keep to odd numbers.
• Storage. Each pod gets a 10Gi persistent volume unless you size it, and if the cluster has no default storage class you must name one or the pods never schedule.
• Scaling. From operator 2.16.0 a cluster can scale to zero and back to its original size. Scaling down to a smaller size is not supported.

The PodDisruptionBudget is short enough to keep next to the cluster definition:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: orders-rabbitmq
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: orders

The operator labels every pod with app.kubernetes.io/name set to the RabbitmqCluster name, here orders.

The Messaging Topology Operator manages what lives inside a cluster created by the Cluster Operator. Its custom resources cover queues, exchanges, bindings, users, vhosts, permissions, topic permissions, policies, operator policies, federation upstreams, shovels, super streams and schema replication. Topology then sits in Git and goes through the same review as the cluster itself, instead of living in a definitions file someone imported once.

Three behaviors catch teams out. Deleting a custom resource deletes the object in RabbitMQ unless deletionPolicy is set to retain, which matters for a queue holding messages. The name, vhost and cluster reference of a resource cannot be changed after creation. And the Topology Operator does not work with a cluster that imports definitions at startup, so pick one method for each cluster.

In July 2025 Bitnami, now part of Broadcom, announced changes to its free catalog. After brownouts from 28 August, the public docker.io/bitnami catalog was removed on 29 September 2025. Existing versioned images moved to docker.io/bitnamilegacy, where they receive no updates. The free tier now offers a smaller set of hardened images on the latest tag only, intended for development, and the full versioned catalog with patches is the paid Bitnami Secure Images product.

The chart source on GitHub stays under Apache 2.0, and packaged charts remain at docker.io/bitnamicharts, but Bitnami said they would no longer receive updates. For RabbitMQ the effect is visible in the repository: on 9 October 2026 the RabbitMQ chart's default image is bitnami/rabbitmq:4.1.3-debian-12-r1, a tag that now exists only in bitnamilegacy/rabbitmq, last updated on 13 August 2025. Bitnami's chart for the Cluster Operator still references operator 2.16.1, against 2.23.0 upstream.

If you run the Bitnami chart today, there are three routes: point it at the legacy images and accept that nobody patches them, buy Bitnami Secure Images, or move to the operator with the official RabbitMQ image. The chart was written around Bitnami's image, so swapping in another image is a test project rather than a values change. The wider supply-chain question is covered in Bitnami image security and the enterprise alternatives.

The comparison most teams actually face in 2026:

Helm still has a place. Teams that standardize every deployment on Helm can template the RabbitmqCluster and topology resources in their own chart and let the operator do the work, which keeps one deployment tool without giving up reconciliation.

There are two kinds of upgrade, and they should never share a change window.

• Upgrading the operator. Existing clusters keep the defaults written into their manifests by the previous operator version. Some operator releases do restart RabbitMQ pods, and the documentation says any release that triggers a rolling restart notes it in its release notes. Read them before every operator upgrade, and upgrade the operator on its own.
• Upgrading RabbitMQ. Change the image in the RabbitmqCluster spec and apply it, and the operator rolls the cluster pod by pod. The version path is the same as anywhere else: supported upgrade hops, feature flags enabled before the next major, and Erlang compatibility. Upgrading RabbitMQ 3.x to 4.x without downtime covers the sequence.

With a plain Helm chart, helm upgrade re-renders the StatefulSet and Kubernetes restarts pods in its own order. The quorum checks, the pacing and the rollback plan are yours to build.

Quorum queues replicate across a majority of members, which is why three replicas is the practical minimum. One pod can be lost to a drain or a node failure while queues keep a majority. The operator's preStop hook and a PodDisruptionBudget of one together stop Kubernetes from taking the second.

Storage decides how fast a lost pod comes back. Each member needs its own persistent volume, and zone-bound block storage can only reattach in its own zone, so a node failure can leave a pod waiting on its volume. Spread pods across nodes and zones with anti-affinity, and use a storage class with WaitForFirstConsumer binding so each volume lands where its pod is scheduled.

Peer discovery changed in RabbitMQ 4.1. Since then only the pod with the lowest ordinal, almost always the one ending in -0, may form a new cluster, and the other pods keep trying to join it. If that pod cannot schedule on a fresh install, the others wait. The operator and the common charts configure discovery for you, which is one more reason not to hand-write the StatefulSet.

The incidents we are called for most, drains that take the quorum leader, volumes that will not reattach, OOM kills before the memory alarm and liveness probes that restart a recovering node, are covered with fixes in RabbitMQ on Kubernetes and OpenShift.

• Use the Cluster Operator for any production cluster where you can install CRDs. Add the Topology Operator if more than one team declares queues or users.
• Use Helm to drive the operator if Helm is your standard: template the custom resources, not a StatefulSet.
• Keep a standalone Helm chart only for short-lived test environments, or where cluster-scoped operators are forbidden, and own the images and upgrade sequencing yourself.
• Plan a move off the Bitnami chart if you run it in production, because its default images no longer receive fixes.

The full sequence of decisions, from storage classes to network policy, is in the RabbitMQ on Kubernetes guide. AceMQ provides RabbitMQ support on Kubernetes, including migrations from Helm charts to the operator, and Kubernetes and container support for the platform underneath.

• RabbitMQ — Kubernetes Operators overview
• RabbitMQ — Installing the Cluster Operator
• RabbitMQ — Using the Cluster Operator
• RabbitMQ — Upgrading the Cluster Operator
• RabbitMQ — Using the Messaging Topology Operator
• RabbitMQ — Cluster formation and peer discovery
• GitHub — rabbitmq/cluster-operator releases
• GitHub — rabbitmq/messaging-topology-operator
• Bitnami — Upcoming changes to the Bitnami catalog (announcement)
• GitHub — bitnami/charts RabbitMQ chart
• Docker Hub — bitnamilegacy/rabbitmq