BlazingMQ

Search the Marketplace for BlazingMQ on Ubuntu 24.04 and choose your VM size. Attach an NSG that allows TCP 22 (SSH) from your management network.

Do not open TCP 30114. The broker is deliberately bound to loopback. Reach it over an SSH tunnel, or from an application running on the same VM.

RG="blazingmq-prod"; LOCATION="eastus"; VM_NAME="blazingmq-01" IMAGE_URN="sac1647283583153:blazingmq-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name bmq-vnet --address-prefix 10.92.0.0/16 --subnet-name bmq-subnet --subnet-prefix 10.92.1.0/24 az network nsg create -g "$RG" --name bmq-nsg az network nsg rule create -g "$RG" --nsg-name bmq-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:blazingmq-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name bmq-vnet --subnet bmq-subnet --nsg bmq-nsg --public-ip-sku Standard

ssh azureuser@<vm-ip>

The broker runs as blazingmq.service and listens on TCP 30114. Confirm that the service is active and that the socket is bound to 127.0.0.1, not to every interface.

sudo systemctl is-active blazingmq ss -tln | grep 30114
# bmqtool prints its usage and exits 1 by convention, so tolerate that exit status here
sudo /usr/local/bin/bmqtool --help 2>&1 | head -3 || true

active LISTEN 0 4096 127.0.0.1:30114 0.0.0.0:* Usage: /usr/local/bin/bmqtool [--mode <mode>] [-b|broker <address>]

The service should show active, and the listening socket should be bound to 127.0.0.1:30114. A bind address of 0.0.0.0:30114 would make the broker reachable from the network. This image never ships that configuration.

First boot generated the username and password and stored them in a root-only file. Read the file and confirm its ownership and mode.

sudo cat /root/blazingmq-credentials.txt
sudo stat -c '%a %U:%G' /root/blazingmq-credentials.txt

The file holds BMQ_USER, BMQ_PASSWORD and BMQ_BROKER_URI, and is owned root:root with mode 600. These credentials exist only on this VM. No other deployment of this image shares them.

This step runs a full round trip. Publish a message to a queue with an authenticated producer, then consume it with an authenticated consumer and confirm that the payload matches. BlazingMQ addresses queues as bmq://<domain>/<queue-name>, and the image ships upstream's bmq.test.persistent.priority domain ready to use.

U=$(sudo grep '^BMQ_USER=' /root/blazingmq-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BMQ_PASSWORD=' /root/blazingmq-credentials.txt | cut -d= -f2-) QUEUE="bmq://bmq.test.persistent.priority/hello"
sudo /usr/local/bin/bmqtool --mode auto --broker tcp://localhost:30114 \
  --queueuri "$QUEUE" --queueflags write,ack \
  --eventscount 1 --eventsize 1 --messagepattern "hello-sac" \
  --shutdownGrace 3 --authnMechanism BASIC --authnData "$U:$P" 2>&1 | tail -5

The producer ends with a summary line that confirms the broker accepted one message:

Final stats: produced 1 messages [9 B] in 1 events [68 B] (Protocol: 86.76%)

Now consume the message. The --dumpmsg flag prints the payload, and --confirmmsg acknowledges it so that the broker can release it.

U=$(sudo grep '^BMQ_USER=' /root/blazingmq-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BMQ_PASSWORD=' /root/blazingmq-credentials.txt | cut -d= -f2-) QUEUE="bmq://bmq.test.persistent.priority/hello"
sudo /usr/local/bin/bmqtool --mode auto --broker tcp://localhost:30114 \
  --queueuri "$QUEUE" --queueflags read --dumpmsg --confirmmsg \
  --shutdownGrace 8 --authnMechanism BASIC --authnData "$U:$P" 2>&1 | tail -12

The consumer prints the message as a hex dump, with the decoded ASCII on the right:

PUSH #0: [ type = PUSH queue = [ uri = bmq://bmq.test.persistent.priority/hello ... ] ] 0: 68656C6C 6F2D636C 6F756469 6D673030 |hello-sac00| 16: 30303030 303030 |0000000 |

The hello-sac payload that the producer published appears, zero-padded to the message size. That completes a publish, queue and consume cycle through the broker. The --dumpmsg flag wraps the ASCII column every 16 bytes, so a longer payload appears across several rows.

Run the same producer with no credentials. The broker refuses the session, which keeps the queue closed to any client that cannot authenticate.

sudo timeout -k 5 20 /usr/local/bin/bmqtool --mode auto --broker tcp://localhost:30114 \
  --queueuri "bmq://bmq.test.persistent.priority/hello" --queueflags write,ack \
  --eventscount 1 --shutdownGrace 3 > /tmp/bmq-anon.log 2>&1 || true tail -6 /tmp/bmq-anon.log

The timeout -k 5 20 wrapper is required. A rejected client retries the connection indefinitely instead of exiting, and it does not stop on a plain TERM. Without -k (force kill), the command never returns.

Redirect the output to a file instead of piping it to tail, for the same reason. A client child process can keep the pipe open after the timeout fires, and tail then waits forever.

The client never opens the queue. The broker states the refusal explicitly in its own log, which is the authoritative proof that authentication is enforced:

sudo journalctl -u blazingmq --no-pager | grep -o "Anonymous credential is disallowed[^']*" | tail -2

Anonymous credential is disallowed, cannot negotiate without authentication. Anonymous credential is disallowed, cannot negotiate without authentication.

Together with the loopback bind, this means an attacker needs both host access and the per-VM credential.

The broker listens on loopback only, so connect to it through an SSH tunnel from your own machine. Run the following command on your workstation, not on the VM:

ssh -L 30114:127.0.0.1:30114 azureuser@<vm-ip>

With the tunnel open, any BlazingMQ client on your workstation can connect to tcp://localhost:30114 and authenticate with the per-VM credential, as if the broker were local. This keeps the broker off the public internet and still lets you use it from anywhere you can SSH.

An application on the same VM needs no tunnel. Connect it directly to tcp://localhost:30114.

A BlazingMQ domain defines the storage and delivery behavior for the queues inside it. The image ships upstream's seven test domains, which cover each delivery mode:

ls /etc/blazingmq/domains/

bmq.test.mem.broadcast.json bmq.test.persistent.fanout.sc.json bmq.test.mem.fanout.json bmq.test.persistent.priority.json bmq.test.mem.priority.json bmq.test.persistent.priority.sc.json bmq.test.persistent.fanout.json

• bmq.test.persistent.priority and bmq.test.mem.priority use priority mode. Each message goes to exactly one of the connected consumers, the classic work queue.
• bmq.test.persistent.fanout and bmq.test.mem.fanout use fanout mode. Every named application gets its own copy of every message.
• bmq.test.mem.broadcast uses broadcast mode. Messages go to all currently connected consumers and are not retained for absent ones.
• The .sc variants use strong consistency rather than eventual consistency.

Domains beginning bmq.test.persistent are file-backed, so their messages survive a broker restart. bmq.test.mem domains are memory-backed, and their messages are not retained across a restart.

To add your own domain, copy one of these files, rename it to your domain name, and adjust the limits. Then restart the broker with sudo systemctl restart blazingmq.