Headscale vs wg-easy

One question settles most of this: can you forward a UDP port from the internet to your server?

If yes, wg-easy is a WireGuard server with a QR code generator attached, and that is the right amount of software for getting your phone and laptop back onto your home LAN. Every packet goes to one endpoint you chose, the topology fits on a napkin, and when it breaks you can reason about it.

If no, because your ISP has you behind carrier-grade NAT or you are in a flat with a router you do not administer, the question stops being a preference. Plain WireGuard needs a reachable endpoint. Headscale gives official Tailscale clients NAT traversal, MagicDNS and ACLs, with the coordination server on your hardware instead of at Tailscale Inc.

Everything else on this page is detail on those two paths, plus a third one you should consider seriously: not self-hosting the control plane at all.

What the table does and does not tell you#

Both are one container. The rows worth your attention are ops load and maturity, because they encode the thing that actually differs: Headscale is pre-1.0 software chasing a protocol it does not own.

Headscale's memory looks smaller, but the data plane is the difference that matters. In Headscale, traffic goes peer to peer and only falls back to a DERP relay when direct connection fails, so the server sees coordination traffic and nothing else. In wg-easy, every packet from every client crosses your server, because that is what hub-and-spoke means.

Hub and spoke against a mesh#

A wg-easy deployment is one WireGuard interface on one host, and every peer's config points at it:

[Interface]
PrivateKey = <client key>
Address = 10.8.0.3/24

[Peer]
PublicKey = <server key>
Endpoint = vpn.example.com:51820
AllowedIPs = 192.168.1.0/24
PersistentKeepalive = 25

Your phone dials the server. Your laptop dials the server. If your phone and your laptop want to talk to each other, the traffic goes through the server. If the server is unreachable, nothing works. That simplicity is the feature.

Headscale coordinates a mesh. Each device runs the official Tailscale client, joins with tailscale up --login-server=https://hs.example.com, receives a network map, and then attempts direct connections to peers using UDP hole punching, falling back to a DERP relay when NAT is uncooperative. Every device gets a stable 100.64.x.x address and a MagicDNS name. Nodes can reach each other whether or not the coordination server is up, once they have a map.

That is genuine capability. It is also more machinery: an ACL policy, a base domain, node approval, subnet route enabling, pre-auth keys, and a version relationship with every client. Both want TLS terminated in front of their web side, so Caddy or an equivalent is a prerequisite either way.

The Headscale costs, stated up front#

• It is not affiliated with or supported by Tailscale. The README says so. One maintainer works there and contributes during work hours, which is a good sign for the project and not a support contract.
• The minimum client version moves. v0.29.3 documents a floor of Tailscale client v1.80.0. Distro packages lag, and when they lag the symptom is a registration that hangs or a node that never gets a working network map. Use Tailscale's own repositories on machines you care about.
• You cannot skip minor versions. Upgrade one minor at a time, in order. 0.28 removed migrations for databases older than 0.25.0, so an instance left alone for a year cannot jump to current.
• There is no web UI. Users, pre-auth keys, node approval and route enabling are headscale subcommands or gRPC. Third-party UIs exist, of varying quality.
• base_domain must differ from the domain in server_url, or it refuses to start rather than build a resolution loop. Use server_url: https://headscale.example.com with base_domain: ts.example.net.
• 0.29 redefined the ACL wildcard. A bare * now resolves to the Tailscale CGNAT range plus the IPv6 ULA range, not every address. Rules that granted access to LAN subnets or internet destinations through an exit node stop working after the upgrade, and the symptom is a healthy tailnet with newly broken subnet routing.

The maintainers are also blunt about scale: hundreds of nodes, not thousands, SQLite rather than PostgreSQL (which is in maintenance mode), and maintainability prioritized over performance. For a homelab that is the right set of tradeoffs, stated honestly.

The wg-easy costs, stated up front#

• v15 is a different product from v14. A full rewrite with, in the maintainer's words, no migration path at all. You export from v14, deploy v15 into a clean volume, and import during the setup wizard. Import is not available once setup completes, so clicking past it means starting over.
• The latest tag still points at v14. Pin :15.
• The licence changed to AGPL-3.0-only in v15, from CC BY-NC-SA 4.0. Commercial internal use is now unambiguously fine; the network copyleft clause applies if you modify it and offer it as a service. Either way, the terms you evaluated in 2024 are not the terms you get today.
• 32-bit ARM images are gone. armv6 dropped in 15.0, armv7 in 15.2.0. A Pi 3 or Zero on a 32-bit OS cannot pull v15 and there is no v14 fallback that shares a config format.
• It needs real privileges. NET_ADMIN and SYS_MODULE, the sysctls net.ipv4.ip_forward=1 and net.ipv4.conf.all.src_valid_mark=1, and a read-only bind of /lib/modules so it can load the kernel module.

Headscale's equivalent is /var/lib/headscale: db.sqlite plus noise_private.key, which is the server's identity. Lose the key and every node re-registers from scratch. Neither is large; both need sqlite3 db.sqlite ".backup out.db" rather than a live cp, and Backups that actually restore covers automating that.

The case for just using hosted Tailscale#

This is the uncomfortable section, so here it is plainly: for most people reading this, Tailscale's hosted control plane is the correct answer, and Headscale is a preference rather than a requirement.

Self-hosting the coordination server buys you exactly one thing: your device inventory, the key exchange coordination and your ACL policy stay on hardware you own. That is a real privacy gain and for some people a real compliance one.

What it does not buy you is independence. You are still running Tailscale's client, speaking Tailscale's protocol, following Tailscale's version cadence, and by default relying on DERP relays you do not run unless you enable the embedded one and open udp/3478 for STUN. You have taken on an upgrade treadmill, a client-version matrix and a pre-1.0 database migration path, and you are still inside somebody else's ecosystem.

If you can state why the device list must not live at Tailscale, run Headscale. If you cannot, use the hosted free tier and spend the saved evenings on something else. wg-easy remains the answer when you want no ecosystem at all: one UDP port, one config file format, no vendor.

Which one for your situation#

What to do next#

Check whether you actually have a forwardable port before anything else: look at your router's WAN address and compare it to what a "what is my IP" page reports. If they differ, you are behind CGNAT and the decision is made. Remote access without port forwarding covers the alternatives including reverse tunnels, and if you go the mesh route, decide early whether DNS for your internal names resolves over the tunnel, which is where DNS for self-hosters and your AdGuard Home or Pi-hole instance come into it. Whichever you choose, put Uptime Kuma on the far side of the tunnel so you find out it is down before you are away from home, and read A security baseline for a home server before you publish anything on a port. The rest of the category is at Networking.