Tailscale vs Headscale: What Self-Hosting the Control Plane Changes

The quick answer: Headscale replaces Tailscale's hosted coordination service with a Tailscale-compatible control server that you operate. That moves device registration, public-key distribution, IP and DNS configuration, route approvals, policy compilation, coordination metadata, upgrades, backups, and recovery into your trust boundary. It does not automatically put ordinary peer traffic through the Headscale host. Tailscale clients still encrypt the data plane with WireGuard, still prefer direct peer-to-peer paths, and still need a DERP or peer relay when direct connectivity fails. Self-hosting Headscale also does not automatically self-host identity, relays, client updates, or every Tailscale feature.

Evidence and version status: This is a documentation-backed comparison, not a TechGeeks deployment test. Official release feeds showed Tailscale v1.102.2 and Headscale v0.29.3 as the latest non-prerelease releases checked on August 15, 2026. Headscale v0.29.3 states a minimum supported Tailscale client version of v1.80.0. Recheck all three facts and the feature pages on publication day.

The Short Version

• Choose Tailscale-hosted coordination when you want the provider to operate the control service and DERP fleet, and you value the integrated admin console, identity integrations, audit features, posture controls, support, and lower maintenance burden.
• Evaluate Headscale when control-plane custody is a real requirement and you are prepared to run a public HTTPS service, protect its database and secrets, operate OIDC or manual registration, test client compatibility, maintain policy, monitor it, and recover it.
• Do not choose Headscale merely to keep file transfers local. Direct Tailscale connections are already peer to peer. A control-plane change does not alter a working direct data path.
• Do not assume Headscale removes Tailscale's relays. Its default DERP map can include Tailscale's free DERP servers. You must deliberately operate and test a different relay map if relay custody matters.
• Do not call policy syntax "compatible" without a version. Headscale v0.29.x supports ACLs, grants, policy tests, SSH tests, node attributes, and several autogroups, but current documentation still lists gaps including device posture, IP sets, Funnel, Serve, and network flow logs.
• Treat migration as a security and recovery project. Inventory identities, tags, routes, DNS, policy tests, client platforms, key expiry, relay use, and break-glass access before moving any important device.

Interactive Control-Plane Switchboard

Start with the fixed center row, then open each decision. It separates the part you are moving from the parts that remain distributed across clients, relays, identity, and applications.

Architecture decision model

What moves, what stays, and what becomes your job

The coordinator changes sides. The encrypted client data plane remains at the endpoints.

Tailscale-hostedTailscale operates coordination, the admin service, control storage, and its distributed DERP fleet.

Same Tailscale clients
Same WireGuard data plane
Same direct-path preference

Headscale self-hostedYou operate coordination state, policy delivery, identity integration, updates, monitoring, backup, and recovery.

1. Coordination custody

Moves: device records, public keys, assigned addresses, routes, DNS settings, and compiled policy distribution.

Decision: is local custody worth owning a public, security-critical service?

Changes

2. Packet path

Stays: clients encrypt and decrypt traffic. A direct connection does not pass through either coordinator.

Decision: do not self-host merely to change a path that is already direct.

Does not change

3. Relay path

Depends: Headscale can advertise Tailscale DERP, an embedded DERP, separate custom relays, peer relays, or a combination.

Decision: inspect the actual map and test direct, peer-relay, and DERP outcomes.

ConfigurableAvailability risk

4. Identity boundary

Moves partly: Headscale can use one OIDC provider or administrator-approved registration. The external identity provider remains a separate trust dependency when enabled.

Decision: test join, reauthentication, revocation, and IdP outage.

Changes

5. Policy surface

Similar, not identical: both use huJSON policy concepts, but selectors, posture, app capabilities, tests, and defaults must be checked against the exact versions.

Decision: require policy tests plus real allowed and denied connections.

Parity check

6. Operations and recovery

Moves: Headscale database migration, configuration compatibility, TLS, secrets, monitoring, backup, restore, and break-glass access become operator work.

