# Continuwuity: a Rust Matrix homeserver forked from an archived one > Continuwuity is a community-driven Matrix homeserver written in Rust, picked up after the original conduwuit project was archived, with a stated goal of running on modest hardware. The database is compatible with conduwuit but no longer with Conduit, Grapevine, Dendrite or Synapse, so migration is a one-way door in practice. **continuwuity/continuwuity** — A community-driven Matrix homeserver - Repository: https://github.com/continuwuity/continuwuity - Website: https://continuwuity.org - Stars: 1,164 · Forks: 34 - Language: Rust - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/continuwuity-continuwuity ## The project exists because conduwuit was archived Continuwuity is described as a Matrix homeserver written in Rust and as the official community continuation of the conduwuit homeserver. The README explains why in a paragraph. The original conduwuit project has been archived and is no longer maintained, and rather than letting the Rust Matrix homeserver disappear, a group of community contributors forked it to continue development, fix outstanding issues and add new features. The stated aim is to provide a stable, well-maintained alternative for current conduwuit users, and to welcome newcomers seeking a lightweight, efficient Matrix homeserver. That origin explains both the audience and the caution in the project, since the people behind it are described as Matrix enthusiasts, developers and system administrators who used conduwuit, a mix of previous contributors to the original project and newcomers. ## The stated goals are modest hardware and spec compliance, not feature parity The project lists seven goals, and the wording is more disciplined than a typical roadmap. Maintain a stable, reliable Matrix homeserver implementation in Rust. Improve compatibility and specification compliance with the Matrix protocol. Fix bugs and performance issues from the original conduwuit. Add missing features needed by homeserver administrators. Provide comprehensive documentation and easy deployment options. Create a sustainable development model for long-term maintenance. And keep a lightweight, efficient codebase that can run on modest hardware. Read that last one as a design constraint rather than a boast, because it is the one that shapes every other decision. A homeserver that fits on modest hardware and speaks to the spec is a different goal from one that implements every administrative feature, and the project is explicit that it is pursuing the former. ## Database compatibility is the one migration question that matters The README has a section titled Can I migrate my data from X, and the answers are blunt. From conduwuit, yes. From Conduit, no, because the database is now incompatible. From Grapevine, no, the database is now incompatible. From Dendrite, no. From Synapse, no. Five lines, and they are the first thing an operator with an existing homeserver will look for. The reason is structural rather than incidental, since the fork continued the Rust codebase and its schema rather than designing a common one, and a schema that diverged from Conduit and Grapevine before the fork cannot be reunited afterwards. The README also notes that no guide has been written for migrating from the incompatible homeservers and invites people to get in touch, so an operator arriving from Synapse is starting from an export and an import rather than a conversion. ## Deployment is documented on the website, not in the repository For trying the project out, the README points at continuwuity.org and specifically at the deployment section, and the repository ships a conduwuit-example.toml as the sample configuration. That split is a deliberate signal about where the project has put its effort, since the documentation is a separate concern from the code and is versioned with it. The repository layout backs this up. The docs/ directory holds the documentation sources and the package.json shows it is built with Rspress, with scripts for docs:dev, docs:build and docs:preview, so the documentation is a site you can run locally, and there is an rspress.config.ts at the top level. There is also a docker/ directory, a default.nix and flake.nix with a flake.lock, and a nix/ directory, so container and Nix packaging are both available for a self-hosted deployment. ## The build is a Cargo workspace with a pinned toolchain and an xtask binary The Cargo.toml describes a workspace whose members are src/* and xtask/, with the src/ crates as the default members, in edition 2024 and with a version of 26.9.1 and the Apache-2.0 licence. The version numbering follows the calendar, matching the release tags v26.7.0, v26.7.1 and v26.7.2 all published on the same day in August, so the scheme is date based rather than semantic in the usual sense. A rust-toolchain.toml file pins the compiler, and rustfmt.toml and clippy.toml hold the formatting and lint configuration, with taplo.toml and toml formatting for the configuration files. The xtask/ member is the automation crate, the usual place for build and release chores, and release.toml and towncrier.toml sit at the top level alongside a changelog.d/ directory, which is the news fragment workflow rather than a hand edited changelog. ## Forges: the primary is Forgejo, with GitHub, GitLab and Codeberg as mirrors The README carries badges for four forges, and the distinction between them matters for anyone who wants to contribute. The Cargo.toml repository field points at a Forgejo instance on ellis.link, and the package.json repository field is an SSH URL to the same host, so Forgejo is the canonical source. GitHub, GitLab and Codeberg are labelled mirrors. The badge set also shows issue and pull request tracking on the Forgejo instance. There is a .forgejo/ directory at the top of the repository, and the Open Collective badge points at an opencollective.com/continuwuity page, which is the funding and governance surface for a project that describes itself as an open community project. The practical upshot for a contributor is that the mirror layout is there to make the code reachable, but a patch should go to the primary forge. ## Protocol conformance is tested against the Matrix complement suite The complement/ directory at the top of the repository is the most telling directory name in the list. The Matrix specification has a reference test suite, and a homeserver that claims specification compliance has to pass it, so a complement directory in a homeserver repository means conformance is checked automatically rather than asserted. The other test-related paths are tests/ and a development.md, and the repository carries a pre-commit config, a typos configuration for spell checking, a markdownlint ignore file, a git-blame-ignore-revs file, and a renovate configuration for dependency updates. There is a SECURITY.md and a CODE_OF_CONDUCT.md, plus a CONTRIBUTING.md and a separate docs/ site, which together describe a project with an unusual amount of process for a homeserver of its size. ## Upkeep, licensing and the three-try-it options The last push to the repository was on 2026-10-19, and the most recent listed releases are v26.7.0, v26.7.1 and v26.7.2, all dated 2026-08-07, with the workspace version at 26.9.1 in the manifest, which tells you development continues past the last published tag. The licence is Apache-2.0, which is permissive and carries no copyleft obligation for a deployment, though a fork that redistributes remains subject to it. For evaluation without running anything, the README offers two ways in. Two partnered homeservers are listed, federated.nexus where you apply to join and receive a username and password by email, and continuwuity.rocks where you can register directly through Cinny or another client that supports registration. That last detail is a compatibility signal, since not every Matrix client can complete a registration flow against a given homeserver. ## Conclusion Continuwuity suits a homeserver administrator who already ran conduwuit and wants a maintained Rust implementation, or who wants a lightweight Matrix server for a small community and is willing to accept a database that only interconverts with the conduwuit lineage. It is the wrong choice if you are moving from Synapse, Dendrite, Conduit or Grapevine, because the README states those databases are now incompatible, and it is a poor fit if you need the full breadth of a mature homeserver's administration features. Before adopting it, read the deployment section on continuwuity.org, check that the database you already have is one of the compatible ones, and note that the project moved its primary forge to Forgejo with GitHub, GitLab and Codeberg kept as mirrors, so a fork and a pull request should target the right host. ## FAQ ### What is Continuwuity and how is it related to conduwuit? Continuwuity is a Matrix homeserver written in Rust and is the official community continuation of the conduwuit homeserver. The original conduwuit project was archived and is no longer maintained, so community contributors forked it to continue development, fix outstanding issues and add new features. ### Can I migrate my existing Matrix homeserver to Continuwuity? The README states that migration from conduwuit is possible, and that from Conduit, Grapevine, Dendrite and Synapse it is not, because the database is now incompatible. No guide has been written for the incompatible cases, and the project asks you to get in touch if you need one. ### What hardware does Continuwuity need? The project lists keeping a lightweight, efficient codebase that can run on modest hardware among its goals, and describes itself as a lightweight, efficient Matrix homeserver. The README does not give specific hardware requirements or a resource footprint, and the deployment section on continuwuity.org is the place to look for those. ### Where should I send a pull request for Continuwuity? The primary forge is a Forgejo instance on ellis.link, which is the repository URL recorded in the Cargo manifest and the package.json. GitHub, GitLab and Codeberg are kept as mirrors, and issue and pull request tracking happens on the Forgejo instance. ### How is the Continuwuity documentation built and where is configuration documented? The documentation lives in the docs/ directory and is built with Rspress, with scripts for docs:dev, docs:build and docs:preview in the package.json. The deployment instructions are on continuwuity.org, and the repository ships a conduwuit-example.toml as the sample configuration file. ## Sources - [continuwuity/continuwuity on GitHub](https://github.com/continuwuity/continuwuity) - [License: Apache-2.0](https://github.com/continuwuity/continuwuity/blob/main/LICENSE) - [Project website](https://continuwuity.org) - [README](https://github.com/continuwuity/continuwuity/blob/main/README.md) - [Releases](https://github.com/continuwuity/continuwuity/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/continuwuity-continuwuity