WireGuard vs Tailscale vs Headscale

WireGuard vs Tailscale: the short answer

WireGuard vs Tailscale is not a choice between two protocols, because Tailscale is WireGuard. Tailscale runs the same encryption and the same tunnel, then adds a control plane: a coordination server that exchanges public keys, hands out addresses, punches holes through NAT (network address translation), and applies an access policy. You are choosing how much of that coordination you want to run yourself.

There are three honest answers. Run plain WireGuard when you have one server and a handful of clients that all dial into it. Run Tailscale when you want every machine to reach every other machine with no config file to maintain. Run Headscale when you want that mesh but do not want a third party holding the node list.

What the control plane actually buys you

Plain WireGuard has no discovery. Every peer is a block of text you write by hand: a public key, an AllowedIPs line, and an Endpoint if that peer is reachable. Adding one machine to a network of ten means editing ten config files, because each side needs the other's key. That is why almost every self-hosted WireGuard setup is hub and spoke: one server with a public IP, and clients that only ever talk to it.

A control plane removes the editing. Each node registers once, receives an address from the 100.64.0.0/10 CGNAT (carrier grade NAT) range, and is told the public keys of the nodes it is allowed to reach. The tunnel is still direct WireGuard between two peers, and your traffic never passes through the coordination server. What the server carries is metadata: who exists, which key is theirs, and who may talk to whom.

Three concrete things come out of that.

NAT traversal. Two laptops behind two home routers have no public IP between them. Tailscale uses STUN (session traversal utilities for NAT) to discover each side's outside address and port, then both sides send packets at the same moment so each router sees an outgoing flow first and accepts the reply. When that fails, traffic falls back to a DERP relay, which is an encrypted relay run by Tailscale. Your data stays end to end encrypted through the relay, because the relay never holds the keys. Run tailscale status and each peer line says direct or relay. Run tailscale netcheck to see which relay is nearest and whether your network allows UDP at all.

Key rotation with an expiry. WireGuard keys never expire. A key you issued three years ago works forever unless you delete the peer block by hand. Tailscale expires node keys instead, and as of July 2026 the default expiry period on a new tailnet is 180 days. A machine that has not reauthenticated stops connecting. You can turn expiry off per device for a server or a subnet router that nobody will be around to log in on.

Policy instead of routing. In plain WireGuard, AllowedIPs is the routing table and the access control list at the same time, so "alice may reach the database" has to be expressed as an IP range. Tailscale keeps a separate policy file where rules name users, groups and tags. A rule can say that tag:laptop may reach tag:db on port 5432 and nothing else, and that rule survives a machine getting a new address.

What the control plane costs you

The coordination server knows your network. It holds every node's public key, every node name, the addresses handed out, and the policy. With hosted Tailscale that is a company outside your control. Your packets are not readable to them, because the WireGuard private keys stay on your machines, but the shape of your network is theirs to see, and your ability to connect depends on their service being up and your account being in good standing.

There is a second cost that is easy to miss. Tailscale is a daemon on every machine, so it is software you now have to keep patched on every machine. Plain WireGuard on Ubuntu 24.04 is a kernel module that ships with the distribution and updates with the kernel.

The third cost is billing. As of July 2026 the Personal plan is free with unlimited devices for up to 6 users, Standard is $8 per user per month, and Premium is $18 per user per month. A household stays free. A ten person team does not.

When plain WireGuard is the right answer

Pick plain WireGuard when the topology is genuinely hub and spoke. One VPS with a public IP, three or four devices that connect to it, and no requirement for those devices to reach each other. The config fits on one screen, there is no daemon to update, no account to lose, and no outside service sits between you and your server.

It is also the right answer when you want to understand the layer everything else is built on. Self-hosting a WireGuard VPN on a VPS walks through key generation, wg0.conf, IP forwarding, NAT and the handshake failures, and every one of those mechanisms is still running underneath a tailnet. If you are still weighing the older option, WireGuard vs OpenVPN covers the four cases where OpenVPN keeps an advantage.

The install is short:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

Where plain WireGuard stops being pleasant is the moment every device must reach every other device. A full mesh of N nodes needs N times N minus one peer blocks. At six devices that is thirty blocks kept in sync by hand, and a duplicated AllowedIPs entry silently steals traffic from the peer that had it first, with no error printed anywhere.

When Tailscale is the right answer

Pick Tailscale when the machines move. Laptops on hotel networks, a phone on mobile data, a home server behind a router you do not control. Those are exactly the cases plain WireGuard handles badly, because neither side has a stable public endpoint to put in Endpoint.

Installing the client is one command from the official installer:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up prints a URL. Open it, log in, and the machine joins. There is no key to copy and no inbound port to open, because the daemon makes an outbound connection to the coordination server and keeps it open. That is also why a Tailscale node works on a network where you control no firewall at all.