Decision: restore a backup before putting the service in the critical path.

Your responsibility

Stop condition: if you cannot name the independent administration path and show a successful isolated restore, the Headscale option is not operationally ready.

Architecture: Coordination Is Not The Data Plane

Documented fact: Tailscale separates a control plane from a data plane. The coordination service tracks devices, authenticates registrations, distributes allowed peers' public keys, assigns addresses, shares endpoints, configures DNS and routes, and turns high-level policy into information clients can enforce. The data plane runs on the devices and carries end-to-end encrypted WireGuard traffic.

Component	Tailscale-Hosted	Headscale	Traffic Consequence
Coordinator	Tailscale operates it	You operate a compatible implementation	Distributes state; it is not the ordinary packet forwarder
Client	Tailscale client	Tailscale client pointed at a custom login server	Encrypts, filters, routes, and transports packets
Direct path	Peer to peer when possible	Peer to peer when possible	Does not traverse either control server
DERP	Tailscale's distributed map and fleet	Map chosen by the operator; defaults may still include Tailscale DERP	Relays already-encrypted packets when needed
Identity	Supported provider or custom OIDC through Tailscale	Manual approval, pre-authenticated keys, or one configured OIDC provider	Controls enrollment; it does not replace application login
Policy	Hosted editor/API/GitOps and Tailscale's feature set	File or API/database state compiled by Headscale	Clients enforce distributed packet filters; local firewalls still matter

Headscale describes itself as an open-source, self-hosted implementation of the Tailscale control server for a single tailnet, aimed at self-hosters, hobbyists, and small open-source organizations. Tailscale's clients officially support a custom control server URL. This is more precise than calling Headscale "self-hosted Tailscale": the coordinator is replaced, while the client software and protocol behavior remain central to the result.

What Self-Hosting Actually Changes

• Custody of coordination state: Tailscale documents device metadata, public keys, certificates, DNS, preferred DERP regions, routes, and policy as control-plane data. With Headscale, the corresponding server database, configuration, policy, and service keys live in infrastructure you administer.
• Administrative authority: Headscale's local CLI and authenticated API can manage users, nodes, routes, tags, registration, and policy. Protecting the host, Unix socket, API keys, OIDC client secret, database, and backups becomes your responsibility.
• Availability ownership: Headscale must be reachable over public HTTPS so devices can register and maintain control connections. You own DNS, certificates, host patching, capacity, monitoring, and an administration path that does not depend on Headscale itself.
• Feature selection: You receive the capabilities implemented by the Headscale release and compatible clients, not an entitlement-equivalent copy of the Tailscale service. Headscale has no built-in web admin interface; its documentation lists community interfaces that the Headscale authors do not maintain.
• Logging and privacy choices: Headscale says it instructs clients to disable Tailscale's central client-log submission by default. That does not prove that every external dependency is gone: your OIDC provider, DNS and certificate services, software distribution, and selected DERP servers can still be outside your infrastructure.

TechGeeks recommendation: write a dependency ledger before deployment. For each of coordination, identity, DNS, TLS, relay, client packages, backups, monitoring, and alert delivery, name the operator and failure path. "Self-hosted" is not an architecture diagram.

What Does Not Change

The endpoints still hold the private node keys and perform encryption. The coordinator distributes public keys and network state. Moving that role does not patch a compromised laptop, secure a weak service behind a subnet router, encrypt an unencrypted application before it reaches the local Tailscale interface, or replace application authorization. It also does not make exit-node or subnet-router operators unable to observe traffic they legitimately forward after Tailscale decryption on that endpoint.

Direct-versus-relayed behavior still depends on both networks. Tailscale's current connection sequence starts through DERP for discovery, attempts a direct UDP path, then prefers an available peer relay before remaining on DERP. All three connection types are WireGuard-encrypted. Headscale changes which coordinator supplies peer and relay information; it does not repeal NAT, blocked UDP, hard NAT, latency, or bandwidth limits.

