Dendrite can be run in one of two configurations:
Polylith mode: A cluster of individual components, dealing with different aspects of the Matrix protocol (see WIRING.md). Components communicate with each other using internal HTTP APIs and Apache Kafka. This will almost certainly be the preferred model for large-scale deployments.
Monolith mode: All components run in the same process. In this mode, Kafka is completely optional and can instead be replaced with an in-process lightweight implementation called Naffka. This will usually be the preferred model for low-volume, low-user or experimental deployments.
For most deployments, it is recommended to run in monolith mode with PostgreSQL databases.
Regardless of whether you are running in polylith or monolith mode, each Dendrite component that requires storage has its own database. Both Postgres and SQLite are supported and can be mixed-and-matched across components as needed in the configuration file.
Be advised that Dendrite is still in development and it's not recommended for use in production environments just yet!
If you want to run a polylith deployment, you also need:
Please note that Kafka is not required for a monolith deployment.
Start by cloning the code:
git clone https://github.com/matrix-org/dendrite cd dendrite
Then build it:
Install and start Kafka (c.f. scripts/install-local-kafka.sh):
KAFKA_URL=http://archive.apache.org/dist/kafka/2.1.0/kafka_2.11-2.1.0.tgz # Only download the kafka if it isn't already downloaded. test -f kafka.tgz || wget $KAFKA_URL -O kafka.tgz # Unpack the kafka over the top of any existing installation mkdir -p kafka && tar xzf kafka.tgz -C kafka --strip-components 1 # Start the zookeeper running in the background. # By default the zookeeper listens on localhost:2181 kafka/bin/zookeeper-server-start.sh -daemon kafka/config/zookeeper.properties # Start the kafka server running in the background. # By default the kafka listens on localhost:9092 kafka/bin/kafka-server-start.sh -daemon kafka/config/server.properties
On macOS, you can use Homebrew for easier setup of Kafka:
brew install kafka brew services start zookeeper brew services start kafka
Assuming that PostgreSQL 9.6 (or later) is installed:
Create role, choosing a new password when prompted:
sudo -u postgres createuser -P dendrite
At this point you have a choice on whether to run all of the Dendrite components from a single database, or for each component to have its own database. For most deployments, running from a single database will be sufficient, although you may wish to separate them if you plan to split out the databases across multiple machines in the future.
On macOS, omit
sudo -u postgres from the below commands.
If you want to run all Dendrite components from a single database:
sudo -u postgres createdb -O dendrite dendrite
... in which case your connection string will look like
If you want to run each Dendrite component with its own database:
for i in mediaapi syncapi roomserver signingkeyserver federationsender appservice keyserver userapi_accounts userapi_devices naffka; do sudo -u postgres createdb -O dendrite dendrite_$i done
... in which case your connection string will look like
WARNING: SQLite is suitable for small experimental deployments only and should not be used in production - use PostgreSQL instead for any user-facing federating installation!
Dendrite can use the built-in SQLite database engine for small setups. The SQLite databases do not need to be pre-built - Dendrite will create them automatically at startup.
Each Dendrite installation requires:
To generate a Matrix signing private key:
./bin/generate-keys --private-key matrix_key.pem
WARNING: Make sure take a safe backup of this key! You will likely need it if you want to reinstall Dendrite, or any other Matrix homeserver, on the same domain name in the future. If you lose this key, you may have trouble joining federated rooms.
For testing, you can generate a self-signed certificate and key, although this will not work for public federation:
./bin/generate-keys --tls-cert server.crt --tls-key server.key
If you have server keys from an older Synapse instance,
convert them to Dendrite's PEM
format and configure them as
old_private_keys in your config.
Create config file, based on
dendrite-config.yaml. Call it
dendrite.yaml. Things that will need editing include at least:
server_nameentry to reflect the hostname of your Dendrite server
databaselines with an updated connection string based on your desired setup, e.g. replacing
databasewith the name of the database:
postgres://dendrite:password@localhost/dendrite_userapi_accountto connect to PostgreSQL with SSL/TLS
postgres://dendrite:password@localhost/dendrite_userapi_account?sslmode=disableto connect to PostgreSQL without SSL/TLS
use_naffkaoption if using Naffka in a monolith deployment
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
matrix.org in the sample) can
help to improve reliability considerably by allowing your homeserver to fetch
public keys for dead homeservers from somewhere else.
WARNING: Dendrite supports running all components from the same database in PostgreSQL mode, but this is NOT a supported configuration with SQLite. When using SQLite, all components MUST use their own database file.
It is possible to use Naffka as an in-process replacement to Kafka when using
the monolith server. To do this, set
use_naffka: true in your
configuration and uncomment the relevant Naffka line in the
Be sure to update the database username and password if needed.
The monolith server can be started as shown below. By default it listens for
HTTP connections on port 8008, so you can configure your Matrix client to use
http://servername:8008 as the server:
If you set
--tls-key as shown below, it will also listen
for HTTPS connections on port 8448:
./bin/dendrite-monolith-server --tls-cert=server.crt --tls-key=server.key
The following contains scripts which will run all the required processes in order to point a Matrix client at Dendrite.
This is what your clients and federated hosts will talk to. It must forward requests onto the correct API server based on URL:
/_matrix/clientto the client API server
/_matrix/federationto the federation API server
/_matrix/keyto the federation API server
/_matrix/mediato the media API server
docs/nginx/polylith-sample.conf for a sample configuration.
This is what implements CS API endpoints. Clients talk to this via the proxy in order to send messages, create and join rooms, etc.
./bin/dendrite-polylith-multi --config=dendrite.yaml clientapi
This is what implements
/sync requests. Clients talk to this via the proxy
in order to receive messages.
./bin/dendrite-polylith-multi --config=dendrite.yaml syncapi
/media requests. Clients talk to this via the proxy in
order to upload and retrieve media.
./bin/dendrite-polylith-multi --config=dendrite.yaml mediaapi
This implements the federation API. Servers talk to this via the proxy in order to send transactions. This is only required if you want to support federation.
./bin/dendrite-polylith-multi --config=dendrite.yaml federationapi
This refers to components that are not directly spoken to by clients. They are only contacted by other components. This includes the following components.
This is what implements the room DAG. Clients do not talk to this.
./bin/dendrite-polylith-multi --config=dendrite.yaml roomserver
This sends events from our users to other servers. This is only required if you want to support federation.
./bin/dendrite-polylith-multi --config=dendrite.yaml federationsender
This sends events from the network to application services running locally. This is only required if you want to support running application services on your homeserver.
./bin/dendrite-polylith-multi --config=dendrite.yaml appservice
This manages end-to-end encryption keys for users.
./bin/dendrite-polylith-multi --config=dendrite.yaml keyserver
This manages signing keys for servers.
./bin/dendrite-polylith-multi --config=dendrite.yaml signingkeyserver
This manages processing EDUs such as typing, send-to-device events and presence. Clients do not talk to
./bin/dendrite-polylith-multi --config=dendrite.yaml eduserver
This manages user accounts, device access tokens and user account data, amongst other things.
./bin/dendrite-polylith-multi --config=dendrite.yaml userapi