ejabberd

Open-source messaging infrastructure, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source XMPP server, MQTT broker, and SIP gateway built in Erlang/OTP — the protocol-level messaging infrastructure that WhatsApp used to run at scale before building their own stack [website].
• Who it’s for: Engineering teams and technically capable operators who need a federatable, standards-compliant real-time messaging backbone — not non-technical founders looking for a Slack replacement [2].
• Cost savings: ejabberd Community Edition is free software (GPLv2). You need a VPS and operational time. The commercial ejabberd Business Edition from ProcessOne has undisclosed pricing — you contact sales [README].
• Key strength: Proven at absurd scale. ProcessOne claims 2,000,000 concurrent users on a single node, and ejabberd’s Erlang architecture is the reason this isn’t marketing fiction — Erlang was built specifically for telecom-grade concurrency [website].
• Key weakness: Configuration complexity and a steep learning curve that will stop a non-technical founder cold. This is not a tool you install with a wizard and manage from a nice dashboard [2].

---

What is ejabberd

ejabberd is a real-time messaging server that speaks three protocols: XMPP (the open federated messaging standard also called Jabber), MQTT (the lightweight pub/sub protocol beloved by IoT devices), and SIP (the protocol underlying most VoIP systems). It is built in Erlang/OTP, the language designed by Ericsson in the 1980s for telephone switches that needed to run for years without restarting.

The project is maintained by ProcessOne, a Paris-based company that has been shipping ejabberd releases since 2002. As of this review it sits at 6,615 GitHub stars — modest compared to newer messaging projects, but the number undersells how entrenched ejabberd is. It predates GitHub. The codebase has over two decades of battle testing in production systems ranging from mobile messaging apps to gaming backends to IoT platforms [website][README].

What ejabberd is not: it is not a chat application. There is no end-user interface. You are building the messaging layer that chat clients connect to. The XMPP ecosystem has clients — Conversations on Android, Monal on iOS, Gajim on desktop — but ejabberd is the server those clients talk to, much like how you’d self-host a mail server that Thunderbird connects to.

The modern ejabberd is more interesting than the name suggests. The 24.02 release added Matrix federation [4] — meaning an ejabberd server can bridge XMPP and Matrix networks, letting users on different protocols communicate. The 25.03 release extended that to Matrix room support, so you can join public Matrix rooms from an XMPP client [3]. This is technically ambitious work that positions ejabberd not just as an XMPP purist’s server but as a cross-protocol bridge.

---

Why people choose it over alternatives

The case for ejabberd breaks into three arguments, and you need to understand which one applies to your situation before making any decision.

The scale argument. This is ejabberd’s strongest hand. ProcessOne publishes the “2,000,000 users on 1 node” number prominently [website], and it’s credible because Erlang’s BEAM virtual machine was designed for exactly this problem — massive concurrency with fault isolation, where a crash in one process doesn’t take down the system. Ejabberd runs in a cluster out of the box, uses consistent hashing to avoid data replication bottlenecks, and can be upgraded while running [website]. For teams building mobile messaging or gaming backends that need horizontal scale without a complete rewrite, this is a serious differentiator.

The standards compliance argument. XMPP has a large body of published protocol extensions (XEPs). ejabberd’s compliance rate is high — ProcessOne publishes a supported XEP list, and the 24.02 and 25.03 releases added TLS 1.3, SASL2, Bind 2 for faster mobile connections, message retraction (XEP-0424), and SCRAM downgrade protection [3][4]. If you are building an application that needs to federate with other XMPP servers — or interoperate with standard XMPP clients — ejabberd covers more of the specification than most alternatives [2].

The federation / bridge argument. The Matrix gateway (mod_matrix_gw) is the most strategically interesting recent addition. As of ejabberd 25.03, you can receive invitations to and join public Matrix rooms from an ejabberd instance [3]. This matters if you have users on different networks and want a single server to bridge them. The caveat ProcessOne is careful to document: Matrix end-to-end encryption cannot be preserved through the bridge — the decryption has to happen at the server level [3]. That’s an honest limitation worth understanding before you base a privacy pitch on it.