DERP: The Commonly Missed Boundary

DERP stands for Designated Encrypted Relay for Packets. Tailscale documents DERP as a discovery channel and last-resort relay. Because private node keys remain on clients, a DERP server forwards encrypted WireGuard packets and cannot decrypt their payload. That payload guarantee does not prove the absence of relay metadata, nor does it guarantee direct-path performance.

Documented Headscale behavior: the embedded DERP server is disabled by default. When enabled, Headscale adds it to the loaded map, which ordinarily also includes Tailscale's free DERP servers. Setting the DERP URL list empty can remove the default map. Headscale warns that relying on one embedded DERP creates a single point of failure, and says its embedded relay has no speed or throughput optimizations. It also uses UDP 3478 for STUN in addition to HTTPS.

TechGeeks recommendation: separate three decisions: control-plane custody, relay custody, and direct-path performance. If relay custody matters, operate at least two independently failed relay locations or keep a deliberately accepted external fallback. Verify the exact map with tailscale debug derp-map, network conditions with tailscale netcheck, and each important peer with tailscale ping plus tailscale status. A result marked direct, peer-relay, or relay is evidence for that device pair at that time, not for the whole tailnet.

Identity And OIDC Are Separate From Coordination

Tailscale's hosted service delegates user authentication to supported identity providers, including custom OIDC providers. Headscale can approve registrations through an administrator, pre-authenticated keys, or one external OIDC provider. Its OIDC implementation supports discovery, optional PKCE, admission filters for domain, email, or group, and profile synchronization from standard claims.

The important difference is broader than "cloud identity versus local identity." An operator can self-host Headscale while still depending on an external OIDC service, or can operate both and create a larger recovery dependency. Headscale supports only one configured OIDC provider. Its documentation also says OIDC groups can filter who may join but cannot be used directly in policy rules. Email and username can change; the combined issuer and subject identifier is intended to be stable, but it is less readable in policy. Switching OIDC providers currently requires manual handling of stored provider identifiers.

TechGeeks recommendation: use verified email, PKCE with S256, narrow admission filters, short-lived single-use pre-authenticated keys, and a documented non-tailnet administration path. Test four separate events: a new user joins, a disabled user cannot reauthenticate, an expired node is denied as intended, and the IdP is unavailable. Existing device behavior during an IdP outage depends on node expiry and cached state; do not infer it from a successful login test.

ACL And Policy Differences Matter At The Edges

Both products use a human-friendly JSON policy model and both default to broad connectivity when no restricting policy is loaded. Tailscale recommends grants for new work because ACLs remain supported but do not receive new features. Headscale v0.29.x supports grants and ACLs together, policy tests and sshTests, Tailscale SSH, node attributes, route approval, and a subset of autogroups. The v0.29.0 release labeled policy and SSH tests beta while compatibility coverage expanded.

Do not miss the empty-policy trap: Headscale says no loaded policy allows all node-to-node traffic. An empty object also allows all; an explicit empty grants array denies all. Tailscale likewise starts with an allow-all policy. The rule language itself is additive: matching grants add capabilities rather than letting a more specific rule override a broad earlier grant. A narrow-looking rule does not subtract access already granted elsewhere.

Policy Area	Tailscale-Hosted	Headscale v0.29.x Snapshot	Required Check
ACLs and grants	Both; grants recommended	Both supported	Run syntax tests and real connections
Policy tests	Hosted editor/API/GitOps testing	tests and sshTests supported; introduced as beta in v0.29.0	Confirm current status and failure behavior
Device posture	Supported feature, with plan-dependent details	Not supported in current policy limitations	Remove posture-dependent assumptions
IP sets	Available in current policy system	Not supported in current policy limitations	Expand to supported explicit selectors
OIDC groups	Identity/group integrations vary	Admission filter only, not policy selectors	Create explicit Headscale groups or stable user mappings
Flow and audit evidence	Configuration audit logs and optional flow logging	Application logs/metrics; feature page marks network flow logs unsupported	Design host and endpoint logging separately

