Run it yourself.

Getting one up

Five ways in, sorted by how much you have to know, not by which is best. Pick the first one you can already do. The first needs nothing but the app you downloaded. The last one is a Helm chart.

1. 01Nothing you have not already got

   From the app

   The app you downloaded is a server too. Add Server, then Host a server, name it, and read the address out to whoever is joining. Anyone on the same network won't even need that.

   Guide →
2. 02A terminal, on Linux or macOS

   The gryt CLI

   One script installs a binary. Run gryt and press n. It asks eight questions with sensible defaults, writes the Compose files, picks ports nothing else is using, and starts a shared voice server and object store the first time. It needs Docker to run what it writes, so get that first.

   bashCopy

   $ curl -fsSL https://get.gryt.chat | sh

   Guide →
3. 03Windows, and Node.js 22.13

   Windows

   A zip, one config file and start.bat. Node.js is the only thing you install yourself, and it has to be 22.13 or newer. The server uses the SQLite built into Node instead of a separate module, and 22.12 doesn’t have it.

   Guide →
4. 04Docker, and somewhere to put it

   Docker Compose

   A compose file and an .env, both grabbed with curl. No clone needed. Set the address people will reach you on, bring it up, and you have what most people running this for a community end up with.

   bashCopy

   $ docker compose up -d

   Guide →
5. 05A Kubernetes cluster

   Helm chart

   ops/helm/gryt in the monorepo, with a README and example values. There’s no published chart repo and no docs page yet, so this one links to the chart itself.

   bashCopy

   $ helm install my-gryt ./ops/helm/gryt

   The chart →

What you are running

Four things. A Node server for accounts, channels, messages and uploads. A voice server written in Go that moves the audio and video around. Somewhere to put files, which is any S3-compatible storage. And a small worker that resizes images. On one machine that’s one docker compose up. The desktop app already has the first three inside it, which is why hosting from the app needs no terminal.

Reaching it from outside

Skip all of this if the server is only for people on your own network. Gryt servers announce themselves over mDNS, so on a LAN nobody types an address.

Going public is four lines in .env. Getting them wrong is the usual reason voice works on the LAN and for nobody else. The UDP port has to be open as UDP. A reverse proxy in front of the server doesn’t cover it.

SFU_PUBLIC_HOST=wss://sfu.example.com
ICE_ADVERTISE_IP=203.0.113.10
ICE_UDP_MUX_PORT=3478
CORS_ORIGIN=http://127.0.0.1:15738,https://app.gryt.chat

The server doesn’t do TLS. It speaks plain HTTP and has no certificate of its own, so a domain means something in front of it. Caddy is the usual answer. It gets the certificates and renews them without being asked, and the config is two names pointed at two services.

api.example.com {
    reverse_proxy server:5000
}

sfu.example.com {
    reverse_proxy sfu:5005
}

server and sfu are the compose service names, so it works from a Caddy container in the same file. The second name has to be the one in SFU_PUBLIC_HOST. And Caddy serves HTTP/3 on UDP 443 by default, which is one more reason not to put voice on 443.

• No domain, just an IPWhat works and what does not when there is no name pointing at the box.→
• TLS with CaddyThe compose service that runs the proxy above, and where the certificates come from.→
• Cloudflare TunnelHTTPS and WebSockets without opening those ports. Voice still needs its own UDP port reachable.→
• TailscaleA server nobody outside your tailnet can see, which is a reasonable answer for a group of friends.→

Running it properly

The settings that start to matter once it is up and someone other than you is using it. Upgrading is the same two lines as installing, and pinning a version instead of following latest is what keeps it predictable.

$ docker compose pull
$ docker compose up -d

Back up the server data directory first if you’re moving to a beta. A beta build can change the SQLite schema when it starts, and there’s no way back down. Going back means restoring that copy.

And read how to take one first. The database runs in WAL mode, so copying gryt.db on its own while the server is running can hand you an empty database, and nothing says so until the day you restore it.

• ConfigurationEvery setting each service takes, and the handful that span more than one of them.→
• Roles and permissionsWhat people are allowed to do on your server, and how to decide it.→
• Who can joinWhether your server takes guests, accounts, or both, and what each choice costs you.→
• Custom emojiUploading them, and importing a pack from emoji.gg or BetterTTV with a link.→
• Rate limitingHow the server decides somebody is going too fast, and what it does about it.→
• MonitoringMetrics and health endpoints, for when you want to know before somebody tells you.→
• BackupsWhat to copy, and why copying gryt.db on its own can hand you an empty database.→

Tools and when it breaks

• grytA terminal manager: create a server profile, edit its settings with validation, start and stop the deployment it writes.→
• Voice debuggingThe page to open when voice will not connect. Start here rather than in the server logs.→
• TroubleshootingEverything else that goes wrong, and what it usually turns out to be.→

What a server decides

Almost every limit in Gryt belongs to whoever runs the server, and there’s no tier above them that raises it. Uploads, avatars and emoji all start at 100 MB so nobody fills a disk by accident, and an owner can set any of them to whatever they want, including no limit at all. Voice starts at 96 kbps and goes to 510.

Two limits aren’t yours to set. Uploads go up in parts, so past your own limit the next one belongs to the storage. On S3 that’s 5 TB a file. And behind a Cloudflare Tunnel, the free plans cap uploads at 100 MB whatever your server says.