When reviewers compare ejabberd to Matrix/Synapse [2], the summary is consistent: ejabberd wins on raw performance and XMPP standards depth, Matrix wins on decentralized architecture, modern client ecosystem, and end-to-end encryption story. The comparison site appmus.com [2] flags ejabberd’s weaknesses plainly: configuration complexity, steep learning curve for anyone unfamiliar with Erlang/XMPP, web admin interface that lags behind command-line options, and the need to integrate external media servers for voice/video. These are not fringe issues — they are the regular friction points for anyone running ejabberd.

---

Features

From the README, website, and release notes — what ejabberd actually ships:

Protocol support:

• XMPP server with federation (connect to other XMPP servers) [README]
• MQTT broker (built-in, same process — relevant for IoT) [website]
• SIP service (voice/telephony) [website]
• Matrix gateway via mod_matrix_gw (one-to-one + room support as of 25.03) [3]
• WebSocket and BOSH support for browser clients [website]

Security and authentication:

• TLS 1.3 support [4]
• SASL2 and SASL SCRAM with downgrade protection [3][4]
• Bind 2 for faster mobile reconnections [4]
• Multiple simultaneous password storage formats (plain, scram_sha1/256/512) for gradual migration [3]
• SSL/TLS encryption throughout [website]

Clustering and reliability:

• Active-active clustering with consistent hashing [website]
• Hot upgrades — upgrade the running server without downtime [website]
• Stream management (XEP-0198) with delivery acknowledgment from mobile clients [website]
• PubSub with broadcast optimization [website]

Management:

• ejabberdctl command-line tool for most administrative operations [website][README]
• REST API for backend integration [website]
• Web admin interface (noted to sometimes lag behind CLI features [2])
• Unix domain socket support, including relative paths (25.03) [3]
• SQL schema auto-update via update_sql_schema option [3][4]

Extensibility:

• Modular plugin architecture [website]
• Third-party module ecosystem [README]
• Full API for custom plugins [website]
• Weblate-based translation system [README]

What’s missing or requires external work:

• Voice and video calls require a separate media server integration — ejabberd doesn’t ship one [2]
• End-to-end encryption in Matrix bridge is not preserved [3]
• No built-in end-user chat client — XMPP clients connect separately

---

Pricing: SaaS vs self-hosted math

This section requires honesty: ejabberd does not publish a pricing page for its commercial offerings, so precise SaaS cost comparisons are not available from the sources reviewed.

ejabberd Community Edition:

• License: GPLv2 — free to self-host [website]
• What you need: a Linux server (Erlang is efficient — a $6–10/mo VPS can handle moderate loads; high-concurrency production deployments need proportionally more RAM and CPU)
• Available via Docker, Homebrew, OS packages, source, or installer [README]

ejabberd Business Edition (ProcessOne commercial product):

• Pricing: contact sales — not publicly listed [README]
• Includes additional features, professional support, and presumably SLA guarantees
• Also offered as managed cloud via Fluux [README]

Managed hosting (third-party):

• GigaPros advertises ejabberd hosting starting at $20/month as a managed VPS product [1] — this is a third-party hosting company, not ProcessOne’s official managed service, and the review reflects one vendor’s pricing rather than a market benchmark

What you’re comparing against: If you’re evaluating ejabberd as a replacement for a proprietary chat or messaging SaaS, the relevant comparison depends heavily on your scale. At small team scale (under 100 users), a hosted Slack alternative like Mattermost or Rocket.Chat has more comparable economics and vastly simpler administration. At mobile-app-backend scale (tens of thousands to millions of concurrent connections), the comparison is against building your own WebSocket infrastructure or paying for a messaging platform like Twilio or PubNub — where ejabberd’s operational cost can be dramatically lower.

The core self-hosting math: software is free, compute is what you pay for, and operational expertise is the real cost.

---

Deployment reality check

