Configure a self-managed external RabbitMQ¶

This page describes how to point DataRobot at a self-managed (non-cloud-managed) external RabbitMQ, and also documents the supported settings. Use this guide when you run your own RabbitMQ (VM, bare metal, or a broker you administer) rather than a cloud-managed broker such as Amazon MQ.

To use an external RabbitMQ, disable the bundled broker and provide the connection settings under global.rabbitmq in your values override.

Prerequisites¶

• A reachable RabbitMQ broker (version 3.13 recommended; quorum-queue defaults require 3.12+; Any version between 3.11+ to 4.0).
• RabbitMQ user credentials (username/password).
• If TLS is used, the trusted root CA certificate(s) mounted into the DataRobot pods.
• If the connecting user is not an administrator, the required virtual hosts must be created in advance (see Virtual hosts and queue types).

Connection configuration¶

Set the following under global.rabbitmq in your values override. Only internal, hostname, and auth are required; you can use the default values for all other parameters.

Protocols and ports¶

DataRobot connects to RabbitMQ over two channels:

• AMQP: The message protocol (amqp_protocol + port). amqp on 5672 (plaintext) or amqps on 5671 (TLS).
• HTTP management API: Used for management/health operations (http_protocol + http_port). http on 15672 (plaintext) or https on 15671 (TLS).

Set each protocol scheme and its port to match your broker's TLS configuration — for example, only use amqps with 5671 if the broker's AMQP listener is TLS-enabled. Ensure both the AMQP and management ports are reachable (firewall/security group) from the DataRobot pods.

TLS and certificates¶

To connect over TLS:

1. Set tls: true.
2. Set the protocol schemes to the TLS variants: amqp_protocol: amqps and http_protocol: https.
3. Set the TLS ports: port: 5671 and http_port: 15671.
4. Provide the trusted root CA that signed the broker's certificate and reference it with ca_cert_path. The file must be mounted into the DataRobot pods (e.g., via your custom CA bundle) and ca_cert_path must point to the in-pod path so that DataRobot can verify the broker certificate.

global:
  rabbitmq:
    internal: false
    hostname: "rabbitmq.internal.example.com"
    tls: true
    amqp_protocol: amqps
    port: 5671
    http_protocol: https
    http_port: 15671
    ca_cert_path: /etc/ssl/certs/rabbitmq-ca.crt
    auth:
      username: pcs-rabbitmq
      password: YOUR_RABBITMQ_PASSWORD

Authentication¶

DataRobot authenticates with auth.username / auth.password. The username defaults to pcs-rabbitmq; you may instead create your own user and set it in global.rabbitmq.auth.username. The user must have full permissions on every virtual host DataRobot uses (see Virtual hosts and queue types).

If the user has administrator privileges, DataRobot can create the virtual hosts on demand at install time. If it does not, a RabbitMQ administrator must create all required virtual hosts and grant this user permissions in advance (see the following example).

Non-TLS example¶

global:
  rabbitmq:
    internal: false
    hostname: "rabbitmq.internal.example.com"
    port: 5672
    amqp_protocol: amqp
    http_port: 15672
    http_protocol: http
    auth:
      username: pcs-rabbitmq
      password: YOUR_RABBITMQ_PASSWORD

Virtual hosts and queue types¶

DataRobot uses the following virtual hosts. All default to classic, except nbxv2 and buzok, which must default to quorum:

Create every virtual host with its default queue type and grant the DataRobot user full permissions (configure, write, read = .*). Set USER to pcs-rabbitmq or to the username you configured in global.rabbitmq.auth.username:

USER=pcs-rabbitmq

CLASSIC_VHOSTS="analytics auto_apps mmqueue notifications orm queue nbx csp-spark network_policies entitlement-service-civ2 covalent apigateway"
QUORUM_VHOSTS="nbxv2 buzok workload-api"

for v in $CLASSIC_VHOSTS; do
  rabbitmqctl add_vhost "$v"
  rabbitmqctl set_permissions -p "$v" "$USER" ".*" ".*" ".*"
done

for v in $QUORUM_VHOSTS; do
  rabbitmqctl add_vhost "$v" --default-queue-type quorum
  rabbitmqctl set_permissions -p "$v" "$USER" ".*" ".*" ".*"
done

curl -u <admin-user>:<admin-password> -XPUT \
  https://<host>:15671/api/vhosts/nbxv2 \
  -H 'content-type: application/json' \
  -d '{"default_queue_type":"quorum"}'

Notes on default queue type behavior:

• The default queue type applies only to newly declared queues that do not specify an explicit x-queue-type and are not overridden by a policy. Existing queues are not converted.
• Quorum queues must be durable, non-exclusive, and non-auto-delete; declarations that request transient/exclusive/auto-delete queues fall back to classic even when the vhost default is quorum.

Verify¶

# list vhosts and their default queue type
rabbitmqctl list_vhosts name default_queue_type

# confirm the DataRobot user's permissions on a vhost
rabbitmqctl list_permissions -p nbxv2

Troubleshooting¶

• Verify the broker is running and both the AMQP and HTTP management ports are reachable from the DataRobot pods.
• Confirm the protocol schemes and ports match the broker's TLS configuration (amqps/https + 5671/15671 when tls: true).
• For TLS verification failures, confirm ca_cert_path points to the correct in-pod path and the CA matches the broker certificate.
• Confirm the username/password are correct and the user has permissions on every virtual host DataRobot uses.
• For a limited user, confirm all required virtual hosts exist with the correct default queue type before installing.
• Review the DataRobot logs for connection or authorization errors.