Hosting from the app

The Gryt desktop app has a full server inside it. Not a demo mode or a cut-down build — the same signalling server, SFU and image worker that a Docker deployment runs. Open the app, create a server, and people on your network can join it.

If you ever ran a Minecraft server off your own machine so your friends could join, this is that. Download, host, play. On a LAN it really is that simple: discovery does what Hamachi used to.

From outside your network you still open a port. For people on the desktop app that's all you need: forward the ports, hand out your IP, and skip domains and certificates entirely. See No domain, just an IP.

A Cloudflare Tunnel is for letting people join from a browser, which needs a real hostname and certificate. A tunnel covers the HTTPS and WebSocket side only. WebRTC media is UDP and a tunnel can't carry it, so the SFU still needs its UDP port reachable directly.

Creating one

1. Click the + in the server rail
2. Choose Create my own
3. Give it a name — the icon is generated from it as you type
4. Take the port it offers, or set your own
5. Create

It starts and you're in it. There's no second step.

The port is prefilled with one that's genuinely free, checked against every interface the server will bind. If you need a particular port — one your router already forwards, or one your firewall rules already name — type it and the field tells you whether anything else is on it.

The number is settled here. The server keeps the ports it's given and doesn't go looking for new ones later, so if your router already forwards something, type that.

Discoverable on LAN decides whether anyone else running Gryt on the same network sees it appear on its own. Leave it on for a LAN party.

Ports to open

Three, and the app tells you which. Settings → My servers → Open these ports lists them under the server with the numbers it actually picked, and is also where you change them. They're typically:

Open them on the machine's own firewall if anyone is joining from another computer at all, and forward them on your router as well if anyone is joining from outside your network.

Voice doesn't travel over the same connection as the chat, and it's UDP rather than TCP. With that port shut, people join, the member list fills up, messages send, and nobody can hear anybody.

The numbers aren't always those three. If something already holds one when the server is created, the app takes the next one up — 5006 rather than 5005 — and that becomes the server's port. So read the panel rather than assuming the table.

When a port is taken

The server refuses to start and says which port, rather than quietly moving to a free one.

That's deliberate, and it used to work the other way. A server that moves itself is fine on the machine it runs on and quietly broken for everyone else. Say you forwarded 5000 on your router. Something claims 5000 one morning, the app moves to 5001, and the server comes back up looking perfectly healthy while nobody outside can reach it. With the media port it's worse: chat keeps working and only voice goes quiet. Neither shows up anywhere in the app.

So when something else has the port, you get told, and you pick:

• Close whatever took it, and start the server again
• Or open Open these ports and give the server a different number

The fields are editable while the server is stopped. Changing one rewrites the server's config.env, including the addresses derived from it, so nothing is left pointing at the old number. It doesn't touch your router.

More than one

You can host several. Each server is genuinely separate — its own messages, its own members, its own invites, its own database — and they cost far less than running two of anything else:

• The SFU is shared. One media process serves every server you host, because voice rooms are namespaced per server. Hosting a second server doesn't mean a second SFU.
• The image worker isn't. Each server gets one, because a worker reads exactly one database.

So server number two costs a server process and an image worker, not another stack.

Managing them

Settings → My servers lists everything you host. Each one shows:

• Running / Stopped, and Start or Stop
• Both addresses — 127.0.0.1:<port> for this machine, and the LAN address to give somebody else
• Start automatically with app, per server
• Advertised addresses, which is where voice is told how to reach you
• Open these ports, the three numbers and the fields to change them
• Server logs, which don't fetch anything until you open them
• Open, which puts it in your server rail
• Delete

Delete is exactly as final as it sounds. It stops the server, removes its database, its uploads and its identity key, and asks you to type the server's name first. There's no second copy anywhere.

Where things live

Each server gets its own directory under your app data folder:

<userData>/gryt-servers/<server-id>/
├── config.env      generated at creation — ports, secret, identity tiers
└── data/
    ├── gryt.db     messages, members, roles, invites
    └── uploads/    files and images

<userData> is ~/Library/Application Support/gryt-chat on macOS, %APPDATA%/gryt-chat on Windows, and ~/.config/gryt-chat on Linux.

Back up a server by copying its directory while it's stopped.

What it doesn't do

Hosting from the app is a real server, but it's running on a desktop machine, so the limits are the machine's:

• It's reachable while the app is open and the machine is awake. Closing Gryt stops the servers it's hosting.
• Anyone outside your network needs a route in. A tunnel covers signalling; the SFU's UDP port still has to be forwarded directly.
• Only one hosted server can advertise itself over mDNS on Linux at a time. All of them still work by address.

For something that should stay up without a person nearby, run it with Docker Compose instead — the same server, pointed at a disk that isn't your laptop.