Prosody keeps XMPP useful by staying small

This real Wikimedia Foundation server-rack photograph fits because Prosody's practical story is about owning a small piece of communication infrastructure: domains, TLS, federation, modules, logs, and packaged services rather than an outsourced chat silo.[7]

Prosody is easy to underestimate because XMPP itself is often filed as an older internet protocol. That misses the useful shape of the project in 2026. Prosody is not trying to become an all-in-one workplace suite. It is a small, extensible XMPP server that lets an operator run messaging under a domain, federate when they choose, add modules deliberately, and keep the operational surface closer to a mail server than to a proprietary team-chat platform.[1][2]

As of 2026-06-10T06:33:19Z UTC, the upstream site lists Prosody 13.0.6, released on 2026-05-27, as the latest 13.x release, with 0.12.6 also published on 2026-05-01 for the older stable line.[1][3] The FreeBSD FreshPorts entry likewise shows prosody at 13.0.6, with a last update on 2026-05-27, while Debian's tracker shows active 13.0.x packaging movement through unstable, testing, and backports earlier in 2026.[6][8] That matters because a self-hosted communications server lives or dies by boring continuity: package availability, security fixes, upgrade paths, and enough upstream motion that operators are not nursing abandonware.

Image context: the cover uses a real data-center photograph, not a diagram or logo. Prosody is software, but the adoption decision is physical in the end: a reachable host, DNS records, certificate handling, ports, logs, storage, and enough network reliability that people can treat the domain as a real address for communication.[7]

The Core Bet Is A Domain, Not An App

Prosody's homepage defines the project as a modern XMPP communication server that aims to be easy to set up, efficient with system resources, and easy for developers to extend.[1] The important word is "server." A Prosody deployment begins with the same mental model as email: a domain represents an administrative boundary, and that domain may communicate with other domains through a protocol rather than through one vendor's account system.

The server-to-server documentation makes that architecture explicit. XMPP servers can communicate with each other to form a federated network, and Prosody supports that s2s path out of the box.[2] The minimum operating checklist is refreshingly concrete: a public domain, a public IP path, and port 5269 open for server-to-server traffic.[2] If the user's address domain and the machine's server domain differ, SRV records enter the design.[2]

That is the first adoption boundary. Prosody is strongest when the team actually wants domain-owned communication. A small organization, community, lab, family service, or public-interest project can run addresses under its own domain and decide whether to federate broadly, federate selectively, or keep the service more private. If the organization only wants a polished SaaS inbox with no protocol ownership, Prosody will feel like unnecessary plumbing.

The comparison to email is helpful but incomplete. Email federation became unavoidable infrastructure; XMPP federation is optional for many groups. That makes Prosody less universal and more intentional. The best users are the ones who see the domain as part of the product. They care that [email protected] is not only a login but an address inside a larger protocol space. They also accept that federation brings policy work: abuse handling, TLS decisions, DNS correctness, and expectations about which remote servers are allowed to talk to them.

Federation Is A Policy Surface

Prosody's s2s defaults are deliberately pragmatic. The docs say Prosody will try TLS when the remote server supports it, and otherwise fall back to dialback when the certificate is not trusted or suitable.[2] Operators can tighten that posture with s2s_secure_auth = true, which requires encryption and certificate authentication, or they can define exception lists such as s2s_insecure_domains and s2s_secure_domains.[2] That is not cosmetic configuration. It is the trust contract of a federated messaging service.

This is where Prosody asks for mature ownership. A casual deployment can open federation and discover later that the hard work was never the Lua package. It was deciding how much of the XMPP network to trust, how to handle domains with weak certificates, how to keep stanza sizes under control, and when to disable s2s for a host that should not federate at all.[2] The project gives knobs, but the operator still supplies policy.

The 13.0 release line made that policy story more explicit inside the server as well. Prosody 13.0.0 introduced a roles and permissions framework with built-in roles for instance-wide operators, virtual-host admins, trusted members, registered accounts, and guests.[4] That matters because XMPP servers are not only packet relays. They are communities with local accounts, rooms, pubsub services, and administrative actions. A stronger role model reduces the temptation to solve every privilege problem with a global admin account.

For teams evaluating Prosody, this is the practical question: can you name the trust zones before users arrive? Public federation, private federation among known domains, and a closed internal XMPP service are different systems even if they use the same binary. Each choice changes DNS, certificate strictness, registration policy, room creation, spam posture, moderation, and support expectations.