TechGeeks recommendation: keep policy in version control, require tests for allowed and denied flows, and stage it on disposable users and nodes. Then perform a real denied connection from an identity that should fail. A parser success proves syntax; a policy test proves only the cases written; a successful allowed flow says nothing about access that should have been denied.

Upgrades Become A Compatibility Project

With Tailscale-hosted coordination, Tailscale operates control-service updates and backups, while its shared-responsibility guidance leaves client updates to the customer. With Headscale, you must coordinate the server release, its configuration schema, database migrations, policy behavior, API clients or community UI, and the Tailscale client floor.

Headscale's current upgrade guide requires moving from one stable minor release to the next and selecting the latest patch in each minor. The v0.29.0 release blocks skipped minor versions and minor-version downgrades. That release also changed wildcard policy meaning, hostname handling, tags, configuration keys, and database behavior. These are operational changes even when WireGuard itself has not changed.

1. Inventory headscale version, every tailscale version, installation method, database type, policy source, OIDC provider, custom UI/API consumer, and DERP map.
2. Read every intervening stable release note. Do not jump from "old" to "latest" without the documented minor sequence.
3. Stop the service as directed, take a full protected backup, and copy the exact old package or binary plus configuration.
4. Test the upgrade on a restored copy that cannot answer the production hostname.
5. After production upgrade, prove health, node list, policy load, OIDC, route approvals, DNS, direct and relayed paths, denied flows, restart persistence, and monitoring.

Backups Must Restore A Coordinator, Not Just A File

Headscale's official upgrade guide recommends backing up before migrations. For the standard installation it identifies /etc/headscale for configuration and /var/lib/headscale for the data directory, including the SQLite database. The project recommends SQLite for its use cases; PostgreSQL remains supported but is described as maintenance mode. A full backup can also contain TLS or service keys, OIDC secrets, API credentials, user and node records, and policy, so it is both recovery material and sensitive security data.

TechGeeks recommendation: encrypt the backup, keep a versioned off-host copy, and record the Headscale binary/package version and checksum beside it. Restore the old binary, old configuration, and pre-migration database as one set. Do not point an older binary at a database already migrated by a newer minor release. Restore first under an isolated hostname or blocked egress, validate it, then perform the controlled DNS or address cutover.

• Backup acceptance: the archive includes configuration, data directory, database-consistent state, policy, relay-map files, TLS/ACME state where applicable, service unit overrides, version record, and restore instructions.
• Restore acceptance: the service starts on the recorded version; /health and /version answer; users, nodes, tags, routes, policy, and DNS are present; no test client is silently admitted; and one isolated client can register and reach only its allowed destination.
• Break-glass acceptance: an operator can reach the host, obtain logs, disable registration, fix an invalid stored policy, rotate exposed secrets, and restore service without first needing the failed tailnet.

Failure And Recovery: Separate The Components

Failure	What May Still Work	What Stops Or Stales	Recovery Proof
Coordinator unavailable	Tailscale documents pre-established connections and cached policy continuing	New connections, key changes, registrations, and policy updates	Existing and new-flow tests, then fresh map/policy after recovery
Embedded Headscale DERP unavailable	Direct paths, peer relays, or other cached DERP regions	Pairs dependent on that relay	Map inspection and path result for each critical pair
OIDC unavailable	Already valid nodes until their relevant expiry/state changes	New OIDC enrollment, reauthentication, and OIDC-based SSH checks	Denied new login plus successful break-glass administration
Invalid Headscale policy	Depends on whether failure occurs at write, reload, or startup	New policy may be rejected; stored invalid policy can block startup	headscale policy check, documented direct-database repair, clean restart
Failed database migration	Only the pre-upgrade service if its complete state remains available	Coordinator startup or correct state	Atomic old-version restore, then health and client acceptance suite
Lost TLS/DNS path	Existing data paths may persist temporarily	Control reconnection, registration, and eventual recovery	Public certificate chain, hostname, HTTPS, control reconnection

