A mesh VPN with no coordination server
WireGuard carries the traffic. Who belongs to the network is a log signed by your admins, and every device checks that log for itself.
make install- No server in the middle
- Devices find each other on the LAN, through each other, or through the public BitTorrent DHT. They punch through NAT, and fall back to a relay that one of your own devices runs.
- Changes need your admins
- Admitting or removing a device takes a quorum of admins, each with a key on their own devices. The keys stay in the keystore; the daemon never holds them.
- Fail-closed
- A device that no voucher has vouched for in 48 hours keeps tunnels only to vouchers, so it cannot carry a removed device along.
Your first network
On the first device, juist create makes a network and juist invite prints
a code for the LAN and a link for anywhere else. The new device joins with
either. Both then show four words, and the invite admits the device only once
you have compared them.
$ juist create home
created network "home"
$ juist invite
invite to "home", expires in 1h; on the new device:
juist join 42-drumbeat-tolerance-glucose # same LAN
juist join 'juist:Kx7q…@192.168.1.20:41642'
nas wants to join; compare with the words it shows:
atlas-amulet-banjo-asteroid
same? [y/N] y
admitting nas (nid:fcRW83T_…)
admitted nas at 198.18.36.2
nas joined
Features
For networks of 25 to 100 devices with a few admins.
| Feature | What it does | Runs on |
|---|---|---|
| Mesh and NAT traversal | WireGuard tunnels between every pair of devices, direct where NAT allows. | Linux, FreeBSD |
| Invites | A code for the LAN or a link for anywhere. Both devices show four words to compare. | Linux, FreeBSD |
| Admins and quorum | Every change takes k of n admins. One that needs more is carried to their devices. | Linux, FreeBSD |
| Several networks | One device in several networks, each with an admin key of its own. | Linux, FreeBSD |
| Exit nodes | A device's internet traffic and DNS through another member. | Linux, FreeBSD |
| Subnet routers | The LAN behind one member, reached from all the others. | Linux, FreeBSD |
| Names | Every member as DEVICE.NETWORK.juist, and public names pointed at members. | Linux with systemd-resolved |
| Publishing services | A member's service reached from the internet by name, through an ingress. | Linux; in progress |
| Relays | Where NAT wins, traffic goes through a member with a public address. | Linux, FreeBSD |
| Freshness and removal | A removed device is told. One cut off for 48 h keeps tunnels only to vouchers. | Linux, FreeBSD |
| Android | A phone joins a network and reaches the other members. | planned |
| Access control | Per-device allow-lists, signed by the quorum. Until then every member reaches every port. | after v1 |
Publishing services
A member’s service, such as a NAS at home, can be reached from the internet by name. A device with a public address, the ingress, reads the name the client asks for and passes the connection through the tunnel. TLS ends at the member, so the ingress never sees the content.
- browseranywhere
Asks for docs.example.org.
- TLSvpsingress
Reads the name in the TLS ClientHello and passes the connection on.
- WireGuardnastarget
Ends TLS, with a certificate from Let's Encrypt.
- HTTP127.0.0.1:8080service
Gets the plain connection.
How to set it up is in the handbook.
Trade-offs
Without a server in the middle, some things are weaker than with one. Each entry says what can happen, why juist accepts it, and what you can change. All of them are in 02-threat-model.md.
Membership
Revocation is eventually consistent
juist admins vouchers M
- What happens
- A device cut off from the network keeps tunnels to a removed device until it hears of the removal.
- Why accepted
- There is no server that every device could ask. The freshness lease bounds it: a device no voucher has vouched for in 48 h keeps tunnels only to vouchers.
- What you can do
- Require M vouchers, so that the bound holds against M − 1 dishonest ones.
Losing a quorum of admin keys is final
more admins than the quorum needs
- What happens
- With fewer than k admin keys left, no change can be signed again, ever.
- Why accepted
- A way around the quorum would be one for an attacker too. Break-glass recovery, from secrets made at genesis, is planned.
- What you can do
- Give the network more admins than the quorum needs, each on devices of their own.
Reachability
Symmetric NAT everywhere needs a relay
juist grant vps relay
- What happens
- Where every device sits behind symmetric NAT, no direct tunnel forms.
- Why accepted
- The relay is one of your own members and sees only WireGuard ciphertext.
- What you can do
- Grant
relayto a device with a public address.
Public helpers see addresses
--no-dht --no-stun
- What happens
- The public BitTorrent DHT and STUN servers see the addresses that use them.
- Why accepted
- Nothing they return is trusted. A compromised helper can delay connections, but cannot change who belongs to the network.
- What you can do
- Run juistd without them, and give devices addresses they can reach.
Cryptography
Tunnel traffic is not post-quantum yet
deferred past v1
- What happens
- Recorded WireGuard traffic could be decrypted by a future quantum computer.
- Why accepted
- Group secrets are already hybrid X25519 + ML-KEM-768. A per-pair ML-KEM preshared key for WireGuard is planned after v1.
- What you can do
- Nothing yet. Do not rely on juist for traffic that must stay secret for decades.