This guide covers RabbitMQ installation on Windows. It focuses on the two recommended installation options:
The guide also covers a few post-installation topics in the context of Windows:
and more. These topics are covered in more details in the rest of documentation guides.
A separate companion guide covers known Windows-specific issues and ways to mitigate them.
RabbitMQ packages are distributed via Chocolatey. New releases can take a while (sometimes weeks) to get through approvals, so this option is not guaranteed to provide the latest release. It does, however, manage the required dependencies.
To install RabbitMQ using Chocolatey, run the following command from the command line or from PowerShell:
choco install rabbitmq
For many use cases, Chocolatey is the optimal installation method.
The Chocolatey RabbitMQ package is open source and can be found on GitHub.
The official RabbitMQ installer is produced for every RabbitMQ release.
Compared to installation via Chocolatey, this option gives Windows users the most flexibility but also requires them to be aware of certain assumptions and requirements in the installer:
When these conditions are not met, Windows service and CLI tools may require reinstallation or other manual steps to get them to function as expected.
This is covered in more detail in the Windows-specific Issues guide.
RabbitMQ requires a 64-bit supported version of Erlang for Windows to be installed.
Erlang 25.3 is the latest supported version. Binary builds of other (for example, earlier) versions of Erlang for Windows can be obtained from the Erlang/OTP Version Tree page.
Erlang must be installed using an administrative account or it won't be discoverable to the RabbitMQ Windows service. Once a supported version of Erlang is installed, download the RabbitMQ installer, rabbitmq-server-{version}.exe and run it. It installs RabbitMQ as a Windows service and starts it using the default configuration.
Description | Download | Signature |
---|---|---|
Installer for Windows systems (from GitHub) | rabbitmq-server-3.12.0.exe | Signature |
Once both Erlang and RabbitMQ have been installed, a RabbitMQ node can be started as a Windows service. The RabbitMQ service starts automatically. RabbitMQ Windows service can be managed from the Start menu.
RabbitMQ nodes are often managed, inspected and operated using CLI Tools in PowerShell.
On Windows, CLI tools have a .bat suffix compared to other platforms. For example, rabbitmqctl on Windows is invoked as rabbitmqctl.bat.
In order for these tools to work they must be able to authenticate with RabbitMQ nodes using a shared secret file called the Erlang cookie.
The main CLI tools guide covers most topics related to command line tool usage.
In order to explore what commands various RabbitMQ CLI tools provide, use the help command:
# lists commands provided by rabbitmqctl.bat rabbitmqctl.bat help # lists commands provided by rabbitmq-diagnostics.bat rabbitmq-diagnostics.bat help # ...you guessed it! rabbitmq-plugins.bat help
To learn about a specific command, pass its name as an argument to help:
rabbitmqctl.bat help add_user
On Windows, the cookie file location depends on whether the HOMEDRIVE and HOMEPATH environment variables are set.
If RabbitMQ is installed using a non-administrative account, a shared secret file used by nodes and CLI tools will not be placed into a correct location, leading to authentication failures when rabbitmqctl.bat and other CLI tools are used.
One of these options can be used to mitigate:
The service starts using its default settings, listening for connections on default interfaces and ports.
Node configuration is primarily done using a configuration file. A number of available environment variables can be used to control node's data location, configuration file path and so on.
This is covered in more detail in the Configuration guide
Important: after setting environment variables, it is necessary to re-install the Windows service. Restarting the service will not be sufficient.
Links to RabbitMQ directories can be found in the Start Menu.
There is also a link to a command prompt window that will start in the sbin dir, in the Start Menu. This is the most convenient way to run the command line tools.
Note that CLI tools will have to authenticate to the target RabbitMQ node.
To stop the broker or check its status, use rabbitmqctl.bat in sbin (as an administrator).
rabbitmqctl.bat stop
The following CLI command runs a basic health check and displays some information about the node if it is running.
# A basic health check of both the node and CLI tool connectivity/authentication rabbitmqctl.bat status
For it to work, two conditions must be true:
See the CLI tools section and the Monitoring and Health Checks guide to learn more.
Server logs are critically important in troubleshooting and root cause analysis. See Logging and File and Directory Location guides to learn about log file location, log rotation and more.
Firewalls and security tools can prevent RabbitMQ Windows service and CLI tools from operating correctly.
Such tools should be configured to whitelist access to ports used by RabbitMQ.
The broker creates a user guest with password guest. Unconfigured clients will in general use these credentials. By default, these credentials can only be used when connecting to the broker as localhost so you will need to take action before connecting from any other machine.
See the documentation on access control for information on how to create more users and delete the guest user.
RabbitMQ nodes bind to ports (open server TCP sockets) in order to accept client and CLI tool connections. Other processes and tools such as anti-virus software may prevent RabbitMQ from binding to a port. When that happens, the node will fail to start.
CLI tools, client libraries and RabbitMQ nodes also open connections (client TCP sockets). Firewalls can prevent nodes and CLI tools from communicating with each other. Make sure the following ports are accessible:
It is possible to configure RabbitMQ to use different ports and specific network interfaces.
If you have an existing installation and are planning to upgrade the Erlang VM from a 32-bit to a 64-bit version then you must uninstall the broker before upgrading the VM. The installer will not be able to stop or remove a service that was installed with an Erlang VM of a different architecture.
In the event that the Erlang VM terminates when RabbitMQ is running as a service, rather than writing the crash dump to the current directory (which doesn't make sense for a service) it is written to an erl_crash.dump file in the base directory of the RabbitMQ server, defaulting to %APPDATA%\%RABBITMQ_SERVICENAME% - typically %APPDATA%\RabbitMQ otherwise.
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.
If you'd like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!