Running RabbitMQ on EKS Without Bitnami — A Cluster-Operator-Based Setup

What I Built

I built a custom RabbitMQ deployment on AWS EKS from the ground up to replace Bitnami-dependent charts for a client's Django and Celery-based SaaS platform. The system uses the official RabbitMQ Cluster Operator orchestrated via ArgoCD and a custom, thin Helm chart to manage core task queues across multiple environments.

System Architecture

The infrastructure consists of two separate ArgoCD Application resources that deploy the messaging stack onto AWS EKS to serve downstream applications:

RabbitMQ Cluster Operator — Installed directly into its own rabbitmq-system namespace from upstream release manifests to manage the cluster lifecycle.

Thin Helm Chart — A custom-owned, minimal manifest used solely to render a single RabbitmqCluster custom resource without bundled third-party images or vendor defaults.

CRM Application Components — The downstream API, backend workers, beat scheduler, and Flower monitoring interface that consume the message broker.

Core Technical Behavior

The system executes via an operator-driven pattern rather than traditional template mechanics. The RabbitMQ Cluster Operator watches the cluster for RabbitmqCluster custom resources and automatically reconciles them into a StatefulSet, services, and local cluster configuration.

ArgoCD enforces explicit deployment sequencing at runtime. The operator application applies a negative sync-wave annotation, guaranteeing that CRDs and webhooks are created and verified before the second application attempts to deploy the actual broker resource.

Data ingestion and task execution rely on dynamic credential synchronization. Downstream application components bind directly to an internal cluster secret generated entirely by the operator, removing the necessity of storing explicit broker connection strings in Git repositories.

Scaling and runtime scheduling change based on target parameters. Multi-replica environments inject pod anti-affinity and zone-aware topology spread constraints to distribute workloads safely across nodes, while single-replica staging setups strip these constraints to allow scheduling on smaller node groups.

Traffic to the management interface is gated conditionally. The custom chart templates an Ingress resource behind an internal Application Load Balancer only when the opt-in flag is enabled, dynamically iterating over multi-host array scopes.

Key Engineering Decisions

Prioritizing an operator-first architecture choice over community charts. This shifts operational clustering, leader election, and automated upgrade mechanics from static, vendor-maintained Helm templates into active code maintained by the core RabbitMQ team.

Elimination of inherited vendor packaging defaults. Every configuration field inside the custom Helm chart was added because the client environment specifically required it, creating a values structure focused strictly on explicit storage classes, plugins, and resource parameters.

Sync-wave ordering as an architectural requirement. Utilizing a negative sync-wave combined with server-side apply ensures the operator’s structural dependencies exist first, while excluding CRD status fields and webhook values from ArgoCD's diff prevents reconciliation loops.

Environment-scaled termination grace periods. Production brokers use an elongated termination grace period of seven days to give active queues ample time to drain and rebalance during node churn, whereas development deployments override this setting to sixty seconds for speed.

Scoping configuration parameters and plugins by environment profile. The core platform toggles advanced cross-cluster forwarding using shovel management and specific memory watermarks in production, while running a stripped-down, light management footprint for standard development work.

Trade-offs

Optimized for: absolute control over exposed broker settings, a standardized deployment pattern across cluster environments, and independence from external chart packaging lifecycles.

Sacrificed: the immediate out-of-the-box convenience of large community charts, which include bundled metrics tools, complex default secret mappings, and pre-wired configurations.

Results / Cost Impact

The client eliminated third-party image deprecation and licensing vulnerabilities from their production background-job path.

The architecture established completely identical, zero-drift runtime behavior between environments and allowed non-production configurations to scale down dynamically to avoid idle infrastructure resource waste.

Conclusion

Transitioning to the RabbitMQ Cluster Operator replaces broad community charts with a lean manifest blueprint where core clustering logic is maintained by its actual authors. This setup provides predictable GitOps delivery and clean environmental scaling for critical message broker dependencies.