Fluxer: a self-hostable chat and VoIP app with a Cassandra and Rust service backend

What Fluxer is, and who the repository is written for

Fluxer is described in its README as "a free and open source instant messaging and VoIP chat app built for friends, groups, and communities." That sentence is the whole of the README's product explanation, so anyone evaluating it has to read the repository layout instead. The layout answers the question: fluxer_api, fluxer_gateway, fluxer_messages, fluxer_users, fluxer_media_proxy, fluxer_app_proxy, fluxer_admin, fluxer_unfurl, fluxer_recon and fluxer_snowflakes are separate service directories, most of them listed as workspace members in Cargo.toml. A chat product split this way is aimed at operators, not at end users looking for a download. The homepage points to docs.fluxer.app/operator/get-started/, which confirms the intended reader is someone deploying an instance.

The audience is therefore a team or an individual who wants to run community chat and voice on their own infrastructure and is willing to operate a multi-service backend. The project also ships a desktop client (fluxer_desktop) and a web app (fluxer_app), so the same repository covers clients and server. If you want a hosted account on someone else's servers, nothing in the repository describes that path.

The architecture: Rust services behind a TypeScript monorepo

Fluxer is a pnpm workspace with a Cargo workspace inside it. Cargo.toml declares edition 2024 and lists the Rust services, including fluxer_admin, fluxer_app_proxy, fluxer_common, fluxer_media_proxy, fluxer_gifs, fluxer_svc, fluxer_messages, fluxer_snowflakes, fluxer_users, fluxer_unfurl and fluxer_recon, plus two tool crates (tools/dev and tools/ci) and a markdown parser under packages/markdown_parser/rust. The release profile sets lto = "fat", codegen-units = 1 and strip = "symbols", which is a build tuned for shipping binaries rather than for fast iteration.

The root package.json is the control surface. Almost every script shells out to cargo run -p fluxer-dev, a Rust developer tool that wraps build, dev, bootstrap, infrastructure, Cassandra and desktop tasks. That is an unusual choice for a TypeScript-first repository, and it means the day-to-day workflow depends on compiling the dev tool before you can start services. The TypeScript side is not decorative: the i18n scripts run pnpm --filter fluxer_app and pnpm --filter @fluxer/i18n targets, and the docs build through pnpm --filter fluxer_docs. So the split is roughly Rust for backend services and developer tooling, TypeScript for the application, internationalisation and documentation.

One naming detail is worth flagging. The script dev:cassandra:apply and the related diff and verify commands imply Cassandra schema management is part of the developer loop, and the project publishes a fluxer-app-proxy-self-hosted release alongside fluxer-app-proxy. The repository does not explain in the README what distinguishes the self-hosted proxy build from the standard one, so an operator should expect to resolve that from the operator docs rather than the code listing.

Installing Fluxer from the repository and starting the stack

The repository does not document a download or an installer. It documents a developer and operator workflow driven by pnpm and Cargo, so the first step is a checkout plus the two package managers. The root package.json defines dev:bootstrap, which is the closest thing to a first-run setup command.

pnpm install
pnpm dev:bootstrap

After bootstrap, the infrastructure scripts start and stop the backing services that the Rust components expect. Status is a separate command, which is useful because the start and stop scripts are thin wrappers around the same Rust dev tool.

pnpm dev:infra:start
pnpm dev:infra:status

Cassandra schema work is exposed as three commands. Apply is the one that runs migrations; diff and verify are the inspection commands you would use before applying anything to data you care about.

dev:cassandra:diff
pnpm dev:cassandra:apply
pnpm dev:cassandra:verify

The full development run is a single script, and there is a variant that opens a Cloudflare tunnel if you need the instance reachable from outside your machine.

pnpm dev
pnpm dev:tunnel

For the desktop client, the repository exposes build, run, install and package as separate steps rather than one command, so you can run from source without producing an installer.

pnpm dev:desktop:build
pnpm dev:desktop:run

