Fediversity/matrix/checklist.md

# Checklist

Before you dive in and start installing, you should do a little planning
ahead. Ask yourself what you expect from your server.

Is it a small server, just for yourself and some friends and family, or for
your hundreds of colleagues at work? Is it for private use, or do you need
decent moderation tools? Do you need audio and videoconferencing or not?


# Requirements

It's difficult to specify hardware requirements upfront, because they don't
really depend on the number of users you have, but on their behaviour. A
server with users who don't engage in busy rooms like
[#matrix:matrix.org](https://matrix.to/#/#matrix:matrix.org) doesn't need more
than 2 CPU cores, 8GB of RAM and 50GB of diskspace.

A server with users who do join very busy rooms, can easily eat 4 cores and
16GB of RAM. Or more. Or even much more. If you have a public server, where
unknown people can register new accounts, you'll probably need a bit more
oompf (and [moderation](draupnir)).

During its life, the server may need more resources, if users change
their behaviour. Or less. There's no one-size-fits-all approach.

If you have no idea, you should probably start with 2 cores, 8GB RAM and some
50GB diskspace, and follow the [monolithic setup](synapse).

If you expect a higher load (you might get there sooner than you think), you
should probably follow the [worker-based setup](synapse/workers), because
changing the architecture from monolithic to worker-based once the server is
already in use, is a tricky task.

Here's a ballpark figure. Remember, your mileage will probably vary.

|  Scenario                             | Architecture                    | CPU    | RAM    | Diskspace (GB) |
| :------------------------------------ | :-----------------------------: | :----: | :----: | :------------: |
| Personal, not many very busy rooms    | [monolithic](synapse)           | 2      | 8GB    | 50             |
| Private, users join very busy rooms   | [worker-based](synapse/workers) | 4      | 16GB   | 100            |
| Public, many users in very busy rooms | [worker-based](synapse/workers) | 8      | 32GB   | 250            |


# DNS and certificates

You'll need to configure several things in DNS, and you're going to need a
couple of TLS-certificates. Best to configure those DNS entries first, so that
you can quickly generate the certificates once you're there.

It's usually a good idea to keep the TTL of all these records very low while
installing and configuring, so that you can quickly change records without
having to wait for the TTL to expire. Setting a TTL of 300 (5 minutes) should
be fine. Once everything is in place and working, you should probably increase
it to a more production ready value, like 3600 (1 hour) or more.

What do you need? Well, first of all you need a domain. In this documentation
we'll use `example.com`, you'll need to substitute that with your own domain.

Under the top of that domain, you'll need to host 2 files under
`/.well-known`, so you'll need a webserver there, using a valid
TLS-certificate. This doesn't have to be the same machine as the one you're
installing Synapse on. In fact, it usually isn't.

Assuming you're hosting Matrix on the machine `matrix.example.com`, you need
at least an `A` record in DNS, and -if you have IPv6 support, which you
should- an `AAAA` record too. **YOU CAN NOT USE A CNAME FOR THIS RECORD!**
You'll need a valid TLS-certificate for `matrix.example.com` too.

You'll probably want the webclient too, so that users aren't forced to use an
app on their phone or install the desktop client on their PC. You should never
run the web client on the same name as the server, that opens you up for all
kinds of Cross-Site-Scripting attack. We'll assume you use
`element.example.com` for the web client. You need a DNS entry for that. This
can be a CNAME, but make sure you have a TLS-certificate with the correct name
on it.

If you install a [TURN-server](coturn), either for legacy calls or for [Element
Call](element-call) (or both), you need a DNS entry for that too, and -again- a
TLS-certificate. We'll use `turn.example.com` for this.

If you install Element Call (and why shouldn't you?), you need a DNS entry plus
certificate for that, let's assume you use `call.example.com` for that. This
can be a CNAME again. Element Call uses [LiveKit](element-call#livekit) for the
actual processing of audio and video, and that needs its own DNS entry and certificate
too. We'll use `livekit.example.com`.

| FQDN                  | Use                    | Comment                           |
| :-------------------- | :--------------------- | :-------------------------------- |
| `example.com`         | Hosting `.well-known`  |                                   |
| `matrix.example.com`  | Synapse server         | Can't be `CNAME`                  |
| `element.example.com` | Webclient              |                                   |
| `turn.example.com`    | TURN / Element Call    | Highly recommended                |
| `call.example.com`    | Element Call           | Optional                          |
| `livekit.example.com` | LiveKit SFU            | Optional, needed for Element Call |