Monster Manual: ejabberd
Stat Block
| Dimension | Score | Rating |
|---|---|---|
| Structural difficulty | 10/14 | Impractical |
| Compliance/maintenance | 9/13 | Very High |
| Confidence | High | |
| Estimated packaging effort | 40-80 hours | |
| Ongoing maintenance | High |
Repository: github.com/processone/ejabberd Language: Erlang/OTP License: GPL-2.0 Stars: 6,500 | Last release: 25.10, October 2025 | Release frequency: 3-4 per year (CalVer)
The Verdict
ejabberd is a fundamentally poor fit for Cloudron. The core problem is not the application itself (ejabberd is well-engineered and well-documented) but a structural mismatch between what XMPP requires and what Cloudron provides.
XMPP is a TCP protocol: clients connect on port 5222 with STARTTLS, federation happens on port 5269, and optional services use MQTT (1883), SIP (5060), and STUN/TURN (3478 UDP+TCP). Cloudron only proxies HTTP traffic. This means the core function of ejabberd (being an XMPP server that clients connect to) cannot work through Cloudron’s reverse proxy.
A Cloudron staff member (murgero) started a packaging attempt and described it as “quite the beast”, specifically citing difficulty with the overlaying ACL and access rules.
Structural Analysis
A1. Processes (1): Single Erlang VM with EPMD (Erlang Port Mapper Daemon) on port 4369. Effectively 2 processes.
A2. Data storage (0): Default is Mnesia (Erlang’s built-in database, flat files). Also supports MySQL and PostgreSQL via Cloudron addons. Since 23.10, ejabberd can auto-create and auto-update SQL tables.
A3. Runtime (2): Erlang/OTP is not in cloudron/base:5.0.0. Must install from packages or use the bundled ejabberd binary installer (~100 MB).
A4. Message broker (0): No external broker. All message routing is internal to the Erlang VM.
A5. Filesystem writes (2): Writes to Mnesia spool, logs, uploaded files, TLS certificates, module installations, configuration cache, and CAPTCHA temp files. Requires 8-10 symlinks.
A6. Authentication (0): Excellent native LDAP support (auth_method: ldap) with shared rosters, vCard population, and group-based access. One of ejabberd’s strongest points.
Compliance Analysis
B1. SSO quality (0): Native LDAP is mature and well-documented. Over 15 years of LDAP/AD integration. Genuinely excellent.
B2. Upstream stability (0): Active development since 2002 by ProcessOne (commercial company). CalVer releases are regular with clear upgrade documentation.
B3. Backup complexity (1): Mnesia requires ejabberdctl backup/restore commands. SQL backend is handled by the Cloudron addon.
B4. Platform fit (3): The critical blocker. Requires ports 5222 (client), 5269 (federation), 5280/5443 (HTTP), 1883 (MQTT), 3478 (STUN/TURN), 4369-4399 (EPMD). Only the HTTP ports work through Cloudron’s proxy. Without 5222 and 5269, ejabberd cannot function as an XMPP server.
B5. Config drift (2): ejabberd.yml is one of the most complex config files in the self-hosted ecosystem. Runtime module installation writes to the filesystem. TLS certificates must be self-managed.
Key Risks
The TCP port limitation is a hard blocker, not a packaging challenge. XMPP clients connect on port 5222 (TCP with STARTTLS). Federation uses port 5269. Without these exposed, ejabberd cannot serve its primary function.
STUN/TURN requires UDP for voice and video calling. Cloudron has no UDP support. Voice/video would be non-functional.
The Mnesia database is bound to the Erlang node name (which includes hostname). If the container hostname changes between restarts, the database becomes unreadable without migration.
Recommendation
Do not attempt unless Cloudron adds raw TCP port passthrough. The community is packaging Prosody instead, which faces the same port limitations but is lighter and simpler. See the Prosody assessment for details.
If XMPP-over-WebSocket (severely limited, web clients only, no federation) is acceptable, a theoretical packaging approach exists but would produce “ejabberd Web Admin and WebSocket Gateway”, not a full XMPP server.