VoceChat is a chat server small enough to run on your own hardware

What the project is actually shipping

VoceChat is described as a superlight Rust written social server, with the emphasis on easy integration into your own site or app, and the site's own tagline is about re-decentralising the internet through personal cloud computing. The homepage is voce.chat and the documentation is at doc.voce.chat.

The server is the Rust repository you are looking at, and the surrounding ecosystem is laid out in the project composition table. The server itself is Rust, supports Linux, Windows and ARM32/64, and the official Docker image is built with Docker and Shell, supports Linux and ARM64, and is published as vocechat-server on Docker Hub. The mobile app is Flutter, supporting Android and iOS, and the web client is React, described as a web app with integrated management. The documentation is a Docusaurus site in its own repository.

The feature list is where the scope becomes clear, and the checked boxes are more informative than the description. Voice is done, and it now supports the VoceSpace private hosting solution as well as agora. Video is done, with the same two options. Direct and group chatting are done, as are reply and @ mentions, images and large file transmission, pin, forward, favourite, and auto-delete of your own messages. Bot and webhook support is done for both inbound and outbound.

The one item still open at the end of the visible list is role based permissions, which is worth noticing given that multi-tenant administration is the usual reason a team reaches for chat software in the first place.

The Rust choice is about footprint, and the README argues it explicitly

The Why Rust section of the README is short and direct, and it explains a design constraint rather than a preference.

Personal cloud needs efficient solutions. The Rust written server is less than 20MB and runs with great efficiency. The reasoning that follows is that hosting a 20MB private social media server is much more accessible than a 300MB one, with the analogy that if Facebook is a grand hotel, VoceChat is like a house, and if Matrix and Mastodon are buses, VoceChat is like a car.

That size claim is the reason to look at this project, because it changes what you can deploy. A chat server you can run on a NAS, a Raspberry Pi or a local PC is a chat server you can give to a group, a family, a small team or a school, and the operating cost is a machine someone already owns. A 300MB server with a database to provision is a different conversation.

The repository structure supports the same point. The top level holds src, crates, migrations, config, cert and build directories, a Cargo.lock, a .env file and a debug.log. The crates directory contains the internal libraries, and the Cargo.toml lists them: rc-msgdb for the message database, rc-token, rc-fcm for push notifications, rc-magic-link, vc-license, agora-token, and open-graph built on the poem_openapi feature.

The web stack is the Poem framework, with rustls, SSE, static files, test, i18n, anyhow and acme enabled, alongside poem-openapi for the API documentation surfaces with rapidoc, swagger-ui and redoc. The database is SQLite through sqlx, with the runtime-tokio-rustls and json features, which is consistent with a single-binary, single-file deployment.

Running it with one docker command

The quick run in the README is a single container invocation, and it is the fastest way to see what the project does.

docker run -d --restart=always \
  -p 3009:3000 \
  --name vocechat-server \
  privoce/vocechat-server:latest

The port mapping is the one detail worth reading carefully. The host is published on 3009 and the container listens on 3000, so the browser URL is http://localhost:3009/ rather than the container's own port. The restart policy of always means the server comes back after a reboot without anyone intervening, which matters for something intended to sit on a home NAS.

Everything else about the deployment is out of scope for the README, which points you at doc.voce.chat for the documentation. The repository's own directories give the shape of the configuration: a config directory, a cert directory that suggests the server manages its own certificates, a migrations directory for database schema changes, and a .env file at the root, so the server is configured through environment variables.

The Cargo.toml shows that certificate work is in scope for the server itself, with rcgen and its x509-parser feature listed, and the acme feature enabled on the Poem framework, which is the standard route to automated certificate issuance. That combination is what lets a self-hosted instance get a valid certificate without the operator wiring a reverse proxy for it.

The licensing model, which is the first thing to read

The licence arrangement is the most important commercial fact about this project, and the README puts it under its own heading: free for personal use, require license for non-personal use.

The definition of personal use is precise and numeric. The VoceChat official image is free for personal use, which is defined as equal or less than 20 registered users. If you want to integrate VoceChat into your own app or site for a larger user base, you have to purchase a licence, and the licence is 49 dollars per version.

So this is open source commercial software, as the README puts it, rather than free software in the usual sense. The repository's licence field in Cargo.toml reads MIT, and there is a licence file in the repository root, but the README's own statement is that personal use is free and everything else needs a purchase. The project composition table shows the server under a Big Time Public License and the official Docker image under Creative Commons Attribution-NonCommercial 4.0 International, which is a non-commercial licence, while the Flutter and React clients are GPLv3.

