Openfire

Last reviewed Sep 13, 2026 · 974 words

Openfire is the XMPP server you pick when the person administering it would rather click through a web console than edit a Lua or Erlang config, and when your users already live in Active Directory. For a personal server or a handful of friends, ejabberd or Prosody will use a fraction of the memory and feel more current. For a company or school that wants a chat server tied to its existing directory, with an admin interface a junior sysadmin can operate on day one, Openfire has been the sensible answer since 2004 and still is.

What 20 years of releases bought you

The project is Apache-2.0, maintained by Ignite Realtime, and sits at 3,063 stars, which understates its install base because most deployments are inside organisations that never touch GitHub. The core does the things a chat server must: one-to-one messages, multi-user chat rooms, presence, rosters, server-to-server federation, and TLS on every listener. Setup is a browser wizard rather than a config file: you point it at a database, choose local users or LDAP, create an admin, and you are receiving connections within 10 minutes.

The plugin catalogue is the real product. Message archiving and search, an HTTP file-upload service so photo sharing works in modern clients, push notifications for mobile, a REST API for provisioning users from scripts, clustering, and audio and video meetings all install from inside the console with one click and no restart. Ignite Realtime also ships Spark, a desktop client built for Openfire, which matters in corporate deployments where you want one supported client rather than a menu.

The ports you need to open, and the one you must not

Client connections arrive on 5222 with STARTTLS, or 5223 for direct TLS. Federation with other XMPP servers uses 5269. Browser-based clients and some mobile apps use the HTTP binding on 7070 and 7443. The admin console listens on 9090 for plain HTTP and 9091 for HTTPS, and the mistake I see most is 9090 left reachable from the internet. Bind the console to localhost or a management network, or firewall it and reach it over Tailscale. It is an administrative surface with full control of every account and there is no good reason for it to be public.

Federation is optional. If your server only talks to itself, leave 5269 closed and you have removed the entire class of server-to-server abuse.

Java memory is the cost, and 512 MB is the floor not the target

The catalogue's 512 MB minimum is honest for an idle server with a dozen users and the default JVM settings. Add the monitoring plugin with archiving, a few hundred concurrent users, and the meetings plugin, and you want 2 GB set aside so the garbage collector is not the thing deciding your latency. Set the heap explicitly rather than trusting the default; in the Docker image that means passing JAVA_OPTS with -Xmx sized to the box. This is the trade you make for the console and the plugins. Prosody runs the same dozen users in under 100 MB, and if that number offends you the decision is already made.

The other honest con is the interface. The admin console works and is fast, but it looks like 2010, and the Spark client is functional rather than lovely. Users bringing their own client on Android will want Conversations, which behaves well against Openfire provided you have installed the file-upload and push plugins and enabled message archiving. Without those three, they will report that images do not send and notifications are late, and they will be right.

Database choice decides how easy upgrades are

The wizard offers an embedded database, and it is fine for evaluation and for tiny deployments, but the moment you care about backups use PostgreSQL or MySQL. The embedded store lives inside the Openfire data directory, is awkward to back up while the server is running, and makes migrating to a bigger box a chore. With an external database, a backup is a standard dump plus the conf directory, and an upgrade is stopping the container, pulling the new image, and starting it; schema updates apply themselves on boot.

LDAP integration is the feature that keeps organisations on Openfire, and it is genuinely good: users authenticate against AD or OpenLDAP, groups map to shared roster groups so everyone sees their department automatically, and disabling an account in the directory disables chat. Read-only is the default, and you should keep it that way.

Where it sits against ejabberd and Prosody

The Matrix and XMPP category lists all three, and the split is not about protocol support, which is close to equal today. ejabberd scales further on the same hardware and is the better choice for anything approaching a public service. Prosody is smaller, simpler, and the preferred home for one person who enjoys a config file. Openfire wins on administration by non-specialists, on directory integration, and on the one-click plugin story. It is the bigger-project-is-safer case in reverse: Openfire is the smaller GitHub number, but for the corporate use case it is the more conservative pick.

What I'd do

For an organisation with a directory, I would run the official Docker image with PostgreSQL alongside, the heap pinned at 1 GB, the admin console reachable only over the management VPN, and the file-upload, push, and monitoring plugins installed before the first user logs in. Federation off unless there is a stated need. For myself, at home, I would not run it: Prosody does the job in a tenth of the memory and I do not need a console. Choose Openfire for the people who will administer it, not for the protocol.