Two settings do most of the useful work after that. A subnet router advertises a whole LAN into the network so you do not have to install the client on every device:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

The route stays inactive until you approve it in the admin console, which is deliberate: a node cannot inject a route into your network on its own. Linux clients also need sudo tailscale set --accept-routes, because Linux does not accept advertised routes by default, so a route that looks approved on the server side still does nothing on a Linux laptop until you set that.

An exit node sends all of a client's traffic through one machine, which is the full tunnel behaviour people usually mean by "a VPN":

sudo tailscale set --advertise-exit-node

When Headscale is the right answer

Headscale is an open source implementation of the coordination server, and it runs on a VPS you own. The official Tailscale clients point at it instead of at the hosted service:

sudo tailscale up --login-server https://headscale.example.com

Everything about the data path is unchanged. It is still WireGuard, still direct between peers where the network allows it. What changes is that the node list, the keys and the policy live in a SQLite file on a disk you own. Nobody outside can see your network's shape, disable your account, or bill you per user.

The trade is real work. You are now running a public HTTPS service, which means a DNS name, a certificate, and a reverse proxy that passes WebSocket upgrades through correctly. You own its uptime, and a coordination server that is down means new nodes cannot register and existing nodes cannot learn about changes. Headscale is also below version 1.0 and its minor releases have carried breaking changes, so read the changelog before every upgrade. Running Headscale as your own Tailscale control server covers the install, config.yaml, preauth keys and the ports to open.

One caveat catches people late. Headscale does not come with Tailscale's global relay network. Where two peers cannot connect directly, you either enable the embedded relay on your own server or point the config at another one, and that relay is a single box in a single region rather than a worldwide fleet. Peers on the far side of the planet feel that difference.

How to decide in one pass

Ask how many machines must reach each other. If the answer is that they all just talk to the server, plain WireGuard is less software for the same result.

Ask whether the machines have stable public addresses. If most of them sit behind NAT you do not control, you want a control plane, because hole punching is the hard part and it is not something worth rebuilding.

Ask who is allowed to know your network's shape. If the answer excludes outside companies, or your user count makes per seat billing painful, run Headscale and accept that you now operate the control server.

You can change your mind cheaply. Because the data plane is the same protocol in all three, moving from plain WireGuard to a coordinated mesh is a client install rather than a redesign, and moving from Tailscale to Headscale is a re-registration of each node against a different login server.

What none of the three give you

None of them is a firewall. A tunnel decides which packets are carried, not which services listen. A server reachable over the tunnel is still reachable from the internet on any port you left open, so keep UFW firewall rules on the VPS doing their job. Tailscale's policy file narrows what other nodes may reach, and it does nothing about the public interface.

None of them is per service authentication, and none of them is an audit trail of what a user did once connected. Treat all three as transport, and put the login checks in the application.

FAQ

Is Tailscale just WireGuard with extra steps?

Tailscale uses the WireGuard protocol for the data path, so the encryption and the tunnel are the same. What it adds is coordination: key exchange, address assignment, NAT traversal with STUN and DERP relays, key expiry, and a policy file that names users instead of IP ranges. Those are the parts plain WireGuard leaves to you, and they are the parts that get hard once machines move between networks.

Does my traffic go through Tailscale's servers?

Normally no. Peers connect directly to each other once the coordination server has introduced them, and tailscale status shows direct on those peer lines. When a direct path cannot be established, traffic falls back to a DERP relay and the line reads relay. Even then the relay carries encrypted packets and does not hold your WireGuard private keys, so it cannot read the contents. Run tailscale netcheck to see whether your network is blocking the UDP that direct connections need.

Can I use Headscale with the official Tailscale apps?

Yes. Headscale speaks the same control protocol, so the official clients join with sudo tailscale up --login-server https://headscale.example.com. Desktop and mobile apps can be pointed at a custom login server too, though the setting sits in a different place on each platform, and the mobile apps are the ones most likely to need a specific version. Test one phone before you migrate a whole network.

Do I still need to open ports for Tailscale or Headscale?

A Tailscale client needs no inbound port, because it dials out to the coordination server and keeps that connection open. A self-hosted Headscale server does need inbound ports: 443 for the control protocol, 80 if you use an HTTP-01 certificate challenge, and 3478/udp only when you enable the embedded relay. Plain WireGuard needs its UDP listen port, usually 51820, open on the server and on any separate network firewall your provider runs.

Which of the three is fastest?

Throughput is the same, because all three move packets with WireGuard. The difference shows up in connection setup and in path quality. Plain WireGuard with a correct Endpoint connects directly every time. Tailscale and Headscale connect directly most of the time and fall back to a relay when the network blocks hole punching, and a relayed path adds latency. Measure your own path with tailscale ping <node>, which reports whether the route is direct or relayed, or with iperf3 across the tunnel.