Deployment guide

Qpid Broker-J

Overview

Apache Qpid Broker-J is a pure Java message broker from the Apache Software Foundation. It 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, plus an HTTP web management console for creating queues, browsing messages, managing users and watching broker activity.

This SecureAnyCloud image installs Qpid Broker-J 10.0.1 on OpenJDK 17 at /opt/qpid and runs it as a dedicated qpid system user. Every VM generates its own admin password and TLS certificate on first boot.

What you get:

Apache Qpid Broker-J 10.0.1 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 on 5672 and TLS AMQPS on 5671 (AMQP 0-8, 0-9, 0-91, 0-10 and 1.0)
The HTTP web management console bound to loopback 127.0.0.1:8080 and fronted by an nginx TLS reverse proxy on :443 with a per-VM self-signed certificate, with :80 redirecting to HTTPS
A per-VM admin password (QPID_ADMIN_PASSWORD) generated on first boot and stored in a root-only file
qpid.service and nginx.service as enabled, active systemd units
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting size for the JVM broker. Scale up for higher message throughput.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 443/tcp for the web console. Also allow the message ports your clients use, 5672 for AMQP and 5671 for 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 SecureAnyCloud, and select Create.

On the Basics tab, 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).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:qpid-broker-j-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name qpid \
  --image sac1647283583153:qpid-broker-j-ubuntu-24-04:default:latest \
  --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

Check that both services are active.

systemctl is-active qpid.service nginx.service

Both services report active. On first boot the broker can take a minute or two to start 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

Your VM generates a unique admin password on first boot and writes it to a root-only file. Read it with sudo:

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

The QPID_ADMIN_PASSWORD value is the password. Use it to sign in to the web console and to authenticate AMQP clients as admin.

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. 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. You can also 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 these commands 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. The second returns a JSON document that includes the broker modelVersion and productVersion, which confirms that the console authenticates the per-VM admin over TLS.

Step 8 - Send and receive a test message

The image includes a small AMQP round-trip helper. It connects as the per-VM admin, declares a durable queue, publishes a message and consumes it back. Run it 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. This confirms 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. Authenticate 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 work with the same broker.

Open the matching NSG ports from your application networks only. 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 - Confirm authentication is enforced

Only clients that present the per-VM credential are authorized. The broker rejects a wrong or anonymous AMQP credential, and the console requires the admin password. Run this on the VM to confirm that 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, which confirms that 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, replacing the domain with your own:

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

To present a CA-signed certificate on the AMQPS listener as well, 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 in the web console under authenticationproviders > passwordProvider. You can add users, set passwords and remove the initial admin once you have created your own.

You can also create and browse queues, exchanges and bindings 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.

Keep the OS patched with sudo apt update && sudo apt upgrade. Restart the broker cleanly with sudo systemctl restart qpid.

Support

24/7 SecureAnyCloud support backs this image. Contact us by email or 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.

Deploy on Azure

Launch Apache Qpid Broker-J on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

Apache Qpid Broker-J is a pure Java message broker from the Apache Qpid project. It speaks the full range of AMQP versions on a single server: 1.0 alongside 0-8, 0-9, 0-9-1 and 0-10. That makes it a practical bridge between older AMQP clients and modern AMQP 1.0 applications.

The stock Qpid Broker-J configuration ships a well-known guest/guest account that is accepted on both the message listeners and the management console. This image does not. It ships with no rendered broker configuration at all, so the broker cannot start until first boot generates a unique administrator password for your instance.

What you get:

Apache Qpid Broker-J 10.0.1 from the official Apache release distribution (Apache License 2.0), sha512 verified at build time
OpenJDK 17 headless runtime, with the broker running as the unprivileged qpid system user under systemd
AMQP on 0.0.0.0:5672 and AMQPS on 0.0.0.0:5671, both requiring authentication
The management console bound to 127.0.0.1:8080 and published only through nginx on :443 with a per-instance self-signed certificate, with :80 redirecting to HTTPS
An unauthenticated /health endpoint for load balancer probes
qpid-broker-j-firstboot.service, which generates a 28-character administrator password, a per-instance TLS certificate and a per-instance AMQPS keystore, and writes /root/qpid-broker-j-credentials.txt (mode 0600 root:root)
python3-pika for the bundled AMQP round-trip helper
24/7 SecureAnyCloud support