The practical consequence for an adopter is that the size of your user base decides your obligations, and the boundary is at twenty registered users. Above that, you are in the market for a per-version licence, and resale licensing is also offered for NAS and cloud providers who want to collaborate with the project. The team also offers a customization service.

Note what is not claimed. The README does not explain how the registered user count is measured, what a version means for the 49 dollar price, or what happens to a deployment that grows past twenty users. Those are questions for the vendor, not for the documentation.

Webhooks and bots, and the work in progress of connecting servers

The section on interconnection is the most forward-looking part of the README, and it is also the least finished, so it is worth reading with care.

The problem it names is that social media cannot always stay private if people want new information transferred among different servers. The word social in social media means multiple nodes communicate with multiple nodes in a synced space, mass to mass, and a channel, private or public, should serve as the end of that mass to mass data sharing and syncing space.

The mechanism that exists today is webhooks, and the README says both inbound and outbound webhooks are implemented, so it is possible to sync messages from a VoceChat channel to another channel, naming Slack, Discord or VoceChat as targets. The cost is stated in the same sentence: you will need to write your own server side code to personalize this process, and the README calls that troublesome.

The proposed fix for the troublesome part is architectural rather than a feature. The README argues that serverless could be a good solution, in the same breath as noting that the next paradigm of the internet is serverless functions plus personal storage, and that making VoceChat serverless is also a next step. That is a direction, not a capability.

Bots are the other thread. The README says bots are interesting and that personal bot services may replace platforms, with the team training some bots based on the GPT API that can be added to VoceChat.

For a federated future, the README invites proposals: if you have a proposal on how multiple servers could get interconnected, for example whether to support the Matrix protocol or other protocols, the discussion is open.

The honest reading is that VoceChat is currently a good self-hosted chat server with a webhook-based bridge to other services, and that cross-server sync in the general case is a design question the project has not answered yet.

Where VoceChat is the wrong choice

Three limits, and they follow from the project's own stated direction rather than from missing features.

The first is federation. If your requirement is a chat that participates in a larger network, Matrix-style, where users on different servers can talk across them with a shared identity model, then VoceChat is not that today, and the README's own framing of the problem as unsolved supports that. A team that needs Matrix federation is looking at the wrong project; a team that needs a private chat for one group is looking at the right one.

The second is the role based permissions gap. The feature list ends with role based access still unchecked, and the README's passage on channel power describes what an administrator might have the right to assign rather than a shipped capability. For a community, a school or a company with a support desk and a contractor tier, that is the feature you are most likely to need and the one that is not there.

The third is the licence ceiling, which is a hard limit rather than a soft one. Twenty registered users is not many, and the transition from a hobby deployment to a service for a customer base crosses from free to paid, which means the cost model and the upgrade path both change at that point. The project is candid about it, which is better than discovering it later, but it does mean the tool is aimed at exactly the audience its size limit describes.

On alternatives, the comparison worth making is with Matrix, since the README names it, and with any hosted chat product your users already have accounts for. Matrix is a protocol with a server ecosystem, and it buys you cross-server federation, which is precisely what VoceChat has not built. The difference in approach is that Matrix accepts a great deal of protocol complexity in exchange for federation and interoperability, while VoceChat accepts a much simpler deployment and a per-version licence in exchange for being a house rather than a bus. For a group that already runs its own infrastructure, the footprint argument is usually the deciding one, and the federation gap usually does not matter because the group is not trying to talk to anyone outside the house.

Editorial conclusion

Adopt VoceChat if you want a chat and media server you host yourself, on a NAS, a Raspberry Pi or a local machine, and you need something with a small footprint and a real mobile client rather than a browser tab. Do not adopt it for a commercial service above twenty registered users without buying a licence, because the README is explicit that personal use is capped at that count and the licence is 49 dollars per version, and do not expect inter-server federation, because the README describes mass to mass syncing between servers as a work in progress with webhooks as the current mechanism. Verify first that the size definition of personal use fits your situation, that the Docker image or the Rust build matches the platform you deploy on, and that the pieces you actually need, voice and video calls, are served by the providers the README names rather than by the server itself.

Frequently asked questions

Official sources

1. Issues
2. Privoce/vocechat-server-rust on GitHub
3. Project website
4. README
5. Releases