Voice on a real SFU
Voice runs through a selective forwarding unit, not a peer-to-peer mesh. Each person sends their audio once no matter how many are listening, so a room of twelve sounds like a room of two.
Vocalkeep is a voice and text chat platform you can run yourself. Servers, channels and real-time voice on infrastructure you control — with a desktop app and a browser tab that share one account.
Also on macOS and Linux · Free and open source · Hosted sign-up is coming
Text
Voice
Voice connected
Lounge · 24 ms
kestrel11:04
pushed the read-state fix — unread counts settle instantly now
nine11:06
confirmed on the Windows build. same account, no re-login.
ora11:09
voice held 12 people last night with zero drops
SFU was barely awake
Members — 5
No ads, no engagement mechanics, no telemetry pipeline pointed at your conversations. Just the chat app, built well.
Voice runs through a selective forwarding unit, not a peer-to-peer mesh. Each person sends their audio once no matter how many are listening, so a room of twelve sounds like a room of two.
Create a server, carve it into text and voice channels, invite people in. Messages arrive over a persistent WebSocket — no polling, no refresh, no waiting to find out someone replied.
Unread state is computed from what you have actually read, never stored as a counter that can drift. A dedicated service keeps every badge in the app correct in one request at launch.
Passwords hashed with Argon2. Short-lived access tokens in memory, refresh tokens in an httpOnly cookie that JavaScript cannot read — rotated on every use, so a stolen one is detectable.
The Windows app and the browser app are the same client, built twice. Same account, same servers, same unread state — sign in wherever you are and pick up mid-sentence.
One command brings up the whole stack — services, database, object storage, voice. Nothing phones home, nothing needs a cloud account, and the development keys ship in the repo so day one works.
Vocalkeep is not a hosted service with a self-host option bolted on. Local is the primary way it runs — the same compose file that a contributor uses on day one is the one that runs it for your group.
# everything: datastores, services, voice
make dev
# on Windows, where make is not a given
.\make.ps1 dev
# services come up on
api localhost:5000
gateway localhost:5001
read localhost:5002
voice localhost:7880Not polyglot for its own sake. Each piece has a different failure mode and a different shape of load, and each one is written in the language that makes its particular problem boring.
Client
TypeScript · React
One codebase, built twice — once as a browser bundle, once inside an Electron shell. The desktop app is a shell, not a fork.
API
Elixir · Phoenix
Auth, accounts, servers, channels. Plain versioned JSON over HTTP, so anything can talk to it.
Gateway
Elixir · OTP
Tens of thousands of long-lived connections, each supervised and restartable on its own. That is what the BEAM was built for.
Read states
Rust
The hottest read-write path in a chat app — every mention writes one, every channel click acks one. It gets its own service and its own budget.
Voice
LiveKit SFU
Self-hosted, and deliberately not written here. Building an SFU is a project, not a feature.
Backed by PostgreSQL 17, Redis, and S3-compatible object storage.
The desktop app adds native notifications, a tray icon and push-to-talk that works when the window isn't focused. Everything else is identical to the web app — same account, same servers.
Builds aren't published yet. Vocalkeep is still in active development — these links go live with the first tagged release. In the meantime you can run it from source.
Including the ones where the answer is "not yet".
Yes — they are the same client. One account, one set of servers, one unread state. Sign in on the web, close the tab, open the desktop app, and you are exactly where you left off.
Self-hosting is the model Vocalkeep is built around: you run the server, you hold the data. If you are joining someone else’s server you just point the app at it and sign in — you do not need to run anything yourself.
Yes. It is open source and there is no paid tier, no seat count and no feature held back. The only cost is whatever you spend running it.
Not today. Voice is encrypted in transit with DTLS-SRTP between each participant and the server, which is the standard WebRTC guarantee — but the server forwards decrypted media, so it is not end-to-end. If you host the server yourself, that server is yours.
No, and there are no plans to. Discord does not offer an export path for server history, and anything that claims otherwise is scraping against their terms.
Accounts, servers, channels, real-time messaging, unread state and voice all work today. It is not yet at a tagged release — there are no published builds, and things will move around before there are.
Your server, your data, your rules — in an app that doesn't feel like a compromise for any of it.