Prerequisites¶

In order to set up a Continuwuity server, you will need the following:

• A server running Linux (BSD is also supported, but takes a bit more work to set up, and is not covered in this guide).
• A domain name that you own, and can point to your server.
• An internet connection of at least 1Mbps (far more is recommended) that is not behind NAT (see further down for advice on getting around the NAT restriction).
• A basic understanding of how to use the command line, edit files, and use SSH.
• Around half an hour to set it up.
• An IPv4 address (IPv6 only is technically possible, but most of the federation still doesnt support it, so you will be unable to communicate with most other servers).

Getting around NAT, firewalls, and IPv6-only networks¶

If you're hosting at home, chances are you are behind NAT, and/or have a firewall that you may not be able to configure. The easiest way around this is to use a VPS (cloud server). This cloud server will have a public facing IP address, usually both an IPv4 AND IPv6, and will also likely have a static IP address, which is important for federation.

If you are not planning to host Continuwuity on your own hardware, you should skip this section - I am only recommending cloud servers for getting around NAT/firewall issues. If you are hosting Continuwuity on a cloud server, I expect that you already know how to pick what you need.

Picking a cloud provider¶

You can use an Oracle Cloud Free Tier instance, but be aware that they are not reliable, and may be suspended at any time. I cannot recommend any other "free" providers, as they have all so far proven to be sketchy. It's worth noting that some server administrators will also firewall block IP ranges that are frequently abused (such as free cloud providers'), meaning that your federation with them will be hampered, and E2EE with them will not work.

I personally recommend any of the following providers (having used them myself):

Note: The prices listed here as as of 2025-04-25, and are currently very likely to change, especially the conversion rates. $currentYear and all that.

Setting up tailscale¶

Note: You need sudo/root access to your VPS, local server, and own device.

This section will be brief, and expects you to know how to SSH into your server. This also assumes you picked Debian or Ubuntu as your OS.

Here, we're going to install Tailscale, a remote-access solution that uses wireguard to create a secure tunnel between your server and your home network. This will be used to allow your server to communicate with your home network, and vice versa.

First of all, create an account on Tailscale. After signing up you will need to select "personal use", and then you will be given the instructions to install Tailscale on your own device.

After you have installed Tailscale, you will need to log in. On Linux, just run sudo tailscale up, and it will give you a link to open in your browser. Open the link, and log in with the same account you just created.

You can then go back to the welcome screen, and will have a view like this:

Next, you will need to connect to the server that you intend to run Continuwuity on, and install Tailscale there too.

Follow the same steps, and then the tailscale website will show you a new device and a ping command to test the connection with. Once you've confirmed that the connection is working, go ahead and install Tailscale on your VPS, following the same steps as before.

After installing Tailscale and confirming the connection on all three devices, you will want to go to the Tailscale admin console. It will look something like this:

In order to prevent the connection between your VPS and your home server from being interrupted, you will want to make sure that neither devices expire. To do this:

1. Click on the three dots next to the device you want to persist.
2. Click on "Disable key expiry".

Do the same for each server in the chain. After you've done this, your admin dashboard should look like this:

(note that in this example, vm is my "personal device")

And that's it! You now have a secure connection between your home server and your VPS, which persists through the NAT/firewall. Details on how to set up the reverse proxy and Continuwuity follow.

Getting a domain name¶

In order to participate in the Matrix network, you will need a domain name. While it is not technically required (you can just use an IP address), you will not be able to join a very large portion of Matrix rooms without a domain name attached to your server.

Getting a domain is actually very cheap - if you aim to use top-level domain names (TLDs) like .com, .net, .org, etc, or country-code TLDs (ccTLDs) like .uk, .de, etc, you can expect to pay around £5-£10 per year for a domain name. It will literally cost you less than a Tesco meal deal.

I personally use Porkbun, which is usually quite cheap. There are other options, such as Namecheap, CloudFlare (but also, f*ck CloudFlare), and Hetzner and OVH. Starship is also worth a mention.

Do NOT use any "free" domains/providers. They are usually frequently used for abuse, and are commonly blocked from Matrix rooms. Also - if the domain you use expires, you won't be able to continue to use your server, unless you re-register it. This is because your user ID (identity) is tied to your domain name.

In this example, I'm going to be using Porkbun, because that's where I have all of my domains, and I'm not buying one for the sake of showing you how to do it and set up the server, I'll be re-using one I already have.

Go ahead and pick the domain you want to use, register it, and then come back to this guide, because the next step is:

Planning your DNS records¶

For Matrix, you only actually need one DNS record - the A/AAAA record for your apex domain. A lot of people use matrix.example.com as their server, and have their server name set to example.com, but this is not required. In this guide, I won't cover using a subdomain, but you can easily adapt the instructions to use a subdomain instead of an apex domain.

Your server name cannot change after you set it up, so if you want the example.com server name, make sure that you set that. It doesn't matter if you then run matrix on matrix.example.com, but you will need to set the server name to example.com in the config file.

Furthermore, you must always have control over your server name's domain - it is where servers will go to figure out what domain to contact your server on, and if that fails, you'll struggle to federate!

Here's how I have my records set up for nexy7574.uk:

That's it!

You should point the IP addresses at the server where the below Caddy reverse proxy is running. If you bought a VPS to circumvent NAT/firewall issues, you would point the IP addresses at that server. See below for an example of splitting traffic between the origin and the reverse proxy, if that's something you can and want to do.

Using a subdomain¶

If you want to use a subdomain, you will need additional records. I only recommend this if you want to serve matrix from a different server and don't want to route the traffic through your reverse proxy.

For one of my servers (I'll use example.com as a placeholder), I serve client-to-server traffic (things like login, sending messages, downloading images, etc) through my VPS, which applies some caching, but also allows me to absorb a DDOS attack if that happens. However, to reduce federation latency, I serve server-to-server traffic (federation) directly from my home server.

This means I have the following records:

Of course, this is a very complicated example. It could be optimised by not using the matrix subdomain for client-to-server traffic and instead only serving it on the apex domain, but I created that subdomain ages ago and never bothered changing it. The matrix-fed subdomain was set up so that Matrix federation traffic could bypass the reverse proxy on my VPS, instead serving straight from the origin. I did this because I got hit with a DDoS attack that overloaded the link between my VPS and my home server, but my home server was still capable of serving federation traffic.

I don't recommend this unless you know what you're doing, and you have a good reason to do it.

Now that you've got the prerequisites out of the way, you can move on to setting up Caddy.