Tailscale documents that clients cache policy and the DERP map, including across a client restart, but this is not permission to run indefinitely without coordination. Key expiry, endpoint movement, new peers, route changes, revocation, and stale policy eventually matter. For Headscale, the same control role creates the same class of dependency, but TechGeeks did not perform a Headscale outage to establish exact survival time or client-version behavior.

Security, Privacy, Legal, And Recovery Boundaries

• Security: A control server is a key-distribution and authorization authority even though it is not the plaintext data path. Tailscale's Tailnet Lock adds client-verified signatures to limit unauthorized node insertion by its control plane. Headscale's current feature page does not list Tailnet Lock, so do not assume that protection is available or equivalent. Restrict Headscale's host, metrics, debug, Unix socket, API, backups, and administration path.
• Privacy: Self-hosting can move coordination records out of Tailscale's hosted control service, but does not prove that relay, identity, DNS, certificate, update, or client-log metadata stays local. Document retention and access for every remaining system.
• Legal: Access only systems and identities you are authorized to administer. Hosting location, identity data, logs, employee monitoring, software licenses, and provider terms can create obligations that this technical comparison does not resolve.
• Recovery: Keep at least one independent route to the server, protected OIDC and DNS recovery credentials, a tested full-state backup, the exact prior binary, and a written process to revoke API keys, pre-authenticated keys, OIDC secrets, TLS keys, and potentially admitted nodes after compromise.

A compromised coordinator does not automatically reveal past WireGuard payloads because endpoint private keys do not live there. It can still create severe current risk by changing policy and network state or attempting to introduce unauthorized peers. Conversely, a clean coordinator cannot rescue a compromised endpoint that already holds valid keys and application credentials.

A Practical Decision Workflow

1. Name the requirement. "I prefer self-hosting" is not enough. State whether the driver is coordination metadata custody, external dependency reduction, policy control, cost, learning, or a formal hosting constraint.
2. Draw the actual paths. Show coordinator, clients, OIDC, public DNS/TLS, direct connections, peer relays, DERP regions, subnet routers, exit nodes, applications, logs, backups, and alert delivery.
3. Build a feature contract. List every used Tailscale capability and mark supported, different, absent, or untested in the exact Headscale release. Include mobile enrollment, policy selectors, posture, DNS, routes, SSH, Taildrive, API/UI, audit evidence, and key expiry.
4. Price operations honestly. Include public-host patching, monitoring, certificates, backup storage, restore drills, sequential upgrades, compatibility testing, security response, and operator time.
5. Canary a separate control domain. Use disposable identities and clients first. Do not strand the only remote administration path on the system being tested.
6. Require exit criteria. Migration is ready only after allowed and denied policy tests, identity revocation, direct and relay path checks, controlled coordinator and IdP failures, and an isolated restore all meet written expectations.

Decision rule: stay with Tailscale-hosted coordination when the requirement is ordinary private connectivity and you do not want to operate a security-critical public service. Choose Headscale only when control-plane custody or the project itself is valuable enough to justify feature gaps and lifecycle ownership. If the real requirement is relay custody, solve relay architecture explicitly; replacing only the coordinator is incomplete.

Verification Checklist

This is the acceptance evidence a real deployment should collect. Record UTC time, server and client versions, source and destination identity, network vantage, expected result, actual result, and relevant logs for each check.

