Turn your Discord roles
into a private, encrypted network.

No. There's no exit node and nothing is proxied — your default route is untouched. Only traffic addressed to another mesh member goes into a tunnel; everything else leaves your machine exactly as it did before.

Not unless you let them. The engine installs a host firewall that drops all inbound on the mesh interface except the ports you explicitly share — a peer can ping you and nothing else. Sharing a port is a deliberate act, and can be scoped to one network's members or to just your own devices. Your regular LAN and localhost traffic is never touched.

No. It isn't on the data path — packets go peer to peer — and it never holds a peer's private key, so there is nothing for it to decrypt even in principle.

Why there's a trusted party at all: Discord gives one user no way to check another user's roles — only a bot can read a server's member list. So membership has to be vouched for by something holding a bot token, and that something is the coordinator. It's a Discord limitation, not a design preference.

The honest caveat that follows: the coordinator generates its own signing key for each Discord server it serves — UnityLAN's key, nothing Discord issues or knows about — and holds it. So whoever runs the coordinator could mint an attestation and place a device of their own into your networks. That device would still land behind your firewall rules like any other peer, and it could not read traffic between existing peers. If that residual trust bothers you, self-host — then the signing key is on your box and nobody else's.

Your Discord user ID and display handle, your device names and their WireGuard public keys, an index that determines your mesh address, a per-device token, and a last-seen timestamp. That's the lot.

It does not store your traffic (it never sees any), and it keeps no record of the addresses your peers connect from — reflexive candidates are brokered in memory to help two peers find each other and are never written down. The coordinator logs operational events like start-up and membership changes, not a per-request access log.

On Linux, yes, automatically. Both use the same 100.64.0.0/10 address range, and Tailscale installs a firewall rule that drops that range on interfaces which aren't its own — which silently blackholes every UnityLAN packet while peers still look reachable. The engine detects that rule and narrowly exempts the mesh interface, rechecking after every Tailscale restart.

On Windows this isn't handled yet. If you run both there and mesh traffic vanishes while peers show as connected, this is why.

No. Peers negotiate a direct path themselves, hole-punching where the NAT allows it. The hardest cases — CGNAT, symmetric NAT on both ends — fall back to an opted-in member relaying ciphertext it cannot read.

When a direct path exists, traffic takes the same route it would without UnityLAN, plus WireGuard's encryption overhead — so latency is close to a plain internet connection between the same two machines, and there's no server in the middle adding a detour. A pair that ends up on the relay fallback pays whatever the detour through that member costs.

<device>.<you>.unity.internal — so laptop.alice.unity.internal. Whichever device you mark primary also answers to the bare alice.unity.internal.

Yes, and it can have a real HTTPS certificate rather than a browser warning. Mesh names end in .unity.internal, which no certificate authority will ever certify — so a deployment can also configure a domain it owns, under which every device gets a matching public name (laptop.alice.mesh.unitylan.com on the hosted coordinator) and can obtain a publicly-trusted certificate for it. Your device runs the whole exchange and keeps its own key; the coordinator never sees key material.

It's off by default and opt-in per device, for a reason worth knowing: every publicly-trusted certificate publishes its names to public transparency logs, permanently, where anyone can search them. Turning it back off stops renewals but can't unpublish what's there. The app only offers the option once you're actually serving something.

Nothing dramatic. A device stays enrolled and keeps its address until you remove it — ctl remove for one you no longer have, or uninstall when you're done with a machine. Removing it returns the address to the pool.

There's one automatic cleanup: if you mesh only your own machines, with no Discord server involved, an address that goes 30 days without connecting is released and you get a fresh one next time you log in.

Yes, and it's meant to stay that way — there are no seats, plans, or limits to grow into. It's a control plane that carries no traffic, so it's cheap to run. If you'd rather not depend on someone else's goodwill, self-hosting is one container.

Best-effort. UnityLAN is a side project, not a company or anyone's day job — there's no SLA, and the hosted coordinator comes with no uptime promise. Questions in Discord get answered when there's time. Everything is open source and self-hostable precisely so you're never stuck waiting on one person.