Does all my traffic go through the VPS?

No. Headscale only handles registration, key exchange and distribution of the network map and ACLs; once two nodes know about each other they open a direct WireGuard tunnel and traffic flows peer-to-peer without touching your VPS. The exception is when both peers sit behind NATs that block direct connection, in which case the traffic falls back to a DERP relay — and even then it stays end-to-end encrypted, so the relay carries ciphertext it cannot read.

Do I need a domain name?

Yes. `server_url` is written into the Headscale configuration and every client registers against that HTTPS address, so it must be a real, stable domain with a valid certificate. Point an A record such as `vpn.example.com` at your VPS before deploying. Changing it later invalidates existing registrations and forces every node to enrol again.

Is there a web interface?

Not in Headscale itself: the project ships a CLI and a REST/gRPC API, and administration happens through `headscale users`, `headscale preauthkeys` and `headscale nodes` commands run inside the container. Several third-party web UIs exist and talk to the API, but they are separate community projects — if you want one, deploy it yourself alongside and treat it as an extra piece of exposed surface to secure.

How do Magic DNS and the address range work?

Nodes receive addresses from the `100.64.0.0/10` range (plus an IPv6 range), which is reserved for carrier-grade NAT and therefore does not collide with the usual private networks. With Magic DNS enabled, each machine is also resolvable by name under the mesh's base domain, so you can reach a server as `db.headnet.local` instead of memorising its address — without touching your public DNS zone.

What are the limits compared to Tailscale's own service?

Headscale implements the core of the protocol — mesh connectivity, Magic DNS, ACLs in the same HuJSON policy format, subnet routers and exit nodes — but it is a community reimplementation, not a feature-for-feature clone. Some of Tailscale's higher-level and enterprise features have no equivalent, and you take on operating the control server yourself: backing up its SQLite database, keeping the container updated, and being the reason your mesh works. In exchange you get unlimited users and devices and a network map that never leaves your VPS.

Secure access and connect teams.

Headscale

Self-host your Tailscale control server — full mesh VPN under your control, no cloud dependency.

512 MB RAM 1 vCPU Port 8080 Available

Source code

Tech stack

DockerGoSQLiteWireGuard

Minimum RAM512 MB

Minimum CPU1 vCPU

Default port8080

Compatible OSubuntu-24.04

Headscale is an open-source, self-hosted implementation of the Tailscale control server. Where Tailscale's free tier limits you to 3 users and stores your network map in the cloud, Headscale runs the coordination server on your own VPS — your keys, your ACLs, your logs. Clients are standard Tailscale apps for every platform (Linux, macOS, Windows, iOS, Android), so your team needs zero new software.

Under the hood, every connection is a direct WireGuard tunnel. Headscale only handles key exchange and ACL distribution — once peers discover each other, traffic flows peer-to-peer with WireGuard's minimal footprint. The Go binary idles under 50 MB RAM. BSD-3-Clause licensed, ~41 k GitHub stars.

Key features

Full Tailscale-compatible control plane: use the official Tailscale client on every platform — no custom fork required.

Unlimited users and devices: no 3-user cloud limit, no per-seat cost, your network scales with your team.

WireGuard peer-to-peer tunnels: Headscale only coordinates key exchange; actual traffic is direct WireGuard, not proxied.

Magic DNS: resolve every node in your mesh by hostname (machine.yourtailnet) without touching your public DNS.

ACL-based access control: define which users and devices can reach which services using the same HuJSON policy format as Tailscale.

DERP relay support: configure your own DERP relay servers or use Tailscale's public DERP map for NAT traversal fallback.

REST + CLI management: create namespaces, generate auth keys and manage peers via the headscale CLI or the HTTP REST API.

Under 50 MB RAM at idle — run it on any VPS alongside your existing workloads.

When to use this solution?

1

Remote access to internal services

Put your VPS fleet, your office NAS and every team laptop on the same private mesh, and internal dashboards, databases and admin panels stop needing a public port at all. A service bound to a mesh address is reachable by your team from anywhere and invisible from the internet — which removes an entire class of exposure without a single firewall rule to maintain per service.

2

Private links between servers

Connect servers hosted in different places — a ServOrbit VPS, a machine at another provider, a rack in an office — into one flat network with stable addresses. Application-to-database traffic then travels over a direct WireGuard tunnel rather than the public internet, and the address a service uses to reach another does not change when either machine moves or its public IP changes.

3

Leave the Tailscale free tier without changing clients

The Tailscale free plan caps you at a small number of users and keeps your network map in someone else's cloud. Headscale speaks the same protocol, so the official clients on Linux, macOS, Windows, iOS and Android connect to it unchanged — you point them at your own `--login-server` and the number of users and devices becomes your business, at the fixed cost of one small VPS.

Deploy Headscale on your VPS

Guide optimized for ServOrbit Cloud VPS.

01

Order a ServOrbit VPS

512 MB of RAM is plenty: Headscale only coordinates key exchange and distributes the network map, so the control server is idle most of the time. It is not in the data path — traffic between your nodes flows peer-to-peer — so its bandwidth needs are minimal and it happily shares a VPS with other services.

02

Point a domain at the VPS

Headscale needs a domain: server_url is baked into the configuration and every client is registered against that exact HTTPS address. Create an A record such as vpn.example.com pointing to your VPS IP before deploying — the certificate is issued and renewed automatically. Changing the domain afterwards means re-registering every node, so choose one you will keep.

03

One-click deploy from the marketplace

Open your ServOrbit dashboard → Marketplace → Network → Headscale → Deploy. An init container writes the configuration on first start — the 100.64.0.0/10 address range, Magic DNS, SQLite storage and Tailscale's public DERP map for NAT traversal — then headscale serve starts and answers on port 8080 behind the HTTPS vhost.

04

Create a user and an authentication key

Management is done through the CLI inside the container. Create a user with docker exec headscale users create ops, then issue a key for it: docker exec headscale preauthkeys create --user --reusable --expiration 24h. Reusable keys let you enrol several machines during one session; short expirations keep a leaked key from being useful later.

05

Connect your machines

Install the standard Tailscale client on each device and point it at your server instead of the cloud: tailscale up --login-server https://vpn.example.com --authkey . On mobile, enter the same server URL in the app's account settings. Check the result with docker exec headscale nodes list — every registered machine appears with its mesh address, and the nodes can reach each other immediately.

Frequently asked questions

No — that is the whole point. Headscale reimplements the Tailscale control server, so the official Tailscale clients for Linux, macOS, Windows, iOS and Android connect to it unmodified. The only difference for your users is the `--login-server` flag (or the custom server URL field in the mobile app) pointing at your own domain instead of Tailscale's cloud.

Complementary solutions

Networking & VPN

Activate Headscale on your infrastructure.

Dedicated Cloud VPS — IPv4 included, European datacenter, support included. Your data never leaves your server.

Recommended configuration: 512 MB RAM · 1 vCPU