Why Gryt?
The questions people actually ask before they trust a chat app. Some of the answers aren't flattering. They're still the answers.
What is Gryt, and what is it not?
Voice, video and text chat, with screen sharing and file sharing, that you run yourself. That’s the normal way to use Gryt. It isn’t a fallback for people who don’t trust the hosted one. Your community’s stuff sits on machines you control, and you can read the code, fork it, or send a change back.
It isn’t trying to grow. No ads, no tracking, nothing built to keep you scrolling. Which also means nobody is selling it to you except the people already using it.
Do I need an account?
No. Download Gryt and you already have one. Your device makes a keypair and never sends it anywhere. You don’t sign up for anything, and there’s nothing in it we could trace back to you.
And that isn’t a cut-down mode. A guest signs the same challenge an account does, and can own a server with the same roles. Your app makes a separate key for every server you join, so two servers can’t work out they’re talking to the same person.
An account does get you two things a guest doesn’t. You’re the same person on every Gryt server, so people recognise you somewhere new. And you don’t lose it with your device.
It also makes a ban stick. You can ban a guest, but a guest who wants back in makes a new keypair in about two seconds. So servers that take guests lean on the door instead: invites, approval, or LAN only. That’s a real trade-off, and it’s the one to understand before you turn guests on. The rest is in the docs.
If you use the hosted web client at app.gryt.chat, the Privacy Policy covers what we hold.
What am I actually trusting?
Three things, and they’re not the same.
Whoever runs the server. If you join someone else’s server, they can get at what it stores. Messages, uploads, logs. If you host it yourself, that’s you.
The connection. WebRTC encrypts the audio and video on the way with DTLS-SRTP. Voice goes through an SFU so it can reach everyone at once, so the SFU is on the path too. The server owner runs that as well.
Us, and only if you ask. A guest identity doesn’t touch anything of ours. The certificate is signed by the key it describes, and no server calls us to check it. Signing in changes that. Login goes through auth.gryt.chat, and a separate identity service at id.gryt.chat hands out the certificates servers check. Both are in the repo, and you can run both yourself.
Where does the server run?
Wherever you put it. The desktop app has a whole server inside it, so you can host one without touching a terminal. The same server runs under Docker Compose or Helm when you want it on a machine that stays on.
Getting to it from outside your own network means opening a port either way. A Cloudflare Tunnel handles the HTTPS and WebSocket side without opening those. But voice is WebRTC over UDP, and a tunnel can’t carry that. It’s one port, not a range, and it has to be reachable directly.
Self-hosting has the how, in more detail than this page should get into.
How does it fit together?
The server handles rooms, chat and uploads. The SFU moves the voice and video around. Storage and the database are their own pieces, so you can run the lot on your own machines. The dotted lines are the ones a guest never uses.
Voice goes straight from the client to the voice server, over UDP. Nothing in between carries it, and that's the one a tunnel can't do for you.
Can a server admin read my messages?
If the server stores them, yes. That’s true of Gryt and every other self-hosted chat system, and anyone claiming otherwise about theirs is worth a second look. The difference is you get to pick who runs it. Or run it yourself.
Can I run this for a private group?
Yes, and that’s what most people do. One server for a community, a team, or a group of friends. Starting one from the desktop app takes a name and a button. One that should still be there tomorrow is a single command on Linux. On a shared network, servers announce themselves and show up in the app without anyone typing an address.
The docs go further than this page does, including the full architecture.