Ninety-six days ago this site ranked the Matrix homeserver landscape for the deployments we actually build: a fire hall, a town office, a small organization. The conclusion then was: Continuwuity is the practical option at community scale — with the honest gap that nothing in the FOSS landscape gives you a well-worn answer for a homeserver that must not have a single point of failure. Synapse high availability exists but demands worker deployments and tuning; the supported multi-node story is Element's commercial product. We wrote the gap down as a gap and moved on.

That gap just got a candidate. It needs scrutiny, not celebration, and it got the scrutiny first.

What happened

On October 2, Zendrite v3.4.0 shipped. Zendrite is an opinionated fork of element-hq/dendrite rebranded from Dendrite in February by its maintainer — the same Go codebase lineage Element confirmed this week is still in maintenance mode, meaning security fixes only. The fork is not in maintenance mode. Its headline feature set in v3.4.0 is opt-in active-passive high availability, built like this:

  • Election, not consensus-in-process. Multiple Zendrite candidates run against shared PostgreSQL, shared NATS JetStream, and shared S3-compatible media storage. A Kubernetes Lease elects exactly one candidate to serve; the others wait as standbys. One writer at a time, by election.
  • Fencing at every durable boundary. A durable ownership generation is enforced at the database, the broker, media storage, outbound federation, and request admission — so a paused or partitioned old leader cannot write after its successor takes over. This is the part most DIY HA gets wrong: it is not enough to elect a new leader; the old leader must be unable to do damage when it wakes up confused.
  • Rolling upgrades between compatible builds hand over without failed client requests, and an upgrade contract refuses builds that would need offline migration — version skew between leader and standby is rejected rather than guessed at.
  • The HA claims are qualified by a fault-injection harness in CI that runs against real PostgreSQL, a three-node JetStream cluster, a kube-apiserver, and a federating peer. It kills leaders, freezes them, partitions them, fails over the database, loses brokers — and asserts no acknowledged write, to-device message, or receipt goes missing. The repo's recent commits show this harness actively catching real failure modes (a broker restart leaving a lagging replica caught by CI within a day of the fix landing).

Separately, v3.4.0 also carries federation work (MSC4311 and knocking implemented) and a large-room sync fix — a state update in a room of 50,000 members went from minutes to seconds — plus dozens of reliability fixes: federation transactions now retry instead of silently dropping receipts, a silent NATS broker is detected in about thirty seconds, and stalled consumers became visible in metrics. The fork is closing the gaps that made Dendrite a hard sell, not just bolting on HA.

The honest framing

Read the release notes with the skepticism the site's own rules require:

  • One maintainer. Patrick Schratz is the name on the releases, and the project is small — a dozen watchers and forks. Every feature claim above is real and verifiable in the commit log, but the bus factor is one. This is the same failure mode this site has written about twice — archived maintainer-less software and projects that died with their maintainer's clock — and the answer is the same: the code is AGPL-3.0 (verified in the v3.4.0 tree), so the fork can be forked. The repository also carries a LICENSE-COMMERCIAL file inherited from Element's dual-licensing structure; if you need commercial terms, the conversation is with this fork's maintainer, not Element.

  • The HA it ships is the election, fencing, and handover. The HA of PostgreSQL, JetStream, and S3 underneath is still yours to run. If your Postgres dies, the Lease cannot save you — nothing can, that is what Postgres failover is for. Zendrite's contribution is that the homeserver layer now rides those failures cleanly instead of being the fragile part. At community scale, that is exactly the layer where the fragility actually lived.

  • It is opt-in and new. Active-passive means one server serving at a time — not horizontally scaled throughput, and not a claim that v3.4.0 has production years behind it. The fault-injection evidence is good. It is not a substitute for doing your own kill tests before you put a community's chat history on it.

What to actually do

If you run plain Dendrite and accepted the maintenance-mode risk when the July landscape post came out: reassess. Zendrite is a fork of the thing you are running, a migration path exists and is tested in its CI, and upstream's confirmed posture is security-fixes-only. Planning a cutover to an actively developed fork is a calendar task now, not an emergency.

If you need HA on FOSS terms and have been waiting: a candidate now exists to pilot. Pilot it the way this site pilots anything: verify the fence yourself — kill the leader mid-write, fail Postgres, freeze the broker — and hold it at pilot stage until the project proves it can outlive its maintainer. Do not put a community's primary chat server on day-new HA software.

If you run Continuwuity on minimal hardware and never needed HA: nothing changes. That was and remains the right pick for the fire hall. Continuwuity holds about one in eleven of the homeservers MatrixRooms.info discovered this week — it is not going anywhere.

Everywhere — the federation interop clock that matters: in the same week, Synapse 1.162.0 (September 29) did two things. It raised the default room version to 12 for newly created rooms — existing rooms keep the version they were created with, so this only reaches your new rooms — and it fixed Synapse's flawed MSC4311 implementation from August 2025: invites and knocks now carry full PDUs federation-side, where clients were reading stripped state. Continuwuity has been strictly validating that format since v26.6.1, which created real invite/knock breakage between Synapse and Continuwuity fleets. Synapse applies strict validation of incoming invites/knocks only after 2027-06-01 to give the ecosystem time to adapt. If you run a mixed Matrix fleet, upgrade Synapse and test federated invites and knocks between your implementations now; June is further away than it feels.

Closing

The July landscape post's one missing rung was high availability on FOSS terms, without a proprietary license or a worker farm. A one-maintainer fork shipped a serious candidate for that rung and qualified it with a harness most commercial products do not have — and at community scale, that is exactly the layer where the fragility actually lived. Scrutiny it earned: bus factor one, boundaries honestly drawn, license verified. That is the same standard this site holds everything to, including the proprietary answers waiting to sell you the whole stack.

Sources: Zendrite v3.4.0 release notes; Zendrite repository; Zendrite HA documentation; TWIM 2026-10-02, Dept of Servers; Synapse 1.162.0 changelog; element-hq/dendrite README — maintenance mode; MatrixRooms.info federation stats.