What you should see is infrastructure coming up under dev:infra:status, migrations applying cleanly, and the dev process serving the app. The README itself gives none of these steps; they come from the script names in package.json, so treat the operator get-started page as the authoritative sequence.

Where Fluxer is the wrong tool

The clearest limitation is client distribution. The related searches include how to install Fluxer on Android, and the repository contains no Android project. The top-level entries include fluxer_desktop and fluxer_app but nothing mobile, and the desktop scripts cover build, install, canary, package and run. If your users are on phones, the repository as listed does not give you a path for them, and the README does not address mobile at all.

The second limitation is operational weight. A deployment with a gateway service, a message service, a user service, media and app proxies, an admin service and Cassandra schema migrations is not a single binary you drop on a small VPS. The Cargo profile is tuned for release artefacts (fat LTO, one codegen unit), which makes builds slow. The dev workflow routes through cargo run -p fluxer-dev, so even front-end work pulls in a Rust compile. Teams without Rust experience will feel that.

Third, the documentation surface is thin in the repository itself. The README is a logo, a donation link, a docs link, a licence badge and one sentence. Everything an operator needs lives on docs.fluxer.app, which is a separate site. If that site is incomplete for your scenario, for example around backup, upgrade or rollback, the repository will not fill the gap. Nothing in the repository describes a rollback procedure.

How Fluxer differs from Matrix and from Discord

The obvious comparison is Matrix, because both are open protocols you can self-host. The difference is federation. Matrix is built around servers exchanging messages with other servers, and its specifications are the product. Fluxer is a single application: the services in this repository (gateway, messages, users, media proxy, app proxy) form one instance, and nothing in the repository describes interoperability with other Fluxer deployments or with another protocol. Choosing Fluxer means choosing an application you operate, not a network you join. That is simpler to reason about and harder to migrate away from.

The other comparison is Discord, which the search data raises directly. The difference is ownership and control: Fluxer is AGPL-3.0 and the whole stack is in this repository, so you can run it and modify it. Discord is a hosted service where you get an API and a bot surface but not the server. A community that needs data residency, custom moderation tooling at the service level, or the ability to keep running if a vendor changes terms has a reason to look at Fluxer. A community that just wants a working chat server with no operations burden does not. The trade is explicit: you gain control and you take on Cassandra, migrations and upgrades.

Maintenance, upgrades and the AGPL-3.0 licence

The last push to the default branch was on 2026-08-29, and the same date carries the three most recent releases: [email protected], [email protected] and [email protected]. The version scheme encodes the date (2026.829), which makes it straightforward to tell how far behind an instance is. The repository is not archived. That is the extent of what the repository supports about activity; the README says nothing about support windows, release cadence or long-term branches.

Upgrade cost follows from the architecture. Because Cassandra schema changes are managed through dev:cassandra:diff, dev:cassandra:apply and dev:cassandra:verify, an upgrade is not just pulling a new image. You inspect the diff, apply it, and verify. The three published release artefacts suggest the API and the proxies version independently, so an operator has to track more than one component. The repository does not document a rollback path, which is the gap I would want closed before running this in production.

On licensing: the workspace declares license = "AGPL-3.0-or-later" in Cargo.toml and the repository carries an AGPL-3.0 LICENSE file. AGPL-3.0 is a copyleft licence with a network clause, which in practice means that if you modify Fluxer and let users interact with it over a network, you have obligations to those users. I am not a lawyer and this is not legal advice. If you plan to fork Fluxer for a commercial hosted service, get your own counsel before you start.

Editorial conclusion

Adopt Fluxer if you want a community chat and voice server you can run yourself and you are comfortable with a Cassandra-backed Rust and TypeScript stack. Do not adopt it if you only want a hosted account, or if you need a documented mobile install path, because the repository does not provide one. Before committing, run the bootstrap and infrastructure scripts from the root package.json, read the operator get-started page at docs.fluxer.app, and confirm which components the self-hosted proxy release actually covers.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes