Frequently Asked Questions

Can I migrate my server or its data to etke.cc?

I want to get a new Matrix server from etke.cc based on exported data from my current provider

The short answer is: no - we do not support migration. It may be technically possible some of the time (see details above), but it’s too much manual work for us and doesn’t guarantee a 100% migration.

If another provider is currently hosting your Matrix server and provides a data export, you may be wondering if you can just migrate the data and continue running your server with us.

Depending on various things, migration may or may not be technically possible or financially justified.

• If your homeserver is based on software other than Synapse , migration is not possible. We only support Synapse right now and migrating data between homeserver implementations is not supported.
• If you are not using your own domain (e.g. example.com), but rather a subdomain (example.hosting-provider.com), migration is not possible. Using the old domain (owned by your current provider) is not possible and migrating data between domains is not supported in Matrix yet.
• If your data export contains a Postgres database, it may possible to import it into our system with manual work on our side
• If your data export contains a .signing.key file, we can easily make use of it for your new server hosted with us
• If your data export uses the default/native media store for the Synapse homeserver, it can be migrated with manual work on our side. However, certain hosting providers (e.g. EMS) use an alternative media store (matrix-media-repo ) and we cannot migrate media files stored that way.

Because there are a lot of variables in this and manual work is necessary, it may be impossible to achieve a 100% migration. Even if it is possible, we do not have automated processes for this. As such, it will require going over the exported data and manually importing it into our system, which is a non-trivial amount of manual work.

For these reasons, we cannot afford to support migration and recommend starting fresh.

When starting fresh, you have 2 options:

1. It’s easiest if you use a different domain:

• this way, there won’t be Matrix Federation conflicts with your previous server
• you can get your brand new server by submitting an Order and following the steps there

2. You may re-use your existing custom domain (and start with empty data on it) with this flow:

• while still using the server from your existing provider, leave all federated rooms from it
• get a data export and extract the .signing.key file from it
• submit our Order form
• in the email communication with us (before paying for your order), send over the .signing.key file

Re-using an existing domain can work reasonably well if you leave all federated rooms before switching to a brand new server (having a fresh empty database). If you fail to leave federated rooms, other servers on the Matrix federated network may think you are still part of some rooms while your server thinks it’s not (given its brand new database). Such a state mismatch may cause federation issues.

I want to have an existing Matrix server installed with matrix-docker-ansible-deploy to be maintained by etke.cc

If you have a relatively up-to-date server installation done with the matrix-docker-ansible-deploy Ansible playbook, it may be possible to migrate your setup to us.

However, it will require prior reviewing of your existing configuration, as components offered on etke.cc (which you can see on our Order Form ) differ from those offered by the Ansible playbook.

Please, contact us and send over a cleaned up (no passwords and secrets) version your vars.yml file, so we can let you know if:

• we can migrate your setup as-is immediately
• or, we’re planning on adding support for the services that you’re missing

I want to have existing Matrix servers installed using any other method to be maintained by etke.cc

Unfortunately, that is technically impossible.

Why are .well-known redirects on the base domain important?

We typically host your Matrix server on a subdomain, like matrix.your-server.com. This normally results in full usernames which include the matrix. prefix (e.g. @someone:matrix.your-server.com).

To host Matrix on a subdomain, but have cleaner usernames which do not contain the subdomain (e.g. @someone:your-server.com), so-called delegation is necessary. It’s a similar concept to email services, where you might have an email server at mail.your-server.com, but your mailbox addresses are still like someone@your-server.com.

Matrix server delegation can be done either with DNS SRV records or with well-known files. DNS SRV record delegation is not supported by us, because its SSL certificate setup is peculiar.

