Installing on Windows
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:
- The basics of node configuration
- CLI tool authentication
- RabbitMQ Windows Service
- Managing the node
- Firewall and security tools effects
- Log file location
- Default user limitations
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:
- There must be only one Erlang version installed at a time
- Erlang must be installed using an administrative account
- It is highly recommended that RabbitMQ is also installed as an administrative account
- Installation path must only contain ASCII characters
- It may be necessary to manually copy the shared secret file used by CLI tools
- CLI tools require Windows console to operate in UTF-8 mode
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.
Note that 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,
and run it. It installs RabbitMQ as a Windows service and starts it using the default configuration.
|Installer for Windows systems (from GitHub)||rabbitmq-server-&version-server;.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.
On Windows, CLI tools have a
.bat suffix compared to other platforms. For example,
rabbitmqctl on Windows is invoked as
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
# 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
rabbitmqctl.bat help add_user
On Windows, the cookie file location depends on
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
and other CLI tools are used.
One of these options can be used to mitigate:
- Re-install RabbitMQ using an administrative user
- Copy the file
This is covered in more detail in the Configuration guide
Environment Variable Changes on Windows
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
sbin (as an administrator).
# 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:
- The node must be running
rabbitmqctl.batmust be able to authenticate with the node
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
See the documentation on access control for information on how to create more users and delete
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:
- 4369: epmd, a peer discovery service used by RabbitMQ nodes and CLI tools
- 5672, 5671: used by AMQP 0-9-1 and 1.0 clients without and with TLS
- 25672: used for inter-node and CLI tools communication (Erlang distribution server port) and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). Unless external connections on these ports are really necessary (e.g. the cluster uses federation or CLI tools are used on machines outside the subnet), these ports should not be publicly exposed. See networking guide for details.
- 35672-35682: used by CLI tools (Erlang distribution client ports) for communication with nodes and is allocated from a dynamic range (computed as server distribution port + 10000 through server distribution port + 10010). See networking guide for details.
- 15672: HTTP API clients, management UI and rabbitmqadmin (only if the management plugin is enabled)
- 61613, 61614: STOMP clients without and with TLS (only if the STOMP plugin is enabled)
- 1883, 8883: MQTT clients without and with TLS, if the MQTT plugin is enabled
- 15674: STOMP-over-WebSockets clients (only if the Web STOMP plugin is enabled)
- 15675: MQTT-over-WebSockets clients (only if the Web MQTT plugin is enabled)
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
erl_crash.dump file in the base directory of
the RabbitMQ server, defaulting to
%APPDATA%\%RABBITMQ_SERVICENAME% - typically