• Control: confirm public HTTPS, certificate chain, /health, /version, server logs, metrics exposure, node inventory, and control reconnection after restart.
• Identity: enroll one personal node and one tagged service node; reject an unauthorized identity and unauthorized tag; expire a disposable node; revoke its admission material; and test the planned IdP outage response.
• Policy: validate the file, run tests and sshTests, connect from an allowed source, fail from a denied source, and confirm local host firewall and application authorization still enforce their own boundaries.
• Routes and DNS: verify MagicDNS or configured DNS, split zones, subnet route approval, return routing, exit-node authorization, IPv4 and IPv6, and one negative route test.
• Path: collect tailscale netcheck, tailscale debug derp-map, tailscale ping, and tailscale status for critical pairs. Test from at least the normal LAN and a mobile or restrictive external network.
• Failure: in a controlled window, observe an established connection and a genuinely new connection while coordination is unavailable; separately test IdP and chosen relay failure. Do not combine failures until each one is understood.
• Restore: recover the full backup on an isolated host using the recorded version, inspect state before exposing it, then run the same identity, policy, DNS, route, path, restart, and alert checks.

Unperformed Lab Work And Evidence Limits

Not performed: TechGeeks did not deploy Tailscale v1.102.2 against Headscale v0.29.3, enroll desktop or mobile clients, compare policy compilation, capture packets, force direct-to-relay transitions, measure throughput or latency, interrupt coordination or OIDC, migrate a tailnet, upgrade an older database, or restore a Headscale backup for this draft. The preceding checks are a planned reader or future lab method, not reported results.

• Official documentation establishes architecture and supported behavior; it does not prove that a particular NAT, firewall, client build, identity provider, or mobile platform will behave correctly in your environment.
• End-to-end encryption through DERP proves the relay cannot decrypt the WireGuard payload; it does not prove zero metadata exposure or acceptable relay performance.
• A current feature checklist does not prove bug-for-bug parity, future compatibility, scale, support response, or suitability for regulated production.
• A successful backup command does not prove recoverability. Only an isolated restore plus application-level acceptance does.
• A successful connection does not prove least privilege, and a failed connection does not identify whether policy, routing, DNS, firewall, identity, service health, or relay choice caused the failure.
• The current release numbers are a dated snapshot, not an instruction to upgrade without reading intervening notes and advisories.

Publication-Day Rechecks

• Reopen the Tailscale changelog and official GitHub releases; replace v1.102.2 if a newer stable client exists, and review Tailscale security bulletins.
• Reopen Headscale releases and security advisories; replace v0.29.3 and its v1.80.0 minimum-client claim if they changed. Read every newer breaking-change and upgrade note.
• Recheck Headscale's stable feature, policy, OIDC, DERP, client-support, upgrade, FAQ, and web-interface pages. In particular, verify posture, IP sets, policy-test status, Funnel, Serve, network flow logs, Tailnet Lock, OIDC groups, database guidance, and sequential upgrade requirements.
• Recheck Tailscale's control/data-plane, connection-type, DERP, identity, grants, posture, Tailnet Lock, logging, and shared-responsibility pages for architectural or entitlement changes.
• Open every TechGeeks link below and the current live slug index. Do not publish until the version, compatibility, feature-gap, security-advisory, and internal-link checks have recorded outcomes.

Related TechGeeks Reading

• Tailscale vs WireGuard vs Cloudflare Tunnel vs Reverse Proxy
• Remote Access Without Opening Router Ports
• WireGuard Home VPN: Secure Remote Access for Your Homelab
• Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
• What Should You Monitor in a Homelab?

References

• Tailscale: Control and data planes
• Tailscale: Connection types and DERP servers
• Tailscale: Supported SSO identity providers
• Tailscale: Grants and ACLs
• Tailscale: Device posture and logging
• Tailscale: Tailnet Lock
• Tailscale: Shared responsibility model
• Headscale: Project scope, requirements, and feature compatibility
• Headscale: Client support, API, and web interfaces
• Headscale: Registration methods and OpenID Connect
• Headscale: Policy and DERP
• Headscale: Upgrade and backup and FAQ
• Headscale v0.29.3 release and Tailscale v1.102.2 release
• IETF RFC 7636: Proof Key for Code Exchange and OpenID Connect Core 1.0
• WireGuard protocol and cryptography
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations