Generic Binary Build ("Generic UNIX Build")
RabbitMQ releases include a binary package for Linux, MacOS, and *BSD systems. It is minimalistic and not opinionated in how it is installed, configured and managed. This package is recommended in environments where more opinionated installation options (the Debian or RPM packages, Homebrew, BSD ports) cannot be used. It is also the most convenient option for running multiple versions on the same machine in development environments, e.g. preview release testing. There’s a separate binary package for Windows.
|Generic UNIX binary build (tar.xz, from GitHub, recommended)||rabbitmq-server-generic-unix-&version-server;.tar.xz||Signature|
This package requires a supported version of Erlang to be installed in order to run.
rabbitmq-server-generic-unix-&version-server;.tar.xz archive and extract it.
Contained in the tarball is a directory named
rabbitmq_server-&version-server;. This directory is the node base directory. It should be
moved to a suitable application directory on the system, such as
sbin directory in that directory contains server and CLI tool scripts.
It is a good candidate for including into
Unlike some other installation methods, namely the Debian and RPM packages, RabbitMQ
generic UNIX binary build does not require
sudo. It can be uncompressed
into any location and started and managed using the scripts and CLI tools under
Default data directory location will be under
that is, in the installation directory.
Starting the Server
To start the server, run the
sbin/rabbitmq-server script. This
displays a short banner message, concluding with the message
“completed with [n] plugins.”, indicating that the
RabbitMQ broker has been started successfully.
To start the server in “detached” mode, use
rabbitmq-server -detached. This will run
the node process in the background.
Stopping the Server
To stop a running node, use
sbin/rabbitmqctl shutdown. The command
will wait for the node process to stop. If the target node is not running,
it will exit with an error.
Configuring the Server
RabbitMQ configuration file located at
is the primary way of configuring the node.
It is possible to use environment variables to control certain settings.
The recommended way of doing that is using the
Neither of these files exist after installation, so they must be created first.
See RabbitMQ configuration guide to learn more.
The generic binary build is designed to run without granted
permissions to directories outside of its base one. The directories and files used by default are
all held under the installation directory
which is in the $RABBITMQ_HOME
variable in the scripts.
The node can be instructed to use more conventional system directories for configuration, node data directory, log files, plugins and so on. In order to make the node use operating system defaults, locate the following line
sbin/rabbitmq-defaults script and
change this line to:
but do not modify any other line in this script.
Important: after this modification the default directory locations may point to non-existent directories or directories that the effective node user won’t have permissions for.
RABBITMQ_LOG_BASE may need to be created (the server will attempt to create them at startup), and the
enabled plugins file (
RABBITMQ_ENABLED_PLUGINS_FILE) will need
to be writable by rabbitmq-plugins.
The configuration files will be looked for in
RabbitMQ nodes bind to ports (open server TCP sockets) in order to accept client and CLI tool connections. Other processes and tools such as SELinux 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)
- 15692: Prometheus metrics (only if the Prometheus plugin is enabled)
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
To stop the server or check its status, etc., you can invoke
sbin/rabbitmqctl (as the user running
commands will report the node absence if no broker is running.
rabbitmqctl shutdownto stop the server
rabbitmqctl statusto check whether it is running
See CLI tools guide to learn more.
RabbitMQ installations running production workloads may need system
limits and kernel parameters tuning in order to handle a decent number of
concurrent connections and queues. The main setting that needs adjustment
is the max number of open files, also known as
The default value on many operating systems is too low for a messaging
1024 on several Linux distributions). We recommend allowing
for at least 65536 file descriptors for user
production environments. 4096 should be sufficient for many development
There are two limits in play: the maximum number of open files the OS kernel
fs.file-max on Linux,
kern.maxfilesperproc on OS X and FreeBSD) and the per-user limit (
The former must be higher than the latter.
For more information about controlling the system-wide limit,
please refer to the excellent Riak guide on open file limit tuning.
RabbitMQ management UI displays the number of file descriptors available for it to use on the Overview tab.
includes the same value. The following command
can be used to display effective limits for the current user. There may be more convenient
OS-specific ways of doing that for a running process, such as the
/proc filesystem on Linux.
Configuration management tools (e.g. Chef, Puppet, BOSH) provide assistance with system limit tuning. Our developer tools guide lists relevant modules and projects.