Dendrite is a Go Matrix homeserver that has moved into maintenance mode

What maintenance mode means for an operator

The status line in the README is the first thing to read and it changes the evaluation entirely. Dendrite is in maintenance mode, which means only security fixes are being applied, with room version 12 given as an example. That is a different commitment from the one a homeserver operator usually needs, because a Matrix server accumulates clients, room state and federation traffic over years, and a server that receives only security fixes will not gain the protocol features its users ask for. The stated intent is still to provide an efficient and reliable alternative to Synapse, and the two claims are specific. Efficient means a small memory footprint with better baseline performance than an out-of-the-box Synapse. Reliable means the Matrix specification is implemented as written, using the same test suites as Synapse, namely Sytest and Complement. The project also says plainly what beta software is not, listing that it is not bug-free, not feature-complete, and not ready for massive deployments.

Specification conformance is measured, not asserted

The interesting engineering artefact in this repository is the conformance tracking. Dendrite ships a file called are-we-synapse-yet.list together with a Python script of the same name, and the label of that name is used on issues that describe behaviour Synapse has and Dendrite does not. The documentation asks contributors to look at issues with that label, notes that each one has a related Sytest that has to pass before the issue can be closed, and explains that a contributor can run Sytest locally to see whether their change turns the relevant test names green. There is also a run-sytest.sh script, a sytest-whitelist, a sytest-blacklist and a show-expected-fail-tests.sh helper for the tests that are known to fail. This is the difference between claiming specification compliance and demonstrating it. A homeserver that is merely compatible with a client is easy; passing the same suites as the reference implementation is a much stronger statement, and the machinery in this repository exists to keep that statement honest as the code changes.

A test deployment in six commands

The getting started section is deliberately modest, because it targets a non-federating test deployment with self-signed certificates and SQLite databases rather than a production server. You need Go 1.21 or later to build. The first half clones, builds every command and generates the keys:

$ git clone https://github.com/element-hq/dendrite
$ cd dendrite
$ go build -o bin/ ./cmd/...

# Generate a Matrix signing key for federation (required)
$ ./bin/generate-keys --private-key matrix_key.pem

# Generate a self-signed certificate (optional, but a valid TLS certificate is normally
# needed for Matrix federation/clients to work properly!)
$ ./bin/generate-keys --tls-cert server.crt --tls-key server.key

The second half copies the sample configuration, starts the server and creates an account:

# Copy and modify the config file - you'll need to set a server name and paths to the keys
# at the very least, along with setting up the database connection strings.
$ cp dendrite-sample.yaml dendrite.yaml

# Build and run the server:
$ ./bin/dendrite --tls-cert server.crt --tls-key server.key --config dendrite.yaml

# Create an user account (add -admin for an admin user).
# Specify the localpart only, e.g. 'alice' for '@alice:domain.com'
$ ./bin/create-account --config dendrite.yaml --username alice

When it is up, a client can be pointed at http://localhost:8008 or https://localhost:8448. The sample config file in the repository root is the thing to edit, and the comment is honest that you at least need a server name, the key paths and the database connection strings.

Federation adds four requirements you cannot skip

The gap between the test deployment above and a real one is federation, and the documentation lists what a usable federating deployment needs. You need a domain name or subdomain, a valid TLS certificate issued by a trusted authority for that domain, and either SRV records or a well-known file pointing at your deployment. Those three are not optional conveniences, they are how other servers find and trust yours. Two further recommendations follow. A PostgreSQL database engine is recommended, since it performs better than SQLite with many users or larger rooms, and the project says outright that PostgreSQL is recommended for anyone running Dendrite. A reverse proxy server such as nginx is also recommended, and the repository ships a sample configuration for it under docs/nginx. Once the deployment is up, the Federation Tester is the tool named for verifying it. For operators who want the detail, the Installation documentation and a Planning your Installation page cover requirements, and a Dockerfile is available for containerised runs.

The image ships four binaries and two ports

The container build is a multi-stage Dockerfile that starts from a golang alpine base and adds bash, build-base, curl and git. Cross compilation is handled carefully, with the target architecture and operating system set for the build stage and CGO enabled only when the target architecture matches the build host, since the SQLite driver needs cgo. The final image is alpine with curl added, and it copies four binaries out of the build stage rather than the whole tree:

COPY --from=build /out/create-account /usr/bin/create-account
COPY --from=build /out/generate-config /usr/bin/generate-config
COPY --from=build /out/generate-keys /usr/bin/generate-keys
COPY --from=build /out/dendrite /usr/bin/dendrite

VOLUME /etc/dendrite
WORKDIR /etc/dendrite

ENTRYPOINT ["/usr/bin/dendrite"]
EXPOSE 8008 8448

The two exposed ports are the client facing HTTP port and the TLS port, which matches the URLs in the getting started section. The volume and working directory both point at /etc/dendrite, so configuration and the database live in one mounted place. The image also carries the Open Container Initiative labels, including the licence string that reflects the dual licensing arrangement and the documentation URL that points at the project site. The repository also carries a helm/ directory at the top level.

AGPL-3.0 or a paid commercial licence

Licensing is the one place where a deployment decision has legal weight, so it is worth reading exactly. The project states that it is dual-licensed by New Vector Ltd, which is Element. It can be used for free under the terms of the GNU Affero General Public License, either version 3 or, at your option, any later version, or under the terms of a paid-for Element Commercial License agreement whose terms may vary depending on what you and Element have agreed. The copyright holders are listed as OpenMarket Ltd and Vector Creations Ltd for 2017 and New Vector Ltd for 2017 to 2025. The AGPL matters in a specific way for a homeserver, because the network use provision means that offering the software as a service to users over a network brings the source obligations with it. A self-hosted instance for a community or a small group is the straightforward case, and an organisation that wants to run Dendrite as a service to paying users should look at the commercial route. This is a licensing question to settle with your own counsel, not a technical one the project answers.

Where Dendrite fits, and where it does not

The scope statement is precise about the intended deployment sizes. Dendrite is expected to function well for small homeserver deployments with tens or hundreds of users, and equally for peer to peer Matrix nodes running in a browser or on a mobile device. That second case is one a conventional homeserver deployment cannot cover, since a browser cannot host a full server process. The exclusions are equally precise. There is no high availability or clustering support, and the project says so directly, so Dendrite is not a candidate for a large production deployment. There may be client or federation APIs that are not implemented, and two specific gaps are named. MSC4186, simplified sliding sync, and MSC3861, next generation auth OIDC, are not supported, and the documentation states that this impacts the ability to use Element X with Dendrite servers. That is the practical line to check, because Element X depends on these proposals, and sliding sync is what makes it pleasant on a large room. Schema upgrades between releases are supported, and the project says you should never lose messages when upgrading, which is the operational guarantee that matters most for a homeserver.

Editorial conclusion

Dendrite fits an administrator who wants a Matrix homeserver small enough to run on modest hardware, or a browser or mobile client that needs a peer to peer node rather than a full server, and the SQLite plus self-signed certificate path is enough to try it in an afternoon. It does not fit a service that needs clustered high availability, since there is no such support, and it does not fit a deployment that has to serve Element X, because the sliding sync and next generation OIDC proposals are unimplemented. Before you commit, read the FAQ in docs/FAQ.md and the planning page, confirm the clients you need work against it, and check the licensing route, because New Vector Ltd distributes it under AGPL-3.0 or a paid commercial agreement, and the last push was on 2026-09-17 while the newest tagged release, 0.15.2, is dated 2025-08-15.

Frequently asked questions

Official sources

1. element-hq/dendrite on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases