# Openfire: an XMPP server you run yourself, built in Java

> Openfire is an Apache-2.0 XMPP (Jabber) server maintained by the Ignite Realtime community. It suits teams that want their own messaging server instead of a hosted service, and it asks for a JVM and Maven build in return.

**igniterealtime/Openfire** — An XMPP server licensed under the Open Source Apache License.

- Repository: https://github.com/igniterealtime/Openfire
- Website: https://igniterealtime.org/projects/openfire/
- Stars: 3,067 · Forks: 1,403
- Language: Java
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/igniterealtime-openfire

## What Openfire is, and who ends up running it

Openfire is a real time collaboration server that speaks XMPP, the protocol also known as Jabber. The README describes it as using "the only widely adopted open protocol for instant messaging" and states it is licensed under the Apache License. That combination defines the audience: organisations that want their own messaging server, on their own hardware, with clients they choose, rather than a hosted chat product where the server is somebody else's problem.

The practical consequence is that Openfire is infrastructure. Someone has to install a Java runtime, decide where the server stores its data, open the right ports, and keep it upgraded. The project does not hide this. It ships installers for different platforms under the build directory, a Dockerfile at the repository root, and a Debian packaging target in the Makefile, which tells you the maintainers expect the server to be deployed by people who are comfortable with those tools. If your team has nobody in that role, the server will sit unpatched.

The protocol choice matters more than it first appears. Because Openfire speaks XMPP rather than a proprietary API, any compliant client can connect, and the server is not the only place your messages can live. That is the reason to pick it. It is also the reason some teams should not: XMPP's extension model means features arrive as plugins and protocol extensions, and the README does not enumerate which ones are bundled.

## How the Java codebase is laid out and built

The repository is a Maven multi-module project. The README states that the core server lives in the xmppserver module, with supporting directories: build for installer files, distribution to assemble the parts, documentation for the hosted docs, i18n for admin interface translations, plugins for plugin build configuration, and starter for the small module that starts Openfire consistently across platforms.

That layout explains the shape of a build. The starter module exists because launching a Java server consistently on Windows, Linux and macOS is fiddly; the distribution module exists because the core server alone is not a runnable product. Translations live in their own tree and are managed through Transifex according to the README's resources list, so localisation work does not require touching server code.

The README gives two build commands. The full build with plugins is ./mvnw verify. For core server work, ./mvnw verify -pl distribution -am compiles the core and its dependencies and assembles something runnable. The Makefile wraps the same Maven wrapper: make build-openfire runs ./mvnw package --batch-mode --no-transfer-progress, make test runs the test phase, and make deb calls build/debian/build_debs.sh after a distribution build. Note that the Makefile cannot use "build" as a target name because a directory already has that name, a small detail that tells you how long this layout has been in place.

## Installing Openfire and starting it for the first time

The README points to the project's documentation page and download page rather than reproducing install steps, so treat the commands below as the build-and-run path the repository itself documents.

First, build the core server and assemble a runnable distribution. This is the command the README recommends when you only need the core XMPP server:

```bash
./mvnw verify -pl distribution -am
```

After that completes, the README says to start Openfire from the command line with the shell script or batch file. On Linux and macOS the script is at this path:

```bash
./distribution/target/distribution-base/bin/openfire.sh
```

On Windows the equivalent batch file is:

```bash
.\distribution\target\distribution-base\bin\openfire.bat
```

The README notes that adding -debug as the first parameter to the script starts the server in debug mode, which lets an IDE attach a remote debugger. If you prefer IntelliJ IDEA, the README gives a run configuration: main class org.jivesoftware.openfire.starter.ServerStarter, classpath of the starter module, and VM options including -DopenfireHome pointing at distribution/target/distribution-base and -Dopenfire.lib.dir pointing at its lib folder. The README states that mvnw verify must run before you can launch Openfire from the IDE, and that other IDEs cannot run the server directly; they must start it from the command line.

For container users, the repository has a Dockerfile. It is a multi-stage build: a stage that keeps only pom.xml files and checked-in jars so dependency downloads stay cached, a build stage using eclipse-temurin:17 that copies the Maven wrapper and runs dependency resolution offline, and then the actual build. The Dockerfile comments admit the awkward parts, including that BOM POMs referenced with scope import are not reliably resolved and are fetched explicitly. If you build this image, expect the first build to be slow and network-dependent.

## Where Openfire is the wrong tool

The README does not document rollback, and that silence is worth taking seriously. There is no described downgrade path, no snapshot procedure, and no migration guide in the README. Upgrading a server that holds your organisation's message history is a different risk class from upgrading a stateless web app, and the README does not address it. Anyone deploying Openfire should plan their own backup and restore procedure rather than assuming the project provides one.

