RabbitMQ Vertical Scaler
Automatically scales RabbitMQ cluster resources (CPU/Memory) based on real-time queue metrics and message rates in Kubernetes.
A small, dependency-light Kubernetes control loop written in Go. It watches the RabbitMQ management API and patches the RabbitmqCluster custom resource's CPU/memory requests up or down as load changes — shipped as a single static binary in a distroless container.
⚠️ Note
Vertically scaling RabbitMQ is not generally recommended, since node restarts can cause temporary disruption and potential message loss. I understand and accept this trade-off. This scaler is intended as an alternative for infrequent or bursty workloads where some disruption is acceptable to save resources.
⚠️ Important: This scaler is recommended only for quorum queues with 3+ nodes. Using it on single-node RabbitMQ deployments will result in message loss during scaling operations.
ℹ️ v2.0.0 is a behaviour-identical rewrite of the Node.js v1 in Go — same scaling decisions, same env-var contract, same generated manifests, smaller footprint. See Upgrading from v1.
🚀 Features
- 🎯 Auto Scaling: Adjusts resources based on queue depth and message rates
- ⚡ Debounced: Prevents oscillation with configurable scale-up/scale-down delays
- 🔧 Configurable: Environment variables, config files, and CLI options
- 🐳 Cloud Native: Official
client-go, distroless image, single static binary
- 🪶 Tiny footprint: ~10–15 MB idle RSS, no interpreted runtime, minimal attack surface
📋 Table of Contents
🧭 Why Go (footprint, not speed)
This rewrite is not about speed. The workload is a low-frequency, I/O-bound
control loop: every few seconds it does one HTTP GET against the RabbitMQ
management API, compares a handful of numbers, and maybe issues a Kubernetes
PATCH. It is idle ~99.9% of the time and the bottleneck is the network call, not
the CPU. Go does not make any scaling decision perceptibly faster.
Go was chosen because, for a Kubernetes operator, it wins on what actually
matters for a tool whose entire pitch is saving cluster resources:
- Memory footprint — Node idles ~50–80 MB RSS; the Go binary idles ~10–15 MB. A fat runtime sidecar undercuts a resource-saver.
- Image & attack surface —
distroless/static:nonroot + one static binary, no shell, no package manager, no interpreter. Fewer CVEs, faster pulls.
- Ecosystem fit —
client-go is the official, first-class Kubernetes client; the whole operator ecosystem is Go.
- Dependency hygiene — stdlib
net/http instead of axios; client-go is the one real dependency.
- Distribution — a single cross-compiled binary (
go install or a release download); no "do you have Node 18+?".
See research/benchmark.md for the full methodology and the v1-vs-v2 numbers.
📦 Install
The CLI generates Kubernetes manifests; the same binary runs the controller in-cluster.
# Docker (controller image — also runs `generate`)
docker pull ferterahadi/rmq-vertical-scaler:2
# Go install (CLI / generator)
go install github.com/ferterahadi/rmq-vertical-scaler/cmd/rmq-vertical-scaler@latest
# Or grab a prebuilt binary from the GitHub Releases page (linux/amd64, linux/arm64)
⚡ Quick Start
# Generate manifests from a config file
rmq-vertical-scaler generate \
--config examples/production-config.json \
--output my-scaler.yaml
# Deploy to your cluster
kubectl apply -f my-scaler.yaml
Using the container image instead of a local binary:
docker run --rm -v "$PWD:/work" -w /work \
ferterahadi/rmq-vertical-scaler:2 generate \
--config examples/production-config.json --output my-scaler.yaml
⚙️ Configuration
The scaler supports two configuration methods.
Configuration File (Recommended)
# Use pre-built templates
rmq-vertical-scaler generate --config examples/basic-config.json
rmq-vertical-scaler generate --config examples/production-config.json
