mirror of
https://github.com/matrix-org/dendrite.git
synced 2024-11-23 06:41:56 -06:00
146 lines
4.3 KiB
Markdown
146 lines
4.3 KiB
Markdown
|
---
|
||
|
title: Populate the configuration
|
||
|
parent: Installation
|
||
|
nav_order: 7
|
||
|
permalink: /installation/configuration
|
||
|
---
|
||
|
|
||
|
# Populate the configuration
|
||
|
|
||
|
The configuration file is used to configure Dendrite. A sample configuration file,
|
||
|
called [`dendrite-config.yaml`](https://github.com/matrix-org/dendrite/blob/main/dendrite-config.yaml),
|
||
|
is present in the top level of the Dendrite repository.
|
||
|
|
||
|
You will need to duplicate this file, calling it `dendrite.yaml` for example, and then
|
||
|
tailor it to your installation. At a minimum, you will need to populate the following
|
||
|
sections:
|
||
|
|
||
|
## Server name
|
||
|
|
||
|
First of all, you will need to configure the server name of your Matrix homeserver.
|
||
|
This must match the domain name that you have selected whilst [configuring the domain
|
||
|
name delegation](domainname).
|
||
|
|
||
|
In the `global` section, set the `server_name` to your delegated domain name:
|
||
|
|
||
|
```yaml
|
||
|
global:
|
||
|
# ...
|
||
|
server_name: example.com
|
||
|
```
|
||
|
|
||
|
## Server signing keys
|
||
|
|
||
|
Next, you should tell Dendrite where to find your [server signing keys](signingkeys).
|
||
|
|
||
|
In the `global` section, set the `private_key` to the path to your server signing key:
|
||
|
|
||
|
```yaml
|
||
|
global:
|
||
|
# ...
|
||
|
private_key: /path/to/matrix_key.pem
|
||
|
```
|
||
|
|
||
|
## JetStream configuration
|
||
|
|
||
|
Monolith deployments can use the built-in NATS Server rather than running a standalone
|
||
|
server. If you are building a polylith deployment, or you want to use a standalone NATS
|
||
|
Server anyway, you can also configure that too.
|
||
|
|
||
|
### Built-in NATS Server (monolith only)
|
||
|
|
||
|
In the `global` section, under the `jetstream` key, ensure that no server addresses are
|
||
|
configured and set a `storage_path` to a persistent folder on the filesystem:
|
||
|
|
||
|
```yaml
|
||
|
global:
|
||
|
# ...
|
||
|
jetstream:
|
||
|
in_memory: false
|
||
|
storage_path: /path/to/storage/folder
|
||
|
topic_prefix: Dendrite
|
||
|
```
|
||
|
|
||
|
### Standalone NATS Server (monolith and polylith)
|
||
|
|
||
|
To use a standalone NATS Server instance, you will need to configure `addresses` field
|
||
|
to point to the port that your NATS Server is listening on:
|
||
|
|
||
|
```yaml
|
||
|
global:
|
||
|
# ...
|
||
|
jetstream:
|
||
|
addresses:
|
||
|
- localhost:4222
|
||
|
topic_prefix: Dendrite
|
||
|
```
|
||
|
|
||
|
You do not need to configure the `storage_path` when using a standalone NATS Server instance.
|
||
|
In the case that you are connecting to a multi-node NATS cluster, you can configure more than
|
||
|
one address in the `addresses` field.
|
||
|
|
||
|
## Database connections
|
||
|
|
||
|
Configuring database connections varies based on the [database configuration](database)
|
||
|
that you chose.
|
||
|
|
||
|
### Global connection pool (monolith with a single PostgreSQL database only)
|
||
|
|
||
|
If you are running a monolith deployment and want to use a single connection pool to a
|
||
|
single PostgreSQL database, then you must uncomment and configure the `database` section
|
||
|
within the `global` section:
|
||
|
|
||
|
```yaml
|
||
|
global:
|
||
|
# ...
|
||
|
database:
|
||
|
connection_string: postgres://user:pass@hostname/database?sslmode=disable
|
||
|
max_open_conns: 100
|
||
|
max_idle_conns: 5
|
||
|
conn_max_lifetime: -1
|
||
|
```
|
||
|
|
||
|
**You must then remove or comment out** the `database` sections from other areas of the
|
||
|
configuration file, e.g. under the `app_service_api`, `federation_api`, `key_server`,
|
||
|
`media_api`, `mscs`, `room_server`, `sync_api` and `user_api` blocks, otherwise these will
|
||
|
override the `global` database configuration.
|
||
|
|
||
|
### Per-component connections (all other configurations)
|
||
|
|
||
|
If you are building a polylith deployment, are using SQLite databases or separate PostgreSQL
|
||
|
databases per component, then you must instead configure the `database` sections under each
|
||
|
of the component blocks ,e.g. under the `app_service_api`, `federation_api`, `key_server`,
|
||
|
`media_api`, `mscs`, `room_server`, `sync_api` and `user_api` blocks.
|
||
|
|
||
|
For example, with PostgreSQL:
|
||
|
|
||
|
```yaml
|
||
|
room_server:
|
||
|
# ...
|
||
|
database:
|
||
|
connection_string: postgres://user:pass@hostname/dendrite_component?sslmode=disable
|
||
|
max_open_conns: 10
|
||
|
max_idle_conns: 2
|
||
|
conn_max_lifetime: -1
|
||
|
```
|
||
|
|
||
|
... or with SQLite:
|
||
|
|
||
|
```yaml
|
||
|
room_server:
|
||
|
# ...
|
||
|
database:
|
||
|
connection_string: file:roomserver.db
|
||
|
max_open_conns: 10
|
||
|
max_idle_conns: 2
|
||
|
conn_max_lifetime: -1
|
||
|
```
|
||
|
|
||
|
## Other sections
|
||
|
|
||
|
There are other options which may be useful so review them all. In particular, if you are
|
||
|
trying to federate from your Dendrite instance into public rooms then configuring the
|
||
|
`key_perspectives` (like `matrix.org` in the sample) can help to improve reliability
|
||
|
considerably by allowing your homeserver to fetch public keys for dead homeservers from
|
||
|
another living server.
|