ejabberd’s README documents multiple install paths: source compilation, platform installers (deb/rpm for x64 and arm64), Docker containers (two variants: ecs for simpler setups and ejabberd for more control), OS packages, and Homebrew [README]. The breadth of options is itself a signal that the project has matured — you’re not limited to one opinionated deployment path.

What you actually need:

• A Linux server with Docker or a direct Erlang runtime
• A domain name with DNS configured for XMPP SRV records (required for federation)
• A PostgreSQL or MySQL database for persistence (or Mnesia, ejabberd’s built-in distributed database, for smaller setups)
• A reverse proxy for HTTPS and WebSocket termination
• SMTP if you want registration emails
• An understanding of YAML configuration files — ejabberd’s ejabberd.yml is extensive

What can go sideways:

• The SQL schema changes across versions and requires manual migration unless you enable update_sql_schema: true in config [3][4]. If you upgrade without reading the release notes, you will hit schema errors.
• The Matrix gateway (mod_matrix_gw) requires additional DNS and firewall configuration. The 25.03 release notes explicitly document an iptables rule needed to prevent connection conflicts with the real matrix.org server [3] — the kind of operational footgun that will confuse anyone who doesn’t read carefully.
• The web admin interface has historically lagged behind the ejabberdctl CLI in capabilities [2]. If you prefer clicking through a browser UI to manage your server, ejabberd will frustrate you.
• Voice and video are out of scope — you’ll need a STUN/TURN server and potentially a media relay to handle calls through your XMPP clients [2].
• Erlang release management is its own discipline. Upgrading OTP versions can require testing against your configuration; the README documents supported Erlang/OTP and Elixir version combinations [3].

Realistic time estimate: a technical user who knows Docker and DNS can get ejabberd running in an hour. Getting federation working with correct SRV records and TLS certificates takes another 2–4 hours. Getting clustering, MQTT, and Matrix gateway configured for production takes days of reading documentation. For a non-technical founder, this is not a self-service tool.

---

Pros and cons

Pros

• Proven at scale. Two decades of production use at companies building mobile messaging backends. The Erlang architecture is the real thing — not marketing [website].
• Multi-protocol in one server. XMPP, MQTT, and SIP from a single process is unusual. If your use case spans chat, IoT telemetry, and VoIP, this matters [website].
• GPLv2 open source core. The community edition is genuinely free software. You can inspect every line, fork it, and run it indefinitely without a license negotiation [website].
• Active development. The 24.02 and 25.03 releases show substantial new feature work — Matrix federation, TLS 1.3, SASL2 improvements [3][4]. This is not a maintenance-mode project.
• Federation. XMPP federation is built-in. Your server can communicate with any other XMPP server in the world without a central authority [website][2]. Matrix bridge extends this to the Matrix network [3].
• Standards compliance. High XEP coverage means clients and servers from third parties interoperate correctly [2].
• Efficient under load. Erlang’s per-process memory model and consistent hashing cluster design mean ejabberd doesn’t bloat proportionally with connection count [website].

Cons

• Configuration complexity is a serious barrier. The ejabberd.yml configuration file is large, the option space is wide, and mistakes are non-obvious [2]. This is not a point-and-click setup.
• Steep learning curve. Erlang/OTP concepts bleed through the administration surface. If you’ve never managed an Erlang system, the troubleshooting model is unfamiliar [2].
• Web admin UI lags CLI. The browser-based admin interface is less capable than ejabberdctl [2]. Expect to live in the terminal.
• No voice/video built in. You must integrate external media server components for calls [2].
• Matrix bridge caveats. Room support as of 25.03 is incomplete — older Matrix room protocol versions aren’t supported yet, persistence doesn’t survive server restart, and end-to-end encryption is not preserved [3].
• Commercial pricing is opaque. If you need Business Edition features or managed hosting from ProcessOne, you have no public pricing to evaluate without contacting sales [README].
• Not a user-facing product. There’s no included chat client, no admin dashboard with usage graphs, no onboarding flow. You’re building infrastructure, not installing an app.

---

Who should use this / who shouldn’t

Use ejabberd if:

