Openfire XMPP Server on AWS 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. Launch the cloudimg AMI 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 ports 5222 and 5223, and federation uses port 5269. The admin console is bound to the loopback connector 127.0.0.1:9090 and is never exposed directly; instead nginx fronts it on ports 80 and 443, with a self signed TLS certificate regenerated uniquely on each instance's first boot. The embedded database that holds your users, rooms and rosters lives on a dedicated data volume. The first run setup wizard is pre-completed on the first boot of every instance, which also generates a unique admin password, so a fresh instance 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 data volume at /var/lib/openfire
• The admin console bound to 127.0.0.1:9090 and never exposed directly, fronted by nginx on ports 80 and 443 over TLS
• Port 80 serving an unauthenticated /healthz endpoint for load balancer probes
• XMPP client to server on ports 5222 (STARTTLS) and 5223 (direct TLS), 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

Connecting to your instance

Connect over SSH on port 22 as the default login user for the operating system variant you launched:

ssh <login-user>@<instance-public-ip>

Prerequisites

An AWS account and an EC2 key pair in the target region. m5.large (2 vCPU / 8 GiB RAM) is the recommended starting point; size up for more concurrent users and rooms. The instance security group should allow 22/tcp from your management network, 80/tcp and 443/tcp for the admin console, 5222/tcp and 5223/tcp for XMPP clients, and 5269/tcp for server to server federation. The admin console is fronted with a per-instance self signed certificate, so browsers show a certificate warning until you install a trusted certificate (see Maintenance).

Step 1 - Launch from AWS Marketplace

Find the Openfire listing by cloudimg in AWS Marketplace, choose Continue to Subscribe, accept the terms, then Continue to Configuration and Continue to Launch. Pick the m5.large instance type, your key pair, and a security group that opens ports 22, 80, 443, 5222, 5223 and 5269, then launch. You can also launch the AMI directly from the EC2 console.

Step 2 - Launch from the AWS CLI

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-group-ids <security-group-id> \
  --subnet-id <subnet-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=openfire}]'

Ensure the referenced security group opens ports 22, 80, 443, 5222, 5223 and 5269.

Step 3 - Confirm the services are running

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

Both services report active. Openfire listens on ports 5222 and 5223 for XMPP clients and 5269 for federation, while the admin console listens only on the loopback address 127.0.0.1:9090 (and 9091 for its own secure port) and is fronted by nginx on ports 80 and 443.

Step 4 - Retrieve your admin password

The Openfire admin password is generated uniquely on the first boot of your instance 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 data volume mounted at /var/lib/openfire.

Step 5 - Confirm the health endpoints

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

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

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

Step 6 - 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-instance 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 4 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-instance password prints HTTP 302 (signed in, redirected to the dashboard); a wrong password prints HTTP 200 (rejected, the login page is shown again).

Step 7 - Sign in to the admin console

Browse to https://<instance-public-ip>/. Because the admin console is fronted with a per-instance self signed certificate, your browser shows a certificate warning the first time; accept it (or install a trusted certificate as described in Maintenance). 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 4, then select Login.

Step 8 - 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 (including the loopback only admin console). From the tabs across the top you manage everything: users and groups, sessions, group chat, server settings and plugins.

Step 9 - 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 10 - 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 11 - 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 instance's public IP address and use port 5222 (STARTTLS) or 5223 (direct TLS). 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 12 - Confirm data lives on the dedicated volume

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 data volume, so it survives OS changes and can be resized independently:

findmnt /var/lib/openfire

The mount is backed by a separate EBS data volume captured into the image and re-provisioned on every instance.

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 admin console is fronted by nginx on port 443 with a per-instance self signed certificate at /etc/nginx/ssl/, and Openfire generates a self signed certificate for client STARTTLS. For production, point a DNS name at the instance, obtain a trusted certificate (for example with certbot / Let's Encrypt), replace the nginx certificate, and import a certificate for XMPP clients under Server -> TLS/SSL Certificates in the admin console.
• 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 volume.
• Federation: server to server is enabled on port 5269; open the port in your security group 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 volume; back up that volume with EBS snapshots 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.