RabbitMQ 3.7: What's New, Release History & Support Lifecycle

What Is New in RabbitMQ 3.7

RabbitMQ 3.7.0 is a major release packed with significant enhancements to the core server, management, tooling, and client libraries. It introduces a new configuration format, pluggable clustering, per-vhost message stores, and requires Erlang 19.3 or later.

What are the major breaking changes?

You must upgrade Erlang to at least version 19.3 before installing RabbitMQ 3.7. This version also fully supports Erlang/OTP 20.

The release decouples the .NET and Java client libraries from the server's release cycle. You now get them via NuGet and Maven repositories respectively. Also, the rabbitmq_management_visualiser plugin no longer ships with the server and must be disabled before upgrading.

HTTP API Changes

Several management API endpoints have minor breaking changes. For example, successful POST and PUT requests now return 201 Created instead of 204 No Content. The node stats endpoint returns a more detailed memory breakdown.

How is cluster formation improved?

Cluster setup for new nodes is now pluggable. You can discover peers using built-in file or DNS backends, or use community plugins for AWS, Consul, etcd, or Kubernetes.

Nodes can now be restarted in any order. A restarting node will attempt to reconnect to known peers several times, which simplifies recovery procedures. This feature was adopted from the rabbitmq-autocluster plugin.

What's new in the configuration system?

A new, simpler configuration file format is introduced, similar to sysctl or .ini files. You can use rabbitmq.conf for this new style while still supporting the classic Erlang term format in advanced.config.

# Example new format in rabbitmq.conf
loopback_users.guest = false
vm_memory_high_watermark.relative = 0.75

The system also now accepts config file paths with or without the .config or .conf extension, removing a common source of admin error.

How does the new logging system help operators?

RabbitMQ 3.7 switches to the Lager logging framework. This provides a dedicated debug log level, makes the system less prone to log overload, and allows for pluggable log backends.

You have finer control over log output and can route logs to different destinations. This is particularly useful for debugging in production without impacting performance.

What multi-tenancy improvements were added?

Each virtual host now uses its own dedicated message store. This reduces contention and improves isolation between tenants. It also paves the way for better backup and recovery tools.

Operators can set limits on the number of concurrent connections and queues per vhost. New "operator policies" let you enforce global limits, like message TTL, that merge with user-defined policies.

How are the command line tools better?

The CLI tools were completely redesigned to be extensible by plugins and support command aliases, similar to Git. A new rabbitmq-diagnostics command is added for health checks.

Useful new commands include closing all connections in a vhost in one go, listing non-AMQP connections (like MQTT), and checking for stuck processes within the broker.

What changed in the management plugin?

The statistics database is now distributed; each node stores its own metrics. This improves scalability and reduces cross-node traffic.

Users with the administrator tag now implicitly get full access to all vhosts, simplifying management. The plugin's HTTP layer was migrated from Webmachine to Cowboy REST, a more modern Erlang web server.