Prerequisites

You need an AWS account, an EC2 key pair, and a VPC subnet.

Configure the security group to allow inbound TCP 22 (SSH), 443 (management console), and 5672 and 5671 (messaging) from your trusted CIDR.

m5.large is a comfortable default. The broker is a JVM service sized for roughly a gigabyte of heap plus a gigabyte of direct memory.

Connecting to your instance

SSH in as the default login user for the operating system variant you launched. This listing currently ships one variant:

OS variant SSH login user

Ubuntu 24.04 LTS ubuntu

ssh ubuntu@<public-ip>

Launch from AWS Marketplace

Subscribe to the SecureAnyCloud Apache Qpid Broker-J listing and launch an instance. Pick m5.large and choose your VPC and subnet. Attach a security group that allows inbound TCP 22, 443, 5672 and 5671 from your trusted CIDR.

Connect over SSH

ssh ubuntu@<public-ip>

Check the Service Status

Confirm that the broker and the TLS reverse proxy are both active.

sudo systemctl is-active qpid nginx

active active

Confirm the Health Endpoint

nginx serves an unauthenticated health endpoint. Point an Application Load Balancer target group or an external uptime check at it, so probes never need credentials.

curl -sk -o /dev/null -w 'health HTTP %{http_code}\n' -m 10 https://127.0.0.1/health

health HTTP 200

Confirm Secure-by-Default Authentication

The management API must reject an unauthenticated request.

curl -sk -o /dev/null -w 'unauthenticated management API HTTP %{http_code}\n' -m 10 https://127.0.0.1/api/latest/broker

unauthenticated management API HTTP 401

Next, confirm the listener topology. The two messaging ports are network-facing, the management port is loopback-only, and nginx alone is publicly bound.

sudo ss -tlnp | grep -E ':5672|:5671|:8080|:443 ' | awk '{print $1, $4}'

LISTEN 0.0.0.0:443 LISTEN [::ffff:127.0.0.1]:8080 LISTEN *:5671 LISTEN *:5672 LISTEN [::]:443

127.0.0.1:8080 is the key line. The management console cannot be reached from the network except through the TLS proxy.

Read Per-Instance Credentials

First boot generated this instance's administrator password. Read it with sudo.

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

Note QPID_ADMIN_USER (admin) and QPID_ADMIN_PASSWORD. Both are unique to this instance and exist nowhere in the image.

Sign In to the Management Console

Browse to https://<public-ip>/. The image ships a self-signed certificate that is regenerated for your instance, so your browser warns on first visit. Accept the warning, or replace the certificate as described in Step 12.

The console presents its own sign-in form, which shows that the broker is not open.

Sign in as admin with the generated password. The broker view opens and lists the virtual hosts, the configured ports, the broker loggers and the authentication providers.

Check the Ports table. AMQP and AMQPS are bound to *, while HTTP is bound to 127.0.0.1. This is the loopback restriction, visible in the broker's own UI.

Explore the Virtual Host

Expand virtualhostnodes in the tree and open default. The virtual host view shows live message and queue depth statistics and the four standard AMQP exchanges, ready for you to bind queues to.

Confirm the Broker Version and Ports over the API

Everything the console does is also available through the REST API with the same credentials.

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$P" -m 15 https://127.0.0.1/api/latest/broker | python3 -c "import sys,json;d=json.load(sys.stdin);b=d[0] if isinstance(d,list) else d;print('broker product:',b.get('productVersion'));print('model version:',b.get('modelVersion'))"

