Openfire XMPP Server on Ubuntu 24.04 on Azure User Guide

Overview

Openfire is a mature, open source XMPP and Jabber server for real time collaboration: one to one chat, presence, group chat rooms (MUC), publish and subscribe, and server to server federation. Install the cloudimg image and you have your own private chat server that any standard XMPP client can connect to, managed through a polished web admin console. The image installs Openfire 5.1.1 from the official Ignite Realtime package (which bundles its own Java runtime) and runs it as the dedicated openfire system service. Client connections use port 5222 (c2s) and federation uses port 5269 (s2s). The admin console is bound to the loopback connector 127.0.0.1:9090, and nginx on port 80 reverse proxies to it plus an unauthenticated health endpoint. The embedded database that holds your users, rooms and rosters lives on a dedicated Azure data disk. The first run setup wizard is pre-completed on the first boot of every VM, which also generates a unique admin password, so a fresh VM lands straight on the ready admin console login page rather than the wizard. Backed by 24/7 cloudimg support.

What is included:

• Openfire 5.1.1 installed from the official Ignite Realtime package and run as the openfire system service
• The built in embedded database (no external database required) on a dedicated Azure data disk at /var/lib/openfire
• The admin console bound to 127.0.0.1:9090, fronted by nginx on port 80
• Port 80 serving an unauthenticated /healthz endpoint for load balancer probes
• XMPP client to server on port 5222 (STARTTLS) and server to server federation on port 5269
• The setup wizard pre-completed on first boot, with a unique admin account whose password is recorded in a root only file
• openfire.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 reasonable starting point; size up for more concurrent users and rooms. NSG inbound: allow 22/tcp from your management network, 80/tcp (and 443/tcp if you add TLS) for the admin console, 5222/tcp for XMPP clients, and 5269/tcp for server to server federation. The admin console is served over plain HTTP by default, so for production put your own domain and a trusted certificate in front of it (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Openfire 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 HTTP (80). After creation, add inbound rules for 5222 (XMPP clients) and 5269 (federation). Review the dedicated data disk on the Disks tab, then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name openfire \
  --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 openfire --port 80   --priority 1010
az vm open-port --resource-group <your-rg> --name openfire --port 5222 --priority 1020
az vm open-port --resource-group <your-rg> --name openfire --port 5269 --priority 1030

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active openfire.service nginx.service
ss -tlnp | grep -E '5222|5269|9090'

Both services report active. Openfire listens on port 5222 for XMPP clients and 5269 for federation, while the admin console listens only on the loopback address 127.0.0.1:9090 and is fronted by nginx on port 80.

Step 5 - Retrieve your admin password

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

sudo cat /root/openfire-credentials.txt

This file contains OPENFIRE_USERNAME (admin), OPENFIRE_PASSWORD and the admin console URL. Store the password somewhere safe. The file is mode 0600 and owned by root, so only an administrator can read it. The embedded database that holds your users and rooms lives on the dedicated Azure data disk mounted at /var/lib/openfire.

Step 6 - Confirm the health endpoints

nginx serves an unauthenticated health endpoint for load balancers and probes, and fronts the admin console login page:

curl -s http://localhost/healthz
curl -s -o /dev/null -w 'healthz HTTP %{http_code}\n' http://localhost/healthz
curl -s -o /dev/null -w 'login   HTTP %{http_code}\n' http://localhost/login.jsp

/healthz returns ok with HTTP 200 and never requires authentication, so it is safe for an Azure Load Balancer health probe. The admin console login page at /login.jsp returns HTTP 200, which confirms the setup wizard was pre-completed and the server is ready to sign in to.

Step 7 - Verify authentication from the command line

The admin console uses a CSRF protected login form. The check below fetches the login page to obtain the CSRF cookie, then signs in with the correct per-VM password (a successful sign in returns an HTTP 302 redirect to the dashboard) and, for contrast, with a wrong password (rejected, the login page is re-rendered as HTTP 200). Because the command embeds your unique password, run it interactively rather than from a script; substitute the value of OPENFIRE_PASSWORD from Step 5 for <OPENFIRE_PASSWORD>:

login() {
  J=$(mktemp); curl -s -c "$J" -o /dev/null http://localhost/login.jsp
  C=$(awk '$6=="csrf"{print $7}' "$J")
  curl -s -b "$J" -o /dev/null -w "%{http_code}\n" \
    --data-urlencode "username=admin" --data-urlencode "password=$1" \
    --data-urlencode "csrf=$C" --data-urlencode "login=true" \
    --data-urlencode "url=/index.jsp" http://localhost/login.jsp
  rm -f "$J"
}
echo "correct password -> HTTP $(login '<OPENFIRE_PASSWORD>')"
echo "wrong password   -> HTTP $(login 'wrong')"

The correct per-VM password prints HTTP 302 (signed in, redirected to the dashboard); a wrong password prints HTTP 200 (rejected, the login page is shown again).

Step 8 - Sign in to the admin console

Browse to http://<vm-public-ip>/. Because the setup wizard was pre-completed on first boot, you land directly on the Openfire admin console login page (never the setup wizard). Enter admin as the username and the password from Step 5, then select Login.

Step 9 - Explore the server dashboard

After signing in you land on Server Information, the admin console dashboard. It shows the server version, the XMPP domain, uptime, the Java runtime and the listening ports. From the tabs across the top you manage everything: users and groups, sessions, group chat, server settings and plugins.

Step 10 - Manage users and groups

Open the Users/Groups tab to list existing accounts and create new ones. Select Create New User, enter a username and password to create a JID such as alice@localhost; that user can then sign in from any XMPP client. Groups let you build shared rosters so members automatically see one another.

Step 11 - Sessions and group chat

The Sessions tab lists the currently connected clients so you can see who is online in real time, and the Group Chat tab manages your Multi User Chat service and rooms. Create persistent rooms, set their access and moderation, and monitor the active conversations on your server.

Step 12 - Connect an XMPP client

Point any XMPP client (for example Gajim, Conversations, Dino, Spark or Pidgin) at your server. Sign in with a JID you created, such as alice@localhost, and the password you set. Set the connection server or host to the VM's public IP address and use port 5222; the appliance offers STARTTLS on client connections. To chat between servers, Openfire federates over port 5269 (server to server). Create group chat rooms from a client that supports Multi User Chat, or manage them from the admin console.

Step 13 - Confirm data lives on the dedicated disk

Openfire's data, the embedded database that holds your registered users, rooms, rosters and offline messages, is stored under /var/lib/openfire on the dedicated Azure data disk, so it survives OS changes and can be resized independently:

findmnt /var/lib/openfire

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM.

Maintenance

• Password: the admin password is set on first boot. To change it, sign in to the admin console and open Users/Groups -> admin -> Edit Properties, or reset it there.
• Serve a real domain: the default served XMPP domain is localhost. For production, sign in to the admin console, open Server -> Server Manager -> System Properties (or Server Settings), set your public domain, and configure DNS SRV records (_xmpp-client._tcp and _xmpp-server._tcp) for clients and federation.
• TLS and certificates: the appliance serves the admin console over plain HTTP on port 80 and Openfire generates a self signed certificate for client STARTTLS. For production, point a DNS name at the VM, obtain a trusted certificate (for example with certbot / Let's Encrypt), import it under Server -> TLS/SSL Certificates in the admin console, and front the console with nginx TLS on port 443.
• Chat rooms (MUC): Multi User Chat is enabled; create and administer rooms from the Group Chat tab or an XMPP client. Rooms and their archives are stored in the embedded database on the data disk.
• Federation: server to server is enabled on port 5269; open the port in your NSG to chat with users on other XMPP servers.
• Plugins: Openfire has a rich plugin ecosystem (REST API, monitoring, push, and more). Install and manage plugins from the Plugins tab in the admin console.
• Storage: all Openfire state lives under /var/lib/openfire on the data disk; back up that volume to protect your users, rooms and history.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.