forked from fediversity/fediversity
		
	Expanded the checklist, added tables for easier viewing.
This commit is contained in:
		
							parent
							
								
									56c3fc13b4
								
							
						
					
					
						commit
						19dc889db6
					
				
					 1 changed files with 21 additions and 2 deletions
				
			
		|  | @ -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…
	
	Add table
		
		Reference in a new issue
	
	 Hans van Zijst
						Hans van Zijst