forked from Fediversity/Fediversity
Expanded the checklist, added tables for easier viewing.
This commit is contained in:
parent
56c3fc13b4
commit
19dc889db6
|
@ -17,7 +17,9 @@ server with users who don't engage in busy rooms like
|
|||
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.
|
||||
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.
|
||||
|
@ -30,6 +32,14 @@ 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
|
||||
|
||||
|
@ -53,7 +63,7 @@ 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!**
|
||||
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
|
||||
|
@ -73,3 +83,12 @@ 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 |
|
||||
|
|
Loading…
Reference in a new issue