juist compared
How juist differs from other mesh VPNs, and when one of them fits you better.
The question that tells them apart #
Most mesh VPNs carry traffic in a similar way: encrypted tunnels between devices, direct where NAT allows, over a relay where it does not. Where they differ is who decides which devices belong to the network, and how a device is taken out again.
In juist, your admins decide, by signing changes in the membership log, and every device checks those changes itself. No server is needed for that, and none has to be trusted. How that is built is on the Architecture page.
Three things set juist apart from every other mesh here:
- No central infrastructure, and still WireGuard. The other meshes without a server use protocols of their own, EasyTier offers WireGuard as one option, and WireGuard alone does not get through NAT.
- An admin quorum. If you want, a change takes several admins, and then no single person can add a device.
- Routing and names without a server. Among the meshes without a server, only juist publishes services to the internet and points public names at members. The others leave routes or names to each device’s configuration, or lack them.
At a glance #
EasyTier stands in for the shared-secret meshes.
| With a central server | Without one | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| juist | Tailscale | Headscale | NetBird | Netmaker | ZeroTier | Nebula | Tinc | rayfish | EasyTier | WireGuard | |
| Design | |||||||||||
| No central infrastructure | |||||||||||
| No central infrastructure | ● | – | – | – | – | – | ● | ● | ◐1 | ● | ● |
| No server to trust | |||||||||||
| No server to trust | ● | ◐2 | – | – | – | – | ● | ● | ● | ● | ● |
| Tunnels over WireGuard | |||||||||||
| Tunnels over WireGuard | ● | ● | ● | ● | ● | – | – | – | – | ◐3 | ● |
| Membership | |||||||||||
| Changes take several admins if wanted | |||||||||||
| Changes take several admins if wanted | ● | – | – | – | – | – | – | – | – | – | – |
| Removing a device leaves the others untouched | |||||||||||
| Removing a device leaves the others untouched | ● | ● | ● | ● | ● | ● | – | – | ● | – | – |
| A removal spreads without a server | |||||||||||
| A removal spreads without a server | ● | – | – | – | – | ◐4 | – | – | ◐5 | – | – |
| Connections | |||||||||||
| Through NAT on both sides | |||||||||||
| Through NAT on both sides | ● | ● | ● | ● | ● | ● | ● | ● | ● | ● | – |
| A relay where direct fails | |||||||||||
| A relay where direct fails | ● | ● | ● | ● | ● | ● | ● | ● | ● | ● | – |
| Runs without its maker's servers | |||||||||||
| Runs without its maker's servers | ● | – | ●6 | ● | ● | –7 | ● | ● | ● | ● | ● |
| Tunnels in the kernel | |||||||||||
| Tunnels in the kernel | ○ | – | – | ● | ● | – | – | – | – | – | ● |
| Routing and names | |||||||||||
| Exit nodes | |||||||||||
| Exit nodes | ●8 | ● | ● | ● | ● | ◐9 | ◐10 | ◐11 | ◐12 | ● | ◐13 |
| Subnet routers | |||||||||||
| Subnet routers | ●14 | ● | ● | ● | ● | ◐15 | ◐16 | ◐17 | – | ● | ◐18 |
| Names for every device | |||||||||||
| Names for every device | ●19 | ● | ● | ● | ● | – | ◐20 | – | ● | ◐21 | – |
| A public name pointed at a member | |||||||||||
| A public name pointed at a member | ●22 | – | ● | ● | – | – | – | – | – | – | – |
| Services published to the internet | |||||||||||
| Services published to the internet | ● | ◐23 | – | ●24 | – | – | – | – | – | – | – |
| One device in several networks at once | |||||||||||
| One device in several networks at once | ●25 | – | – | – | ● | ●26 | ● | ● | ● | ● | ● |
| Everyday use | |||||||||||
| Access rules | |||||||||||
| Access rules | ●27 | ● | ● | ● | ● | ● | ● | – | ●28 | ● | – |
| Users, with sign-in through an identity provider | |||||||||||
| Users, with sign-in through an identity provider | – | ● | ● | ● | ◐29 | ◐30 | – | – | – | – | – |
| Windows, macOS, Android and iOS | |||||||||||
| Windows, macOS, Android and iOS | ◐31 | ● | ● | ● | ● | ● | ● | ◐32 | ◐33 | ◐34 | ● |
● yes ◐ partly ○ planned – no
Footnotes
- rayfish: By default n0's pkarr server and relays; both can be replaced.
- Tailscale: With Tailnet Lock, devices accept only keys you have signed; removal still goes through the server.
- EasyTier: One transport among several.
- ZeroTier: The controller issues the removal, the devices pass it on.
- rayfish: Through a pkarr server, and from the coordinator over the mesh.
- Headscale: With a DERP relay of your own.
- ZeroTier: Its root servers are run by ZeroTier.
- juist: Android uses one, and serves as none.
- ZeroTier: Allow Default by hand on every client, NAT by hand on the gateway.
- Nebula: By hand in every device's configuration.
- Tinc: Routes by hand on every device.
- rayfish: IPv6 only.
- WireGuard: By hand on every device.
- juist: Not on Android.
- ZeroTier: Forwarding and NAT by hand on the router.
- Nebula: By hand in every device's configuration.
- Tinc: Routes by hand on every device.
- WireGuard: By hand on every device.
- juist: On Linux with systemd-resolved.
- Nebula: Every device's resolver pointed at a lighthouse by hand.
- EasyTier: By hand on every device.
- juist: On Linux with systemd-resolved.
- Tailscale: Only names under ts.net, through Tailscale's servers.
- NetBird: In beta.
- juist: Only one on Android.
- ZeroTier: On phones, one at a time.
- juist: By device and table of devices, not by user.
- rayfish: Each device's own firewall, with rules the coordinator suggests.
- Netmaker: In the paid edition.
- ZeroTier: In the paid plans.
- juist: Android alone, as a member without names, roles or subnets.
- Tinc: No Android or iOS.
- rayfish: No iOS.
- EasyTier: No iOS.
Tailscale #
Tailscale is the most polished mesh VPN, with clients for Linux, Windows, macOS, iOS and Android, sign-in through an identity provider, and access rules. juist builds in parts of its client, see Architecture.
The coordination server is run by Tailscale Inc. and is not open source. It knows every device and hands out the keys, so whoever controls it could add a device of their own. Tailnet Lock closes that gap: devices accept a new key only if a key you hold has signed it. Removing a device and spreading the change still go through the server.
Choose Tailscale if you want clients for every platform and user accounts with access rules by user today, and can accept a company’s server at the centre.
Headscale #
Headscale is an open source coordination server for the Tailscale clients, which you run yourself. Your server then holds the trust Tailscale’s would. It does not support Tailnet Lock (feature request), so the devices take what the server tells them without checking it.
Choose Headscale if you want Tailscale’s clients without Tailscale’s server, and can run and protect a server of your own.
NetBird #
NetBird connects devices through WireGuard, coordinated by a management server that holds the devices, their keys and the access rules. You can use NetBird’s own or run it yourself, together with its signal and relay servers. The client is BSD-3-Clause, the servers are AGPL-3.0.
Choose NetBird if you want a self-hosted server with a dashboard, sign-in through your identity provider and access rules by user.
Netmaker #
Netmaker builds its mesh from WireGuard too, in the kernel on Linux and FreeBSD, around a server you run yourself or rent from Netmaker. As with NetBird, that server knows the devices and hands out their keys. The core is Apache-2.0; sign-in through an identity provider and failover relays come with the paid edition.
Choose Netmaker if you want WireGuard in the kernel and a server of your own.
ZeroTier #
ZeroTier has a protocol of its own, not WireGuard, and emulates an Ethernet network between devices. Who belongs is decided by a network controller, ZeroTier’s or your own. Its core is MPL-2.0, the controller is source available under a licence of ZeroTier’s own that restricts commercial use.
Choose ZeroTier if you need a layer 2 network, such as for broadcast or protocols other than IP.
Nebula #
Nebula, from Slack, has no server either. Each device carries a certificate signed by your own CA, which names its address and groups, and members with a public address help the others find each other. It is MIT licensed and has run at large scale.
What it lacks is a way to take a device out. Each device has to be given a blocklist by some other means, such as configuration management; until then, the device stays in until its certificate expires. In juist a removal is a signed change that the devices carry among themselves, so it needs no such means.
Choose Nebula if your devices are managed centrally anyway and you want access rules by group.
Tinc #
Tinc is the oldest mesh here without a server. Each device holds a host file with the public key of each member it connects to, and the members pass on what they know of the rest. A member with a public address helps the others through NAT and forwards their traffic where needed. To remove a device, its file has to go from every device that holds it. Version 1.0.37 is likely the last of 1.0, and 1.1 has been a pre-release since 2021.
Choose Tinc for a few devices you configure by hand, with software that has run for decades.
rayfish #
rayfish is the newest mesh here and the closest to juist: no account and no server to trust. A network is a key pair. Its coordinator admits devices by invite or by approval and publishes the list of members, signed with the network’s key, and a removal reaches the others the same way. It tunnels over the QUIC of iroh, not WireGuard, and by default uses the relays and the pkarr server of n0, the company behind iroh; both can be replaced.
Where juist differs: rayfish’s co-coordinators hold one and the same network key, so whoever has a copy can change everything alone. In juist every admin has a key of their own, and a change takes k of them. rayfish calls itself experimental, before 1.0 and without a security audit.
Two projects of the same year take a similar path: nostr-vpn, whose devices accept a list of members only if one of its admins signed it, and the direct mode of Tunnet, with signed members and revocations in a document the devices replicate. In both, one admin or coordinator can make any change.
Choose rayfish to try a mesh without a server on platforms juist lacks, such as Windows or macOS.
Shared-secret meshes #
Projects such as EasyTier admit anyone who knows the network’s name and secret. That is simple to set up, but a device is not admitted on its own and nobody records who admitted it. To remove one, the secret has to change on every device that stays.
WireGuard alone #
WireGuard itself only connects devices whose keys and addresses you have written into each other’s configuration. There is nothing in between to trust, and in the kernel it is faster than juist, which runs WireGuard in user space. But every new device means editing every other device, it does not get through NAT on both sides, and it has no relay.
Choose WireGuard alone for a few devices with fixed public addresses.
Not compared here #
Some projects named alongside these solve another problem. Pangolin, Firezone, Twingate and Defguard connect devices to gateways and services rather than to each other, and Cloudflare Mesh carries all traffic through Cloudflare’s network. Yggdrasil, cjdns and Mycelium are one open network that anyone can join. Hamachi and Radmin VPN are made for games on a LAN. EdgeVPN, hyprspace and wgmesh admit whoever knows a shared secret or is on a hand-written list, like the shared-secret meshes above. innernet is, like juist, a command-line tool for Linux, but around a server that decides who belongs.
Where juist is weaker #
- juist has not had a security audit.
- It runs on Linux and FreeBSD, and on Android as a member without names, roles, exit nodes or subnets; there is nothing for Windows, macOS or iOS.
- It knows devices, not users: its access rules name devices, and there is no sign-in through an identity provider.
- A removed device is taken out as soon as the other devices hear of it, but a cut-off device may hear of it only after up to 48 hours. A central server tells every device it reaches at once.
- It is made for networks of 25 to 100 devices with a few admins.
Sources #
- How Tailscale works, Tailnet Lock, Tailscale’s open source
- Headscale, and its request for Tailnet Lock
- How NetBird works, NetBird’s licence
- ZeroTier’s protocol, network controller, licence
- Nebula’s documentation, its PKI and blocklist, Introducing Nebula
- WireGuard quick start
- Netmaker’s NAT traversal, its sign-in through OAuth, its clients
- Tinc
- rayfish and its security model, nostr-vpn’s protocol, Tunnet
- Headscale and OIDC, NetBird’s kernel and user-space WireGuard, ZeroTier’s SSO, Mobile Nebula, EasyTier’s access rules
- EasyTier
- Routing and names: Tailscale’s exit nodes, DNS, Funnel and one tailnet at a time; Headscale’s features; NetBird’s custom zones, reverse proxy and profiles; Netmaker’s DNS; ZeroTier’s exit node and DNS; Nebula’s unsafe routes and lighthouse DNS; Tinc as a gateway; rayfish’s exit nodes; EasyTier’s magic DNS
The survey behind this page, with about 25 projects, is in the repository: control-plane options and the project survey.