One process, one line of config
A server starts with public_addr and nothing else. SQLite is embedded, so the whole server state is one directory.
Thawr connects laptops, servers, phones and home machines across the internet as if they were on one LAN. WireGuard carries the traffic, a server you own decides who may join, and nothing phones home.
Why Thawr
No vendor control plane, no identity provider you must sign up for, no fleet of containers to keep alive. One process runs the network and it keeps running when the internet does not.
A server starts with public_addr and nothing else. SQLite is embedded, so the whole server state is one directory.
The kernel module where present, wireguard-go otherwise. Thawr never implements cryptography of its own.
Peers find each other with STUN and hole punching. When two strict NATs get in the way, the relay built into the server carries packets it cannot read.
Write who may reach what in a YAML file you keep in git. A peer without a rule cannot see another, and the receiving peer filters ports as well.
Scan it in the official WireGuard app. The server keeps only the public key, and the phone resolves peer names through the hub.
A Linux peer advertises the network behind it, or itself as an exit node. An admin approves, and the policy says who may use it.
Every device pins the hub's key and the keys of the peers it reaches. A changed key stays out of the tunnel until you run thawr client trust. The optional network lock adds signatures the server never sees.
It starts and runs with no internet access. Names like nas.thawr resolve from the netmap the client already has.
How it works
On a host with a public address. This writes the config, registers the service and starts it at boot.
sudo thawr server install --public-addr vpn.example.com
The token enrols one device and then stops working.
thawr admin user create markus --role admin thawr admin token create --owner markus --kind human
On every machine except the server. Phones use a QR code from thawr admin peer add-mobile.
sudo thawr client install --server https://vpn.example.com \ --token thawr_... --fingerprint sha256:...
One table shows whether the control connection, a path to a peer or the policy is the problem.
thawr client status ssh nas.thawr
thawr 0.1.0 · alice-laptop 100.64.0.7 server vpn.example.com:8443 connected (netmap #42, 3s ago) WireGuard: kernel · thawr0 · listen 41820 NAT: cone (reflexive 203.0.113.9:41820) PEER IP KIND PATH HANDSHAKE homelab-nas 100.64.0.3 server direct 198.51.100.4:51820 12s build-box 100.64.0.9 agent relay 3m hub 100.64.0.1 server direct vpn.example.com:51820 25s Filter: 3 rules · 0 dropped (last 5 min)
Connections
Download
The thawr binary is the same on every machine. What differs is the subcommand you install: server on the host, client everywhere else. This is a release candidate; v0.1.0 follows once the manual checklists have passed on real hosts.
Not sure which? Apple menu → About This Mac: “Chip: Apple M…” is Apple silicon, “Processor: Intel” is Intel.
SHA256SUMS Homebrew formula (thawr.rb) All releases
curl -fLO https://github.com/Sira-Labs/Thawr/releases/download/v0.1.0-rc7/thawr_v0.1.0-rc7_linux_amd64.tar.gz && curl -fLO https://github.com/Sira-Labs/Thawr/releases/download/v0.1.0-rc7/SHA256SUMS && awk -v f=thawr_v0.1.0-rc7_linux_amd64.tar.gz '$2 == f' SHA256SUMS > thawr.sha256 && test -s thawr.sha256 && sha256sum -c thawr.sha256 && tar xzf thawr_v0.1.0-rc7_linux_amd64.tar.gz && sudo install -m 0755 thawr_v0.1.0-rc7_linux_amd64/thawr /usr/local/bin/thawr && thawr version
Releases are built by CI from a tag, reproducibly, and ship with checksums. Phones do not need this download: they use the official WireGuard app with a QR code from the server.
What you can rely on
WireGuard carries the tunnel. Hashing, password storage and randomness come from Go's standard and x/crypto packages.
CI builds every target twice and fails unless the archives are byte-identical. Each release ships with SHA256SUMS.
Phone traffic goes through the hub, so the server can read it, unlike the end-to-end tunnels between laptops and servers. Read the threat model.
Go, no CGO, one binary. Report vulnerabilities privately through the security policy.
| Tailscale | NetBird | Headscale | Thawr | |
|---|---|---|---|---|
| Control plane | Vendor cloud | Vendor cloud or self-host, multi-service | Self-host, re-implements Tailscale's protocol | Self-host, own protocol, one process |
| Identity | External IdP required | External IdP required | Tailscale clients, OIDC or pre-auth keys | Local users and tokens, OIDC optional |
| Relay | Vendor DERP fleet | Vendor TURN or self-hosted coturn | Separate DERP or vendor DERP | Built into the server binary |
| Works with no internet | No | No | Partially | Yes |
| Deployment | Managed | Docker Compose, 5+ containers | Binary, reverse proxy and DERP | One binary, one YAML line |
Comparison as stated in the project README. Thawr trades breadth for sovereignty and simplicity; the vision document lists the non-goals.
غار ثور
Thawr is named after the cave near Mecca where the Prophet Muhammad ﷺ and Abu Bakr found shelter during the Hijra: hidden, protected, reachable only by those who belong. The mark is a cave arch built from a mesh of nodes, sheltering a smaller mesh.