When we deploy Matrix for a community — a fire hall, a town office, a small organization — the homeserver choice matters more than the client. Element, SchildiChat, FluffyChat, Cinny — they're all fine. They connect to whatever homeserver you point them at. The homeserver is what you operate, what holds your data, and what determines your resource footprint.
That landscape changed quietly over the last year. If you're planning a deployment, you need to know where things stand.
What Happened
Synapse — the original Matrix homeserver, written in Python by the Matrix core team — is in maintenance mode. Element (the company) maintains it on a best-effort basis. Security patches and protocol compatibility updates continue, but no new features are in the roadmap. The Matrix Foundation no longer allocates resources to it. For years this was the default choice. It works. It's battle-tested. It's also a Python application that expects real resources — 1-2 GB RAM minimum for a small deployment, more under load.
Dendrite — the second-generation homeserver written in Go — is also in maintenance mode. Same story: Element maintains it best-effort, no active feature development. It was supposed to be the successor to Synapse. Architecture is cleaner, resource usage is lower, but development paused when funding contracted. The Matrix Foundation's November 2023 blog post explained the situation: core team next-gen projects paused due to funding constraints. Dendrite development slowed as a result and never fully resumed.
Conduit — the Rust homeserver that predates conduwuit — was archived. Development stalled, the repository went read-only. The community didn't let it die.
What to Run Now
Continuwuity is the community-driven continuation of conduwuit, which was itself a fork of Conduit. Written in Rust. Actively developed. The latest version, v26.6.0, shipped July 17, 2026.
Here's why this is the homeserver to deploy for community infrastructure:
Resource footprint. A typical instance serving 10-100 users runs on 64-256 MB RAM. That's not a typo. A community Matrix server that fits alongside other services on a single Proxmox container with 512 MB allocated. Synapse needs 4x that minimum and grows from there. For a fire hall running a Proxmox node with limited hardware, this is the difference between "we can do this" and "we need another machine."
Database options. SQLite for small deployments — zero additional database setup, no PostgreSQL to configure and maintain. PostgreSQL for larger deployments with concurrent access. For a 20-user community server, SQLite is fine. You don't need a database administrator.
Federation. Full federation support with efficient server-to-server communication. Your community's Matrix server talks to the wider Matrix network — matrix.org, other community servers, everything. Federation is the point. A standalone chat server is just a worse Slack. A federated one is part of a network nobody controls.
License. Apache-2.0, inherited from Conduit. Not AGPL, but permissive FOSS. You can run it, modify it, and distribute modifications. The community development happens on Forgejo (forgejo.ellis.link), not GitHub — which is itself a choice worth noting for a project that values community control.
Active development. v26.6.0 is a major release, not a patch. The changelog includes database size reductions (legacy sync logic changes that drop a shortstatehash column), breaking changes around LDAP authentication removal (they're moving to OIDC), and ongoing feature work. This is a project with momentum, not a maintenance shell.
The Trade-offs
Continuwuity is not Synapse. It doesn't have every feature Synapse accumulated over years. If your community needs SSO via LDAP, the v26.6.0 release removed that in favor of OIDC — you'd need to wire up an OIDC provider (Keycloak works). Some edge-case federation features may behave differently. The client-server API parity isn't 100% — check the CI badges if you need specific features.
For most community deployments — chat, federation, file sharing, maybe some bots — none of this matters. The features people actually use are supported and stable.
Why This Matters for Community Deployments
The Matrix homeserver landscape consolidating around a community-maintained Rust implementation is good news for sovereign infrastructure, and here's the specific reason:
When we deploy Matrix for a community, we're deploying infrastructure that community will operate after we leave. Synapse's Python stack — virtualenvs, pip dependencies, Twisted reactor, synapse worker processes — is manageable but has a learning curve. Continuwuity is a single binary with a config file. You can explain it to a volunteer sysadmin in an afternoon.
A homeserver that runs on 256 MB RAM, uses SQLite, ships as a single binary, and federates with the entire Matrix network is infrastructure a small community can actually own and operate. That's the bar. Synapse cleared it for organizations with dedicated IT staff. Continuwuity clears it for fire halls.
Deployment Notes
If you're deploying Continuwuity for a community:
- Use Docker. The official image is
continuwuity/continuwuity:latest. Mount a config volume and a data volume. Done. - Start with SQLite. Switch to PostgreSQL only if you see concurrent write contention (you won't, under 100 users).
- Put it behind a reverse proxy with TLS — Caddy or nginx. Federation requires HTTPS on port 8448.
- Wire up OIDC early if you want SSO. Keycloak is the natural choice if you're already deploying it for Nextcloud or other services.
- Take a Proxmox snapshot before upgrading. The v26.6.0 LDAP removal is the kind of breaking change that bites if you're not reading release notes.
The matrix-docker-ansible-deploy playbook supports Continuwuity if you prefer Ansible over manual Docker. It handles the reverse proxy, TLS, and federation configuration automatically.
The Broader Point
The Matrix ecosystem's homeserver development shifting from a corporate-funded team to a community-maintained project is not a decline. It's the trajectory FOSS projects follow when they matter. Synapse and Dendrite were built by paid developers. Continuwuity is built by people who use it. The code is smaller, the resource footprint is smaller, the deployment is simpler, and the development is responsive to actual operator needs rather than enterprise sales requirements.
For community infrastructure, this is the version of the project that's built for you.