Our setup only supports the well-known file delegation method, which involves you setting up a few redirects (/.well-known/matrix/*) on your base domain. Setting up these redirects allows for shorter, more user-friendly usernames, while still keeping your base domain available for other purposes (such as hosting a website).

Here is the full list of redirects you need to configure (assuming your base domain is your-server.com):

• https://your-server.com/.well-known/matrix/server -> https://matrix.your-server.com/.well-known/matrix/server
• https://your-server.com/.well-known/matrix/client -> https://matrix.your-server.com/.well-known/matrix/client
• https://your-server.com/.well-known/matrix/support -> https://matrix.your-server.com/.well-known/matrix/support

Alternatively: if you are unable or unwilling to configure these /.well-known/matrix/* redirects on your base domain, we can set up your server exclusively on matrix.your-server.com. In this case, usernames will be longer, such as @someone:matrix.your-server.com. Please, indicate your preference during the order discussion!

Also: if you do not need to make use of your base domain for hosting a website right now, it’s easiest if you point the base domain’s DNS record to the Matrix server’s IP address and have us handle the redirections on your behalf.

What are the base Matrix components installed on the server?

We offer a lot of optional Matrix bridges , bots and extra services , but all Matrix servers come installed with a set of core Matrix components:

• the Synapse Matrix homeserver software. At this moment, this is the most complete and compatible homeserver implementation. We currently do not offer alternative homeserver software like Conduit , Construct or Dendrite .

• the matrix-synapse-shared-secret-auth module for Synapse, which assists various bridges and bots with authentication

• the synapse_auto_compressor tool, which runs in the background and periodically compresses the database for the Synapse homeserver, so that it runs optimally.

• the sliding-sync software which assists next-generation clients like Element X in talking to the homeserver in an optimized manner. In the future, it’s expected that the homeserver itself (e.g. Synapse) will handle these tasks, but for now a separate component is necessary.

• the Synapse-Admin web UI tool for homeserver management

• the Coturn TURN server, to assist audio/video calls

• a PostgreSQL database server, storing the data for Synapse and other services

• (only for Bring-your-own-server types of orders), the docker-postgres-backup-local software which makes periodic local backups of your PostgreSQL database - we store 7 daily database dumps by default. For Turnkey orders (hosted on Hetzner Cloud VPS servers rented by us), we do not enable local Postgres database dumps, because we enable Hetzner’s server backups feature , which stores the last 7 daily full-disk snapshots.

• optionally, the Element web application for chatting on your Matrix server, but we also support some alternative client applications like Cinny and SchildiChat . Regardless of the web application we may install on your server, you can connect to your server via any compatible Matrix client application on any platform.

• a Traefik reverse-proxy server, which obtains free Let’s Encrypt SSL certificates for all domains used in your setup

• a Prometheus Node Exporter agent for basic monitoring and alerting. Metrics data is collected by our own external Prometheus system which also does alerting. In the event of trouble, alerts go out to us and to you via email and Matrix.

What ports should be open?

Matrix server components require various ports for operation. The mandatory ports for the base components of the Matrix stack are as follows:

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

Jitsi:

These ports are required only if you want to install Jitsi on your server:

• 4443/tcp
• 10000/udp

Email bridge:

These ports are required only if you want to install Postmoogle on your server:

• 25/tcp
• 587/tcp

IRC bridge:

These ports are required only if you want to install Heisenbridge on your server:

• 113/tcp

Firezone:

These ports are required only if you want Firezone on your server:

• 51820/udp

Peertube:

These ports are required only if you want Peertube on your server:

• 1935/udp

Can I have multiple administrator accounts on my server?

Yes, you can have multiple administrator accounts on your Matrix server. However, there are some important details to consider:

1. Matrix Homeserver Administration: By default, our order form on the website configures a single administrator user account. This user has full access to the synapse-admin tool and various administration APIs of your Matrix server. You can create additional Matrix administrator accounts using the synapse-admin tool without needing to contact us.
2. etke.cc Service Management: To manage your server using our scheduler bot for maintenance scheduling and other commands, you need to prepare Matrix accounts for additional administrators. You can create these accounts (e.g., using synapse-admin ) and provide us with their Matrix IDs (e.g., @someone:YOUR_SERVER). We will grant them access to the bot. These accounts must be on your server’s domain and not on other Matrix servers across federation.
3. Matrix Bridge Administration: If you require additional administrators for your Matrix bridges, whether on your server or other servers, provide us with their Matrix IDs (e.g., @someone:YOUR_SERVER or @someone:ANOTHER_SERVER). We will grant them administrator access to your bridges.

Can I change the registration (sign-up) flow?

By default, we configure invite-based registration on all servers we set up. Enabling completely open registration is generally not recommended due to potential spam and abuse.

Check the supported registration types for your Matrix server below.

(Default) Invite-Based Registration

The Matrix protocol supports Token-authenticated registration . This means registration is closed by default, allowing only those with a valid invite token to register. Admins can issue invite tokens using the synapse-admin tool, and each token can be configured for multiple registrations with various options, including expiration dates.

Closed Registration

Closed registration is similar to invite-based registration . Admins can still manually register users using the synapse-admin tool, but users cannot register themselves with invitation tokens.

Open Registration

Completely open registration allows anyone on the internet to register on your server without restrictions. However, this can lead to spam and abuse. To enhance security, you can enable mandatory email verification, ensuring users confirm their email addresses. An SMTP relay is recommended for this setup to prevent emails from landing in spam.

Single Sign-On (SSO)

You can use Single Sign-On (SSO) with an OpenID Connect provider to allow registration for specific groups of people. SSO can work alongside other registration types, including invite-based , closed registration , or open registration with or without domain restrictions. For instance, you can link your Matrix server to a provider like Google Workspace for one-click registration for your users while restricting access for others.

My newly-installed server joins new rooms slowly

Newly set up Matrix servers lack knowledge about other servers. When you join a room over federation, your server contacts other servers and retrieves data about the room and its members. This process can be slow, especially in larger rooms, as each step involves rate limiting and potential network issues. Over time, your server builds a network of federated servers, and room joins become faster. Be patient, and room joins will improve with time.

Bridge bot doesn’t respond

If your bridge bot isn’t responding, there are two common issues to check:

1. Wrong Bridge MXID: Ensure you’re contacting the correct bridge bot associated with your server. Make sure to use the correct Matrix IDs, which are listed in your onboarding materials or bridge documentation pages .

2. Encrypted Room: We typically set up bridges with encryption support disabled as it can be unstable. Some client apps may automatically create encrypted rooms when trying to chat with a bridge bot. To avoid this, create a new room and disable encryption. Then invite the bridge bot to the room

If you encounter other issues, please refer to our additional documentation resources.

Payments

We’ve prepared a dedicated page with payment guides and instructions .

When will old subscriptions (Maintenance and Turnkeys) be deprecated?

Since December 2023, we operate on a new pay-by-complexity service model under which customers pay a different monthly subscription fee - based on the services we are providing to them. Customers who order a basic server with few components pay minimally (e.g. $5/mo), while others who order tens of services pay more (e.g. $100/mo). People on this new By Complexity subscription tier are always charged according to the services we run for them and this FAQ entry does not apply to them.

Customers from before December 2023 are on an old subscription tier (Maintenance, Maintenance + Email or Turnkey) which has a fixed price. Such customers can keep their existing subscription under certain conditions.

Until 1st of July 2024, existing customers can remain on their old subscription tier as long as the subscription is active (not overdue) and the services we provide to them remain unchanged. That is:

• if customers subscription is overdue (i.e., inactive), we’ll ask them to switch to the new By Complexity subscription tier
• if customers continue to use the same services, they can remain on the same subscription tier and we won’t charge them differently
• if customers request additional services from us, we’ll need to ask them to switch to the new By Complexity subscription tier, so we can charge them fairly according to our new pricing model

After 1st of July 2024, any existing customer who contacts our support will be asked to switch to the new By Complexity subscription plan. If customers wish to continue using our services without support, they can remain on the same subscription tier for longer. We have not yet established a final date after which we’ll completely abandon the old subscription tiers.

Announcement with details

What about deprecated components?

It’s been a long time since we deprecated certain components and replaced them with better-working alternatives. Even though the old components were deprecated and considered unmaintained by us, some of our customers continued using them for a long time.

Despite us proclaiming these components as unmaintained, we still put effort into supporting them - trying to fix problems our customers sometimes encountered. In the end, such components still misbehaved once in a while and we couldn’t always make it fully work. If a component is unmaintained by its developers, we cannot help maintaining it ourselves because eventually it becomes incompatible with modern APIs, and there is nobody to fix the component’s code and make it compatible again.

This has prompted us to re-evaluate the current status of our deprecated components. To avoid having to invest effort maintaining something which we proclaimed as unmaintained many months ago, we’ve set a schedule for completely eliminating all deprecated components.

This includes the following components:

• Discord bridge (mx-puppet-discord) which has been unmaintained by its developers since May 2022. It got superseded by Discord bridge (mautrix-discord)
• Slack bridge (mx-puppet-slack) which has been unmaintained by its developers since May 2022. It got superseded by Slack bridge (mautrix-slack)
• Webhooks bridge (appservice-webhooks) which has been unmaintained by its developers since November 2022. It got superseded by Webhooks bridge (hookshot)
• Dimension integration manager which is unmaintained by its developers since November 2022. There is no free-software alternative integration manager
• Wireguard (and dnsmasq) which has been superseded by Firezone
• Facebook bridge (mautrix-facebook) which has been archived by its developers since March 2024. It got superseded by Facebook bridge (mautrix-meta)
• Instagram bridge (mautrix-instagram) which has been archived by its developers since March 2024. It got superseded by Instagram bridge (mautrix-meta)

If you use any of them, there are 2 paths going forward:

1. We can transition your server to the new components. If you’re not on our Pay-by-complexity model (the new pricing model described above), you’ll need to switch to it. This means your monthly subscription price may change to become lower or higher. For most people, there’s a price increase due to our exceedingly generous pricing in the past.
2. Alternatively, you can keep using the old components (should they still work for you) until 1st of July 2024. At that time, we’ll remove them from our automation and they will get uninstalled from your server. If you choose this path, you won’t have additional time to migrate. At any time you wish, we can upgrade you to the new components as described in #1.

We understand this is a breaking change, but we don’t see a reason to maintain components, already proved to be misbehaving and deprecated for years.