RabbitMQ supports plugins and a number of features are implemented as plugins that ship in the core distribution. This page documents the plugins that ship with RabbitMQ 3.7.7. Other plugins can be installed separately. A set of curated plugins is also available.

Plugins are activated when a node is started or at runtime when a CLI tool is used. For a plugin to be activated at boot, it must be enabled. To enable a plugin, use the rabbitmq-plugins:

rabbitmq-plugins enable plugin-name
And to disable a plugin, use:
rabbitmq-plugins disable plugin-name

A list of plugins available locally (in the node's plugins directory) as well as their status (enabled or disabled) can be obtained using :

rabbitmq-plugins list

Different Ways to Enable Plugins

The rabbitmq-plugins comand enables or disables plugins by contacting the running node to tell it to start or stop plugins as needed. It is possible to contact an arbitrary node -n option to specify a different node.

Having a node running before the plugins are enabled is not always practical or operator-friendly. For those cases rabbitmq-plugins provides an alternative way. If the --offline flag is specified, the tool will not contact any nodes and instead will modify the file containing the list of enabled plugins (appropriately named enabled_plugins) directly. This option is often optimal for node provisioning automation.

The enabled_plugins file is usually located in the node data directory or under /etc, together with configuration files. The file contains a list of plugin names ending with a dot. For example, when rabbitmq_management and rabbitmq_shovel plugins are enabled, the file contents will look like this:

Note that dependencies of plugins are not listed. Plugins with correct dependency metadata will specify their dependencies there and they will be enabled first at the time of plugin activation. Unlike rabbitmq-plugins disable calls against a running node, changes to the file require a node restart.

The file can be generated by deployment tools. This is another automation-friendly approach. When a plugin must be disabled, it should be removed from the list and the node must be restarted.

For more information on rabbitmq-plugins, consult the manual page.

Plugin Tiers

Plugins that ship with the RabbitMQ distributions are often referred to as tier 1 plugins. Provided that a standard distribution package is used they do not need to be installed but do need to be enabled before they can be used.

In addition to the plugins bundled with the server, team RabbitMQ offers binary downloads of curated plugins which have been contributed by authors in the community. See the community plugins page for more details.

Even more plugins can be found on GitHub, GitLab, Bitbucket and similar services.

Tier 1 (Core) Plugins

The table below lists tier 1 (core) plugins that ship with RabbitMQ.

AMQP 1.0 protocol support. This plugin is several years old and is moderately mature. It may have certain limitations with its current architecture but most major AMQP 1.0 features should be in place.
Authentication / authorisation plugin using an external LDAP server.
Authentication / authorisation plugin that uses an external HTTP API.
Authentication mechanism plugin using SASL EXTERNAL to authenticate using TLS (x509) client certificates.
Consistent hash exchange type.
Scalable messaging across WANs and administrative domains.
Shows federation status in the management API and UI. Only of use when using rabbitmq_federation in conjunction with rabbitmq_management. In a heterogenous cluster this should be installed on the same nodes as rabbitmq_management.
A management / monitoring API over HTTP, along with a browser-based UI.
When installing the management plugin on some of the nodes in a cluster, you must install rabbitmq_management_agent on all of the nodes in the cluster. You can install the full management plugin on as many of the nodes as you want.
An adapter implementing the MQTT 3.1 protocol.
A plug-in for RabbitMQ that shovels messages from a queue on one broker to an exchange on another broker.
Shows shovel status in the management API and UI. See the plugin README for this plugin. Only of use when using rabbitmq_shovel in conjunction with rabbitmq_management. In a heterogenous cluster this should be installed on the same nodes as rabbitmq_management.
Provides STOMP protocol support in RabbitMQ.
Adds message tracing to the management plugin. Logs messages from the firehose in a couple of formats.
Provides a client x509 certificate trust store.
STOMP-over-WebSockets: a bridge exposing rabbitmq_stomp to web browsers using WebSockets.
MQTT-over-WebSockets: a bridge exposing rabbitmq_mqtt to Web browsers using WebSockets.
Adds some basic examples to rabbitmq_web_stomp: a simple "echo" service and a basic canvas-based collaboration tool.
Adds some basic examples to rabbitmq_web_mqtt: a simple "echo" service and a basic canvas-based collaboration tool.


All plugins below have been discontinued. They don't (or won't) ship with the RabbitMQ distribution and are no longer maintained.

Broker topology visualiser plugin which is itself a plugin to the management plugin. Adds a Visualiser tab to the management web interface, which then flexibly and interactively displays channels, queues and exchanges, and the links between them.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don't hesitate to ask them on the RabbitMQ mailing list.

Documentation feedback is also very welcome on the list. If you'd like to contribute an improvement to the site, its source is available on GitHub.