broker product: 10.0.1 model version: 9.1

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$P" -m 15 https://127.0.0.1/api/latest/port | python3 -c "import sys,json;[print(f\" {p['name']:<6} port={p['port']:<5} transports={','.join(p.get('transports',[]))}\") for p in json.load(sys.stdin)]"

AMQPS port=5671 transports=SSL HTTP port=8080 transports=TCP AMQP port=5672 transports=TCP

List the Exchanges

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-)
curl -sk -u "admin:$P" -m 15 https://127.0.0.1/api/latest/exchange/default | python3 -c "import sys,json;print('exchanges:',[e['name'] for e in json.load(sys.stdin)])"

exchanges: ['amq.match', 'amq.fanout', 'amq.topic', 'amq.direct']

These are the standard AMQP exchange types: headers, fanout, topic and direct. Bind your queues to the routing model that suits your application.

Prove an End-to-End AMQP Round Trip

The image ships a helper that declares a durable queue, publishes a message and consumes it back. It also asserts that a connection with a wrong credential is rejected. Run it at any time to confirm messaging health.

P=$(sudo grep -m1 '^QPID_ADMIN_PASSWORD=' /root/qpid-broker-j-credentials.txt | cut -d= -f2-) sudo /opt/qpid/bin/qpid-amqp-roundtrip.py admin "$P" 2>&1 | tail -2

AMQP_RT_OK sac-rt-9d8a9de2fe6245f0ac64b4be0fa66ebe

From your own applications, connect to <public-ip>:5672 for plaintext AMQP or <public-ip>:5671 for AMQPS. Authenticate with the same admin user and generated password. Anonymous connections and connections with a wrong credential are rejected.

Production Hardening Checklist

Work through this checklist before you expose the broker beyond a trusted network.

Replace the self-signed certificate. The per-instance certificate is fine for a first connection but not for production clients. Install your own certificate for nginx on :443 and a trusted keystore for the AMQPS listener on :5671.
Prefer AMQPS. Port 5672 is plaintext: SASL protects credentials, but message bodies are not encrypted. For anything that crosses an untrusted network, use 5671 and close 5672 in the security group.
Restrict the security group. Limit 22, 443, 5672 and 5671 to your application and administrator CIDRs rather than the whole internet.
Add per-application users. Instead of sharing the admin account, add users under authenticationproviders in the console and use access control to grant each only the queues it needs.
Back up the broker configuration and store. /var/lib/qpid holds the broker configuration, users and durable message state. Snapshot the volume or copy the directory on a schedule.
Keep it patched. Unattended upgrades are enabled for OS packages. Review the Apache Qpid release notes before you replace the broker under /opt/qpid.

Architecture

Component Path Notes

Broker qpid.service Runs bin/qpid-server as the unprivileged qpid user, JDK 17 headless

Install root /opt/qpid/current Symlink to the pinned apache-qpid-broker-j-10.0.1 distribution

Config template /opt/qpid/var/lib/sac/config/sac-initial-config.template.json Hardened template: single Plain provider, no guest, no anonymous

Rendered config /var/lib/qpid/etc/initial-config.json Written per instance at first boot; absent from the image

Broker work dir /var/lib/qpid Config store, users and durable message state

AMQP round trip /opt/qpid/bin/qpid-amqp-roundtrip.py Declare, publish, consume, plus a negative auth check

nginx vhost /etc/nginx/sites-available/sac-qpid TLS on :443, :80 redirect, unauthenticated /health

TLS cert /etc/nginx/tls/qpid.crt, qpid.key Regenerated per instance at first boot

Customer creds /root/qpid-broker-j-credentials.txt Mode 0600 root:root; URL, admin user, admin password

Firstboot script /usr/local/sbin/qpid-broker-j-firstboot.sh Renders the config, certificate and keystore

Firstboot sentinel /var/lib/sac/data/qpid-broker-j-firstboot.done Created when first boot completes

Support

SecureAnyCloud provides 24/7 support for this image. Open a ticket at https://secureanycloud.com/support/ with your instance ID and a brief description of the issue.

Common requests include replacing the self-signed certificate, queue and exchange design, connecting clients across AMQP versions, access control, and sizing for throughput.

Deploy on AWS

Launch Apache Qpid Broker-J with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS