Frequently Asked Questions

Why do I need .well-known redirects on the base domain?

The purpose of the /.well-known/matrix/server file is to allow your usernames across the Matrix network to be @someone:your-server.com (and not @someone:matrix.your-server.com).

We normally host your Matrix server at a subdomain like matrix.your-server.com, which means your full usernames will include the whole domain by default (including the matrix. prefix).

To signal that you’d like matrix.your-server.com to be responsible for serving Matrix for the base domain (your-server.com), you need to configure some pointers (redirections) on the base domain. These pointers come in the form of /.well-known/matrix/* files hosted on the base domain. Instead of asking you to host files (which may change in the future) manually, we prepare and keep the files up-to-date on the Matrix server itself and instead ask you to set up HTTP redirects (https://<base-domain>/.well-known/matrix/* -> https://matrix.<base-domain>/.well-known/matrix/*).

Generally, it’s preferable to host your Matrix server on a subdomain (like matrix.your-server.com) and to set up the redirects, so that you have nice and short usernames like @someone:your-server.com and have the base domain available for anything else you want to do with it (e.g., hosting a website).

It’s the same for email services. Your email server may be at mail.your-server.com, but you wouldn’t like your mailbox address to include the full long domain (someone@mail.your-server.com), but rather a shorter and nicer someone@your-server.com.

If you don’t want to or can’t set up these /.well-known/matrix/* redirects on your base domain (your-server.com), we can alternatively set up your server only on matrix.your-server.com. Your usernames will be longer (@someone:matrix.your-server.com), but if that’s alright with you, we can proceed this way. Please, send the phrase “I read the FAQ, I know the consequences of this decision, I’m OK with it.” during the order discussion - this way we’ll understand you know the result and will meet your expectations.

What ports should be open?

Different components require different ports to operate, you can find the mandatory ports in the sections below. The following ports must be open in any case, because they are mandatory for base components of the Matrix stack:

• 22/tcp - SSH
• 80/tcp - HTTP
• 443/tcp - HTTPS
• 8448/tcp - Matrix Federation (mandatory for etke.cc/scheduler as well)
• 3478/tcp+udp - TURN (audio/video calls)
• 5349/tcp+udp - TURN (audio/video calls)
• 49152-49573/udp (port range) - TURN (audio/video calls)

Jitsi

Required only if you want Jitsi to be installed on your server:

• 4443/tcp
• 10000/udp

Email bridge

Required only if you want Postmoogle to be installed on your server:

• 25/tcp
• 587/tcp

IRC bridge

Required only if you want Heisenbridge to be installed on your server:

• 113/tcp

WireGuard + dnsmasq:

Required only if you want WireGuard and/or dnsmasq installed on your server:

• 51820/udp
• 53/tcp+udp

Can I have multiple administrator accounts on my server?

Yes, you can. However, there are some nuances.

By default, the order form on our website only handles a single administrator user account. We make this user account the administrator of the various services listed below:

1. Matrix homesever administration with full access to the synapse-admin tool and various administration APIs of your Matrix server. You can create additional Matrix administrator accounts by yourself (without contacting us) via the synapse-admin tool.

2. etke.cc service management using our scheduler bot for adjusting your maintenance schedule and running other commands against your server. If you need additional Matrix users to manage your server via this bot, you will need to prepare Matrix accounts for them (using synapse-admin , etc.) and send us their Matrix IDs (e.g. @someone:YOUR_SERVER), so we can grant them access to the bot. The only limitation is that these accounts need to be on your server domain, not on other Matrix servers (across federation).

3. Matrix bridge administration granting various super-privileges when messaging bridge accounts. If you need additional users (one yours or on other servers) to be administrators of your Matrix bridges, send us their Matrix IDs (e.g. @someone:YOUR_SERVER or @someone:ANOTHER_SERVER), so we can grant them administrator access to your bridges.

I want to have a different kind of registration (sign-up) flow

By default, we configure invite-based registration on all servers we setup. Running a server with publicly open sign-up is generally not recommended.

Check the supported registration types of your Matrix server below.

(Default) Invite-based Registration

The Matrix protocol supports Token-authenticated registration. Registration on the Matrix server is closed, except for people explicitly allowed to register by a Matrix server administrator.

How does it work? With invite-based registration, any Matrix client will show the standard “Register” button and registration form, but the server will accept the registration request only if a valid invite token is provided.

How do I get this token? An invite token can be issued by the Matrix server’s administrator using the synapse-admin tool. Note that one invite token can be configured to allow multiple registrations (e.g. if you want to share it with your community) and has several other options, like an expiration date.

Is there a way to register without a token? If you’re the Matrix server’s admin - you can register new Matrix users manually (bulk registration is available too), using the synapse-admin tool. Non-administrators cannot register users without a token.

Closed Registration

note: we’ve never seen a use case for switching from invite-based registration to a completely closed registration. If you have one - please, tell us about it

Closed registration is similar to invite-based registration - administrators can still register users manually via the synapse-admin tool (one by one or in bulk), but users can no longer register in a self-service manner using invitation tokens.

Open Registration

note: Completely open registration is very dangerous because, at some point in time, your Matrix server will be overloaded with spammers and bots. This is not just a theoretical threat - we’ve had several cases of customers wishing that we wipe their server clean and reinstall it from scratch because it was easier to start over than to clean up the result of all the spam they got.

Open registration means anyone on the internet can register on your server with no restrictions. After registering, they can communicate with anyone on your server or across the Matrix federated network - sending lots of messages/images/files around and potentially spamming or abusing others.

It’s so dangerous, is there a way to make it a bit safer? Yes, by enabling mandatory email verification. In that case, any registration request will be accepted, but the user won’t be registered until they confirm their email address. An SMTP relay is recommended for this kind of setup. Sending emails directly from the Matrix server itself means that they’re very likely to end up in Spam.

Is Single-Sign-On supported?

With SSO, you can allow registration for a specific group of people using an OpenID Connect provider. Note that SSO works in addition to the registration types described above, so you can combine SSO with invite-based or closed registration or even go with open registration + SSO without domain restrictions.

For example: if you’re using Google Workspace , your Matrix server can be linked to its OIDC provider. This will allow one-click registration to Matrix for all users of your Google Workspace, but restrict anybody else.

My newly-installed server joins new rooms very slowly

Matrix servers begin their life by not knowing anything about other Matrix servers, so when you join a room over federation (e.g. even a small one, like #news:etke.cc , with a few messages per week), your Matrix server does the following:

1. Contact some homeserver (likely etke.cc in this case) and ask it about the room you’re joining (#news:etke.cc)
2. Contact the Matrix servers of all current members of the room, to get information about their servers and user profiles
3. Combine all this data and calculate the room state to show the room’s details and last messages

Each step is rate limited (to prevent DoS attacks ). The target server may experience network issues or be overloaded. Some servers may even be offline. The process may be fast enough in small rooms, but in larger rooms, your server will take a long time to request and process all the information it needs before it can properly display the room.

Don’t worry! Joining rooms on servers yours already knows about will be way faster, so be patient the first time around. All Matrix servers have such issues at first because they haven’t built up their network yet. Eventually, your server will have enough knowledge about federation to make room joins fast, even almost instantaneously.

Bridge bot doesn’t respond

The 2 common problems with bridges are:

• Wrong bridge MXID
• Encrypted room

Firstly, ensure you’re trying to contact the correct bridge bot because some client apps may suggest you to contact a bridge bot from some other server. Correct bridges’ Matrix IDs are listed in your onboarding list, plus you can find them on the bridges’ documentation pages .

Secondly, by default we set up all bridges with encryption support disabled because it’s an unstable feature (of course, encryption support can be enabled for bridges that support it if you explicitly ask about that). Unfortunately, some client apps create encrypted rooms by default when you try to start a new 1:1 chat with a bridge bot. If you don’t have “enable encryption” configuration option while creating a 1:1 room, you can try to avoid that by creating a new room (not starting a chat with a specific user, but just creating a room) and unclicking the encryption option. After that, you can invite a bridge bot into that room.

Anything else?

If the answers above don’t help to solve your problem, please check our other documentation resources.