Back to all use cases
Erlang/OTPMessaging platform teams

When no supported runtime exists for your broker

RabbitMQ pins a supported Erlang/OTP range per broker line. For the older broker lines, every Erlang release in that range is itself past end of life -- so patching the runtime means moving the broker too.

Challenge

The broker's supported-Erlang matrix and Erlang's own EOL calendar have drifted apart. Upgrading Erlang past the supported range risks the broker refusing to start; staying inside it means running a runtime nobody patches. Neither option is available without a support relationship.

Environment

A RabbitMQ line whose entire supported Erlang/OTP range sits past community end of life.

Approach

OSSeva patches the Erlang/OTP release the broker actually supports, so the runtime gets CVE coverage without forcing a broker migration to escape the matrix.

What this delivers

A patched runtime inside the broker's supported range -- the two version decisions decoupled instead of forcing each other.

Go deeper

See every EOL & CVE-patching use case