Bug reporting is another friction point. The README states that only a few users have access to the bug tracker, and that new users should create a Discourse account, log in, click New Topic, and post in the Openfire Dev category with a detailed description. That is a deliberate gate, and it means a bug you find may take a while to be triaged by someone with tracker access. For a large enterprise with a support contract elsewhere, that is fine. For a small team expecting a ticket queue, it is not.

The build requirements are the third boundary. Openfire is Java and Maven, and the Dockerfile uses eclipse-temurin:17. If your environment is standardised on a different runtime, or if you have no appetite for a Maven build chain, the cost of entry is real. And if you only need one-to-one chat between two people, a full XMPP server with plugins, an admin console and a database is more machinery than the problem deserves.

## Alternatives and how their approach differs

The most direct comparison in the README is with Openfire's own companion client, Spark, which appears repeatedly in what people search for alongside this project. That is not really an alternative server; it is the client side of the same Ignite Realtime stack. If you are evaluating Openfire, you are likely also deciding which XMPP clients your users will run, and Spark is one option the community maintains.

The wider alternative is a hosted messaging service. The difference in approach is not a feature list; it is who operates the server. With a hosted service, the vendor runs the infrastructure, handles upgrades, and usually owns the data model. With Openfire, you run the JVM, you choose the database, you manage the certificates, and you own the upgrade window. The README's framing supports this: it describes Ignite Realtime as an open source community "aimed at disrupting proprietary, non-open standards-based systems". That is a statement about governance and protocol ownership, not about convenience.

A second alternative is another XMPP server implementation. The README does not name one, so the honest comparison is about ecosystem rather than code: Openfire's distinguishing traits in this repository are its plugin build configuration, its Transifex-managed translations, its multi-platform installer scripts, and its Maven module split. If another server offers a lighter deployment story, that is the axis to compare on, because Openfire's weight is the price of its breadth.

## Maintenance, releases and what the licence means for you

The repository is not archived, and the last push was on 2026-09-19, five days before the date used here for judging recency. Recent releases are v5.1.0 on 2026-06-03, v5.1.1 on 2026-07-07, and v5.1.2 on 2026-08-17. That cadence, roughly a minor release every month or two through mid-2026, is the practical upgrade cost: you are not installing once and forgetting it.

The upgrade path itself is the weak point. Because the README does not document rollback or a data migration procedure, the cost of each upgrade includes whatever backup and verification work your team invents. That is a recurring cost, not a one-off, and it scales with how much history your server holds.

The licence is Apache-2.0, stated in the README and in the LICENSE.txt file at the repository root. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes an explicit patent grant. This is not legal advice, and the obligations that matter to you depend on how you distribute or modify the software; if you plan to ship a modified Openfire inside a product, have your own counsel read the licence text rather than a summary. For internal deployment, the licence is unlikely to be the obstacle; the operational burden is.

## Conclusion

Adopt Openfire if you want an XMPP server you control, are comfortable with Java and Maven, and can accept that the README points you to external documentation and a Discourse forum rather than a single setup guide. Do not adopt it if you need a hosted service with no server to operate, or if your team has no one who can run a JVM, a database and TLS certificates. Before committing, verify three things: that a current release (v5.1.2 is dated 2026-08-17) matches your Java runtime, that the plugins you need are still listed on the project's plugins page, and that the bug-reporting route through the Openfire Dev Discourse category is acceptable to your team.

## FAQ

### What is Openfire used for?

Openfire is a real time collaboration server that speaks XMPP, also called Jabber. Organisations use it to run their own instant messaging infrastructure instead of relying on a hosted service.

### Is Openfire open source?

Yes. The README states that Openfire is licensed under the Open Source Apache License, and the repository carries a LICENSE.txt file. It is an Ignite Realtime community project.

### How do I install Openfire?

The README points to the project's documentation and download pages rather than listing install steps. For a source build it gives ./mvnw verify -pl distribution -am, after which you start the server with the script at distribution/target/distribution-base/bin/openfire.sh.

### What is the Openfire server?

It is an XMPP server written in Java, split into Maven modules with the core code in the xmppserver module. The README describes it as offering easy setup and administration alongside security and performance.

### What is Openfire software?

It is an XMPP server licensed under the Apache License, maintained as an Ignite Realtime community project. The README describes it as a real time collaboration server using the XMPP protocol, also called Jabber.

### How do I set up Openfire?

The README directs you to the project's documentation page for setup guidance. From source, you build with ./mvnw verify -pl distribution -am and then run the script at distribution/target/distribution-base/bin/openfire.sh.

## Sources

- [igniterealtime/Openfire on GitHub](https://github.com/igniterealtime/Openfire)
- [License: Apache-2.0](https://github.com/igniterealtime/Openfire/blob/main/LICENSE)
- [Project website](https://igniterealtime.org/projects/openfire/)
- [README](https://github.com/igniterealtime/Openfire/blob/main/README.md)
- [Releases](https://github.com/igniterealtime/Openfire/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/igniterealtime-openfire