Apache Qpid Broker-J on Ubuntu 24.04 on Azure User Guide

Overview

Apache Qpid Broker-J is a pure Java message broker from the Apache Software Foundation that speaks every major version of the AMQP wire protocol (0-8, 0-9, 0-91, 0-10 and 1.0), so clients written for almost any AMQP library can connect to one broker. It provides durable queues, topics and exchanges for reliable asynchronous messaging, and ships with an HTTP web management console for creating queues, browsing messages, managing users and watching broker activity. The cloudimg image installs Qpid Broker-J 10.0.1 on OpenJDK 17 at /opt/qpid, runs it as a dedicated qpid system user, binds the management console to loopback behind an nginx TLS reverse proxy on :443, exposes AMQP on 5672 and TLS AMQPS on 5671, and generates a unique admin password and TLS certificate on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Apache Qpid Broker-J 10.0.1 broker on OpenJDK 17 at /opt/qpid, run by the dedicated qpid system user
• A single "Plain" authentication provider bound to every port, with no guest user and no anonymous access
• AMQP 5672 and TLS AMQPS 5671 message endpoints (AMQP 0-8 / 0-9 / 0-91 / 0-10 / 1.0)
• The HTTP web management console bound to loopback 127.0.0.1:8080, fronted by nginx on :443 with a per-VM self-signed TLS certificate (with :80 redirecting to HTTPS)
• Per-VM admin password (QPID_ADMIN_PASSWORD) generated at first boot, in a root only file
• qpid.service + nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point for the JVM broker; scale up for higher message throughput. NSG inbound: allow 22/tcp from your management network, 443/tcp for the web console, and the message ports your clients use (5672 AMQP and 5671 AMQPS) from your application networks.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache Qpid Broker-J by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create then Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name qpid \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name qpid --port 443 --priority 1010

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the services are running

systemctl is-active qpid.service nginx.service

Both services report active. The broker can take a minute or two to fully start on first boot while the JVM warms up. The AMQP acceptors listen on 5672 (AMQP) and 5671 (AMQPS); the management console listens on loopback 127.0.0.1:8080 and is reached through nginx on :443.

Step 5 — Retrieve your admin password

The admin password is generated uniquely on the first boot of your VM and written to a root only file:

sudo cat /root/qpid-broker-j-credentials.txt

The QPID_ADMIN_PASSWORD value is the password; sign in to the web console and authenticate AMQP clients as admin with it. No default or guest credential ships in the image, and no two VMs share a password.

Step 6 — Open the web management console

Browse to https://<vm-public-ip>/ and accept the per-VM self-signed certificate warning, then sign in as admin with the password from Step 5. The Qpid Broker-J console lets you inspect the broker, virtual host, ports and authentication providers, create and browse queues and exchanges, and watch live message statistics.

Step 7 — Verify the broker health

The management REST API is served behind the nginx TLS proxy. An unauthenticated request is rejected with 401, and the per-VM admin returns 200 with the broker attributes. Run on the VM:

PW=$(sudo grep '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'unauthenticated: HTTP %{http_code}\n' https://127.0.0.1/api/latest/broker
curl -sk -u "admin:$PW" https://127.0.0.1/api/latest/broker | head -c 200; echo

The first call prints HTTP 401 and the second returns a JSON document that includes the broker modelVersion and productVersion, confirming the console authenticates with the per-VM admin over TLS.

Step 8 — Send and receive a test message

A small AMQP round-trip helper ships with the image. It connects as the per-VM admin, declares a durable queue, publishes a message and consumes it back. Run on the VM:

PW=$(sudo grep '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
python3 /opt/qpid/bin/qpid-amqp-roundtrip.py admin "$PW"

It prints AMQP_RT_OK followed by the message body it published and consumed, proving an authenticated end to end AMQP round-trip against the broker.

Step 9 — Connect from your applications

Point AMQP clients at amqp://<vm-public-ip>:5672 and TLS clients at amqps://<vm-public-ip>:5671, authenticating as admin with the password from Step 5. Qpid Broker-J speaks AMQP 0-8, 0-9, 0-91, 0-10 and 1.0 on both ports, so libraries such as Qpid Proton, Apache Qpid JMS, and pika all interoperate with the same broker. Open the matching NSG ports from your application networks only, and prefer the TLS AMQPS listener for traffic that leaves your VNet.

# Python (AMQP 1.0) example using Qpid Proton:
#   from proton import Message
#   from proton.utils import BlockingConnection
#   conn = BlockingConnection("amqps://admin:<password>@<vm-public-ip>:5671", ssl_domain=...)

Step 10 — Authentication is enforced

Only clients presenting the per-VM credential are authorised. A wrong or anonymous AMQP credential is rejected by the broker, and the console requires the admin password. Run on the VM to confirm a bad credential is refused:

PW=$(sudo grep '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
python3 /opt/qpid/bin/qpid-amqp-roundtrip.py --negative admin "$PW"

It prints AMQP_AUTH_REJECTED, confirming the broker refuses a wrong credential (the Plain authentication provider has no guest user and no anonymous mechanism).

Using a real TLS certificate

The image ships a per-VM self-signed certificate so the console and AMQPS are encrypted out of the box. For production, terminate TLS at nginx with a real domain pointed at the VM's public IP. Install certbot and request a certificate (replace the domain):

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

To also present a CA signed certificate on the AMQPS listener, import your certificate and key into the broker keystore at /var/lib/qpid/etc/keystore.p12 and restart qpid.service.

Adding and rotating users

Manage broker users from the web console under authenticationproviders → passwordProvider, where you can add users, set passwords and remove the initial admin once you have created your own. Queues, exchanges and bindings are also created and browsed from the console, or through the broker REST API under /api/latest/.

Backup and maintenance

The broker configuration and any durable message state live under /var/lib/qpid on the OS disk; snapshot the VM disk in Azure to back it up, and keep the OS patched with sudo apt update && sudo apt upgrade. The broker restarts cleanly with sudo systemctl restart qpid.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and chat for help with broker configuration, AMQP protocol versions, queues and exchanges, TLS, users and backups.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.