• You’re an engineering team building a mobile messaging app, gaming chat system, or IoT backend that needs to handle massive concurrency.
• You need standards-compliant XMPP federation so your users can communicate with people on other servers.
• You want a single server that speaks XMPP, MQTT, and SIP without running three separate processes.
• You’re comfortable with Erlang systems, Linux administration, and reading protocol documentation.
• You need to bridge XMPP and Matrix networks.

Skip it (consider Matrix/Synapse instead) if:

• You prioritize a modern decentralized architecture with end-to-end encryption preserved across federation.
• You want a richer ecosystem of actively maintained clients and integration tooling.
• Your users care more about the E2E encryption story than raw server performance.

Skip it (consider Rocket.Chat or Mattermost instead) if:

• You’re a team looking for a self-hosted Slack replacement with a web UI and file sharing.
• Your users are non-technical and need an app they can open without configuring an XMPP client.
• You don’t have engineering resources to operate messaging infrastructure.

Skip it (consider Prosody instead) if:

• You want a simpler, lighter XMPP server written in Lua that’s easier to configure and extend for smaller deployments.
• You don’t need MQTT or SIP and find ejabberd’s multi-protocol scope excessive.

---

Alternatives worth considering

• Matrix/Synapse — decentralized protocol with end-to-end encryption, growing client ecosystem, heavier on resources than ejabberd [2]. The two projects are increasingly interoperable via ejabberd’s Matrix gateway [3].
• Prosody — lighter-weight XMPP server, written in Lua, easier to configure, better for small deployments, less capable at scale.
• Openfire — Java-based XMPP server with a web admin console. Better UI experience than ejabberd, worse performance at scale.
• Rocket.Chat — if your goal is a team chat platform rather than a messaging protocol server. Includes a web client, file sharing, and app integrations. More SaaS-like to operate.
• Mattermost — similar to Rocket.Chat, Go-based, good Slack analogue, includes a usable web and desktop client.
• EMQX — if MQTT is your primary protocol and you’re building IoT infrastructure specifically, EMQX is built around MQTT rather than treating it as a secondary protocol.

---

Bottom line

ejabberd is the XMPP server you choose when you’re serious about messaging infrastructure — not when you’re looking for a hosted chat service you can set up before lunch. It has two decades of production proof, credible concurrency numbers backed by a runtime that Ericsson designed for exactly this problem, and a development team that’s still shipping substantial features in 2025. The Matrix federation bridge is technically impressive work that positions ejabberd well for a world where XMPP and Matrix coexist.

The trade-off is real: this is engineer-operated infrastructure. Configuration complexity, Erlang operational model, manual SQL schema migrations on upgrades, no built-in voice/video, no end-user client — ejabberd asks a lot. If you have those engineering resources, it will reward you with scale and standards compliance that few alternatives match. If you don’t, there are better-fitting tools for your situation, and using ejabberd anyway will cost you more in operational time than you’ll save in SaaS fees.

For non-technical founders looking to escape a chat SaaS bill: ejabberd is almost certainly not your answer. For engineering teams building real-time communication products that need to run at scale without a per-seat tab from a vendor: it very likely is.

---

Sources

1. GigaPros — Ejabberd Hosting (managed hosting provider page). https://www.gigapros.com/portal/ejabberd-hosting/
2. AppMus — Matrix.org vs ejabberd Comparison (2026). https://appmus.com/vs/matrix-org-vs-ejabberd
3. ProcessOne — ejabberd 25.03 Release Notes (Matrix room support, multiple password types, SASL improvements). https://www.process-one.net/blog/ejabberd-25-03/
4. ProcessOne — ejabberd 24.02 Release Notes (Matrix federation, TLS 1.3, SASL2, Bind 2, message retraction). https://www.process-one.net/blog/ejabberd-24-02/

Primary sources:

• GitHub repository and README: https://github.com/processone/ejabberd (6,615 stars, GPLv2 license)
• Official website: https://www.ejabberd.im/
• Documentation: https://docs.ejabberd.im/