Plugin Development Guide

This is the RabbitMQ Server Plugin Development Guide. It is expected that before reading this guide, the reader has a basic understanding of the RabbitMQ plugin mechanism. Readers are also expected to have a basic understanding of Erlang OTP system and design principles.

Why Write A Plugin?

Writing a RabbitMQ plugin provides a number of appealing possibilities:

  • Enable your application to access internal RabbitMQ functionality that is not exposed via one of the supported protocols.
  • Running in the same Erlang VM as the broker may increase performance for certain applications.
  • Plugins provide an easy deployment model, since they allow for a single "RabbitMQ Appliance" to be built that acts in a self-contained manner. This can be useful both for easing production deployments, and for producing all-in-one infrastructure for use during development.

Why To Not Write A Plugin

As with any plugin mechanism, consideration should be given when developing functionality as to whether embedding it as a plugin is the most appropriate path to take. Some reasons that you might not want to develop your functionality as a plugin:

  • Depending on undocumented internal Rabbit APIs can result in your application requiring changes when RabbitMQ is updated. If you can do what you need to do without using RabbitMQ internals, then your application will be far more compatible in the future.
  • As mentioned in the Admin Guide, a poorly written plugin can result in the entire broker crashing!

Getting Started

To develop a RabbitMQ plugin, first make sure the following requirements are met:

  • Ensure that you have a working installation of Git.
  • Ensure that the dependencies detailed in the Server Build documentation are installed and functional. is used to build RabbitMQ and its plugins. The easiest way to start on a new plugin is probably to copy an existing plugin such as rabbitmq-metronome, used as an example below.

Activating Plugins During Development

To test your plugin while you're working on it, you can start a broker with your plugin enabled:

make run-broker

Plugin Quality Tips

As highlighted in the Administration Guide, badly-written plugins can pose a risk to the stability of the broker. The following tips aim to provide a series of best-practices for ensuring that your plugin can safely co-exist with Rabbit.

  • Always install a Supervisor above your application. You should never start your application directly, instead opting to create a (possibly quite trivial) supervisor that will prevent the Erlang VM from shutting down due to a crashed top-level application.

Broker and Dependency Version Constraints

It's possible to specify broker and dependency version requirements for a plugin using the broker_version_requirements key in plugin's .app.src file. The requirements are specified as a list of minimum version in each release series. Consider the following example:

{application, my_plugin,[
            {broker_version_requirements, ["3.5.2", "3.6.1", "3.7.0"]}
The above requires RabbitMQ 3.5.x starting with 3.5.2, 3.6.x starting with 3.6.1 and all versions in the 3.7.x series. Note that when new major and minor (feature) RabbitMQ versions come out, it is necessary for plugin maintainers to update the list.

Plugins can have dependencies. It is possible to specify supported version series for dependencies, too. This is quite similar to the above but uses a dictionary-like data structure (proplist). For example:

{application, my_plugin, [
            {dependency_version_requirements, [{rabbitmq_management, ["3.6.1", "3.7.0"]}]}
means the plugin depends on rabbitmq_management 3.6.x starting with 3.6.1 and all versions in the 3.7.x series.

Example Plugin: Metronome

Seeing as no development guide would be complete without a Hello World example, the following tries to provide the basics of how your would build your very own RabbitMQ plugin. The following example details how you might build a simple plugin that acts like a metronome. Every second, it fires a message that has a routing key in the form to a topic exchange called "metronome" by default. Applications can attach queues to this exchange with various routing keys in order to be invoked at regular intervals. For example, to receive a message every second, a binding of "*.*.*.*.*.*.*" could be applied. To recieve a message every minute, a binding of "*.*.*.*.*.*.00" could be applied instead.

The rabbitmq-metronome repository on GitHub contains a copy of the code for this plugin.

The following table should explain the purpose of the various files in the repository.

Filename Purpose
Makefile This top-level Makefile defines the name of your plugin and its dependencies. The name must match the Erlang application name. Dependencies are declared using's variables. Just after that, the Makefile includes and, as well as using plugins facility. See below for a description of those files. A local copy of This is not a vanilla copy because RabbitMQ relies on a few modifications which have not been merged upstream at the time of this writing. That's why ERLANG_MK_REPO and ERLANG_MK_COMMIT are overridden for now.
build.config This file configures which features of should be enabled. In most of RabbitMQ's plugins, EUnit is disabled, because they depend on a running broker. Our extensions take care of starting a node and run the EUnit tests when you type make tests. A local copy of The original file is in rabbitmq-common which your plugin will depend on automatically. It contains other extensions and helpers which must be defined before inclusion. This file must be kept up-to-date w.r.t. rabbitmq-common: when it is out-of-date, you will get the following error:
error: must be updated!
In this case, just run the following command to update your copy:
make rabbitmq-components-mk
rabbitmq_metronome.schema A Cuttlefish configrution schema. Used to translate configuration file to the internal format used by RabbitMQ and its runtime. Metronome schema contains mappings for the setting, setting the exchange used by the plugin. Default value is defined in Configuration will be regenerated when the plugin is enabled. Plugin-specific values in the config will cause error if plugin has not been enabled. More information about writing schema files can be found in the Cuttlefish docs.
src/ This file declares the dependencies required by the plugin (rabbit and amqp_client). These applications will be available and started before starting the plugin. Note that the real .app file is generated from this .app.src; there is no need to fill in the list of modules. You can let the vsn field empty: it will inherit RabbitMQ's version.
src/rabbit_metronome.erl Implementation of the Erlang "application" behaviour. Provides a means for the Erlang VM to start and stop the plugin.
src/rabbit_metronome_sup.erl Implementation of the Erlang "supervisor" behaviour. Monitors the worker process and restarts it if it crashes.
src/rabbit_metronome_worker.erl The core of the plugin. The worker will connect internally to the broker, then create a task that will be triggered every second.
test/rabbit_metronome_tests.erl Automated tests for the plugin.
  • Run make to build your application:
  • Start up your Rabbit broker:
    make run-broker
  • To ensure that your new plugin is up and running, run the following command:
    ./deps/rabbit/scripts/rabbitmqctl status
    If your plugin has loaded successfully, you should see an entry in the returned list that looks like:
    {rabbitmq_metronome,"Embedded Rabbit Metronome",[]}
  • You can run the automated tests by issuing:
    make tests
  • Finally, you can produce a .ez file, suitable for distribution with:
    make dist
    The file appears in the plugins subdirectory.