juist compared
How juist differs from other mesh VPNs, and when one of them fits you better.
What sets 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. They differ in who decides which devices belong to the network, and in how a device is removed 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.
Four things set juist apart from every other mesh here:
- No central infrastructure, and still WireGuard. The other meshes without a server use their own protocols, and EasyTier offers WireGuard only as one option among several. WireGuard alone does not get through NAT.
- An admin quorum. You can require several admins for each change, so that 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. In the others, routes and names are set by hand in each device’s configuration, or are not available at all.
- Quantum-safe throughout. Every tunnel mixes in a key a quantum computer cannot recover, and every change to the network is signed with ML-DSA. None of the others signs its members that way. Of the other meshes, only NetBird offers post-quantum tunnels, as an experimental option; plain WireGuard gets them from a preshared key you set by hand.
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 can require several admins | |||||||||||
| Changes can require several admins | ● | – | – | – | – | – | – | – | – | – | – |
| 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 | – | – |
| Against a quantum computer | |||||||||||
| Tunnel traffic recorded today stays unreadable | |||||||||||
| Tunnel traffic recorded today stays unreadable | ● | – | – | ◐6 | – | –7 | – | – | – | – | ◐8 |
| Membership signed so that it cannot be forged | |||||||||||
| Membership signed so that it cannot be forged | ● | – | – | – | – | – | – | – | – | – | – |
| Connections | |||||||||||
| Through NAT on both sides | |||||||||||
| Through NAT on both sides | ● | ● | ● | ● | ● | ● | ● | ● | ● | ● | – |
| A relay where direct fails | |||||||||||
| A relay where direct fails | ● | ● | ● | ● | ● | ● | ● | ● | ● | ● | – |
| From a network that lets only HTTPS out | |||||||||||
| From a network that lets only HTTPS out | ● | ● | ● | ● | ●9 | ◐10 | – | ◐11 | ● | ●12 | – |
| Ethernet (layer 2) between devices | |||||||||||
| Ethernet (layer 2) between devices | – | – | – | – | – | ● | – | ● | – | – | – |
| Runs without its maker's servers | |||||||||||
| Runs without its maker's servers | ● | – | ●13 | ● | ● | –14 | ● | ● | ● | ● | ● |
| Tunnels in the kernel | |||||||||||
| Tunnels in the kernel | ○ | – | – | ● | ● | – | – | – | – | – | ● |
| Routing and names | |||||||||||
| Exit nodes | |||||||||||
| Exit nodes | ●15 | ● | ● | ● | ● | ◐16 | ◐17 | ◐18 | ◐19 | ● | ◐20 |
| Subnet routers | |||||||||||
| Subnet routers | ●21 | ● | ● | ● | ● | ◐22 | ◐23 | ◐24 | – | ● | ◐25 |
| Names for every device | |||||||||||
| Names for every device | ● | ● | ● | ● | ● | – | ◐26 | – | ● | ◐27 | – |
| A public name pointed at a member | |||||||||||
| A public name pointed at a member | ●28 | – | ● | ● | – | – | – | – | – | – | – |
| Services published to the internet | |||||||||||
| Services published to the internet | ● | ◐29 | – | ●30 | – | – | – | – | – | – | – |
| One device in several networks at once | |||||||||||
| One device in several networks at once | ●31 | – | – | – | ● | ●32 | ● | ● | ● | ● | ● |
| Everyday use | |||||||||||
| Access rules | |||||||||||
| Access rules | ●33 | ● | ● | ● | ● | ● | ● | – | ●34 | ● | – |
| Users, with sign-in through an identity provider | |||||||||||
| Users, with sign-in through an identity provider | – | ● | ● | ● | ◐35 | ◐36 | – | – | – | – | – |
| Windows, macOS, Android and iOS | |||||||||||
| Windows, macOS, Android and iOS | ◐37 | ● | ● | ● | ● | ● | ● | ◐38 | ◐39 | ◐40 | ● |
● 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.
- NetBird: With Rosenpass, an experimental option, not on phones.
- ZeroTier: Not ZeroTier One; ZeroTier Quantum, a separate commercial platform, claims it.
- WireGuard: With a preshared key set by hand, or Rosenpass.
- Netmaker: Since 1.7, through a gateway set up for it.
- ZeroTier: A relay over TCP on port 443, without TLS.
- Tinc: Over TCP to port 443 or an HTTP proxy, without TLS.
- EasyTier: Over WebSocket with TLS, to a node listening on port 443.
- Headscale: With a DERP relay of your own.
- ZeroTier: Its root servers are run by ZeroTier.
- juist: Android can use one but cannot be one.
- ZeroTier: Allow Default set by hand on every client, NAT set up 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: Android can use one but cannot be one.
- 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.
- Nebula: Each device's resolver must be pointed at a lighthouse by hand.
- EasyTier: By hand on every device.
- juist: On Linux and FreeBSD, not in the Android app.
- 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 named group 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: Only Android, as a member without public names or roles.
- Tinc: No Android or iOS.
- rayfish: No iOS.
- EasyTier: No iOS.
Tailscale #
Tailscale has 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. Its tunnels are not post-quantum: it sets no preshared key and lets you set none.
Choose Tailscale if you want clients for every platform and user accounts with access rules by user, 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. You then have to trust your server instead of Tailscale’s. 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 the one NetBird runs, or run it yourself together with its signal and relay servers. The client is BSD-3-Clause, the servers are AGPL-3.0. With Rosenpass, an experimental option not available on phones, its tunnels become post-quantum.
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’s source is available, but under ZeroTier’s own licence, which restricts commercial use. ZeroTier One, the open source client, is not post-quantum; ZeroTier Quantum, a separate commercial platform launched in 2026, promises to be.
Choose ZeroTier if you need a layer 2 network, such as for 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 remove a device. Each device has to receive a blocklist by some other means, such as configuration management. A device that has not received it accepts the removed device until its certificate expires. In juist, a removal is a signed change that the devices pass on among themselves, so no separate channel is needed.
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 1.0 release, 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 anyone with a copy can change anything on their own. 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 other projects from the same year take a similar approach: 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 devices are not admitted individually, and nobody records who admitted them. To remove one, the secret has to be changed 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 cannot connect two devices that are both behind NAT, and it has no relay. A preshared key, set by hand or rotated by Rosenpass, makes its tunnels post-quantum.
Choose WireGuard alone for a few devices with fixed public addresses.
Not compared here #
Some projects often named alongside these solve a different 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. On Android, a phone is a member without roles, public names 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 device that is cut off may hear of it only after up to 48 hours. A central server tells every device it reaches right away.
- 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
- Against a quantum computer: Tailscale, NetBird with Rosenpass, ZeroTier Quantum, Nebula’s request, iroh’s handshakes, WireGuard’s known limitations
- HTTPS only and layer 2: Tailscale’s DERP servers, NetBird’s relays, Netmaker 1.7, ZeroTier’s TCP relay, Tinc’s configuration, iroh’s relays, Nebula on layer 2, EasyTier on layer 2
The survey behind this page, with about 25 projects, is in the repository: control-plane options and the project survey.