Modules Are The Product Boundary

Prosody's second strong idea is extension by modules. The community module directory describes Prosody as customizable through plugins that change default behavior or add new features, while warning that modules vary from proof of concept to production-ready and should be evaluated through their own documentation.[5] The directory currently lists 482 modules, grouped by categories such as authentication, registration, storage, MUC, web, pubsub, s2s authentication, statistics, and XEP support.[5]

That module ecosystem is the reason Prosody can stay small without becoming static. A minimal server can remain close to core XMPP behavior. A community server can add cloud push notifications, HTTP file sharing, MUC controls, account lifecycle tooling, metrics, spam controls, or storage backends. The module model lets Prosody remain an extensible communications substrate rather than a fixed product bundle.

It also creates the main failure mode. A module directory is not a managed marketplace with one uniform support promise. Some modules are stable; many are beta, alpha, uncategorized, or explicitly marked with warnings.[5] A serious operator should treat module selection like dependency selection in any other server stack: read the maintenance state, test upgrades, document why each module exists, and avoid accumulating features just because they are available.

The FreeBSD port listing is a useful reality check here. It shows a compact service package, but also a large installed file list: prosodyctl, core managers, networking backends, storage modules, MUC libraries, WebSocket support, OpenMetrics, server contact info, TLS modules, and more.[8] Prosody may feel simple at the top, but a production deployment still has real subsystems. The right virtue is not "tiny means trivial." The right virtue is that the subsystem boundaries are visible enough for an operator to reason about them.

Day-Two Operations Are Now First-Class

The most interesting Prosody 13.0 changes were not flashy chat features. They were day-two operations. The release notes describe expanded prosodyctl shell capabilities, including user-management commands routed through the admin connection, pubsub management commands, real-time log watching, stanza watching for arbitrary JIDs, server-wide announcements, and new MUC inspection commands.[4] Those are operator tools, not onboarding fireworks.

That emphasis is healthy. A communications server becomes important only after people depend on it. At that point, the questions change. Can an account be disabled rather than deleted? Can an accidental deletion have a grace period? Can a room's occupants and affiliations be inspected without writing a custom client? Can debug logs be streamed without storing more sensitive material than necessary? Can administrators diagnose client behavior by watching stanzas in a controlled way?[4]

Prosody 13.0 also improved network behavior through Happy Eyeballs support for IPv4/IPv6 connection attempts, better SRV weight handling, and optional TCP Fast Open or deferred accept behavior in the server_epoll backend.[4] Storage got attention too: internal archive stores gained better query performance through indexes, SQLite users gained a LuaSQLite3 path, and SQLCipher compatibility became available for encrypted SQLite databases.[4] These details are not headline bait, but they decide whether a small server remains comfortable as usage grows.

The latest 13.0.6 release continues that maintenance pattern. It fixes a cloud-notify memory leak, avoids echoing a new password back through the admin shell, fixes pubsub subscription cleanup, and includes a spread of smaller parser, WebSocket, STUN, storage, timer, and crypto-related fixes.[3] The shape is exactly what an operator should want from a mature server: fewer surprises at the edges where clients, network paths, and administrative commands meet.

Where Prosody Fits

Prosody fits teams that want an owned messaging service with a clear protocol boundary. It is a good candidate when the operators can manage DNS, certificates, ports, backups, authentication, room policy, module selection, monitoring, and upgrades. It is especially attractive when the organization wants federation as an option rather than a platform mandate, or when the service needs to integrate with an existing domain identity story without buying into a full collaboration suite.[1][2][5]

It fits less well when the team wants chat with no infrastructure owner. Prosody can be efficient, packaged, and configurable, but it still creates a service that people will treat as communication infrastructure. Someone has to own TLS exceptions, user lifecycle, abuse reports, push-notification choices, file-sharing retention, MUC governance, logs, and database or filesystem storage. Installing the package is the easy part.

The conservative adoption path is narrow. Start with one domain and a small user group. Decide whether server-to-server federation is open, closed, or disabled. Keep the module set short. Enable only the features you can explain during an incident. Confirm package and release-channel expectations for your operating system. Test account disablement, room administration, backup and restore, certificate renewal, and log access before the server becomes authoritative for the community.

Read this way, Prosody's value is not nostalgia. Its value is disciplined smallness. It gives XMPP a server shape that is still understandable: domain at the edge, federation as a choice, modules as explicit extensions, roles for local authority, and admin tools for the work that starts after the first successful login.

cronfeed.work