Public servers

To contribute to the XMPP network, some people choose to run servers on which people can obtain free XMPP accounts.

This page aims to document some best practices for those servers. This is not a complete guide! Running a public server brings a fair amount of responsibility upon the admins, and requires a fair amount of oversight.


The most basic property of a public server is that it is open for registration.



This module allows people to register and manage XMPP accounts. By default it will allow users to change their password but will *not* allow registration of new accounts. To enable this set ‘allow_registration’ to true.

Servers with unrestricted registration are open to abuse and provide an easy method for spammers to get onto the XMPP network. If you do not control this, your server may be blocked by other servers on the network.

Some tips for controlling registration:

  • Set min_seconds_between_registrations to a sensible value (this is a per-IP rate limit). Note that spammers have lots of IP addresses and lots of time, so this limit alone is not enough to prevent abuse.


Documentation (community module)

This module allows you to set a list of reserved account names that cannot be registered on the server. It only affects normal account registration, not commands such as prosodyctl adduser.



This module alerts admins of new accounts, allowing you to keep an eye on how often accounts are created.

If you do not monitor this you may end up with many spam accounts.

Be sure that the admins setting contains a list of service administrators.


The XMPP Core RFC encourages providing an email mailbox xmpp (eg ) for inquiries related to your XMPP service. It can be thought of as a default contact address in case discovery via mod_server_contact_info is unavailable or unreachable.



This module advertises addresses where you can be reached. Especially the abuse address should be set for public servers, which should point to the address of you or someone who will deal with abusive users or spam accounts.

Abuse prevention



This module limits bandwidth used by XMPP sessions. This helps to protect the server and XMPP network from certain types of abuse, and ensures that e.g. a single user cannot consume all the server’s resources.

Traffic patterns between servers may vary, but here is an example that is being used in production on a large server and was based on observing typical usage patterns:

        limits = {
                c2s = {
                        rate = "3kb/s";
                        burst = "2s";
                s2sin = {
                        rate = "30kb/s";
                        burst = "3s";


Documentation (community module)

If you run a MUC (chatroom) service, this module helps to prevent flooding of rooms.


Documentation (community module)

This module allows admins to respond to abuse promptly with a rule-based configuration that is able to drop and reject XMPP stanzas, as well as many other features.



Prevents registration of usernames visibly similar to existing usernames to prevent spoofing attacks.



Prevents registration of usernames that have been deleted, in order to prevent access to any group chats or other resources that may not have revoked access.


If your server grows large, there are some things to consider:

  • Raise the per-process file limit. When running under systemd this can be done by adding a directive to the systemd drop-in directory /etc/systemd/system/prosody.service.d/ (create it if necessary) and add the following configuration file:

    # /etc/systemd/system/prosody.service.d/LimitNOFILE.conf


As with any server, you need to have a good backup and restore plan. Your users will not be happy if a disk or database failure destroys all their accounts and data, for example.