Headscale: Self-hosted Tailscale-Alternative für die private Cloud

In Post 2 dieser Serie haben wir Tailscale als UX-Goldstandard im Mesh-VPN-Segment vorgestellt. Mit einem ehrlichen Caveat: Die Control-Plane ist proprietär, läuft auf AWS in den USA und ist offiziell nicht self-hostbar. Wer das Featureset will und gleichzeitig volle Souveränität braucht, landet zwangsläufig bei einer anderen Lösung.

Diese Lösung heißt Headscale. Es ist die quelloffene Community-Reimplementierung der Tailscale-Coordination-Server-API unter BSD-3-Lizenz, kompatibel mit den offiziellen Tailscale-Clients und vollständig self-hostbar.

Und damit beginnt der ehrlichste Teil dieser Serie: Wir nutzen Headscale bei Infralovers selbst. Unsere interne Infralovers Cloud läuft seit über einem Jahr produktiv mit Headscale als Control-Plane. Dieser Beitrag ist deshalb nicht nur Evaluation, sondern auch Praxisbericht aus dem eigenen Betrieb.

Stand Mai 2026, betrachtet wurden Headscale v0.28.0

Was Headscale ist

Headscale ist eine Open-Source-Reimplementierung der Tailscale-Control-Plane in Go, veröffentlicht unter BSD-3-Lizenz. Es ist nicht das, was Sie installieren, um sich ins Netz zu verbinden, sondern das, was Sie betreiben, damit andere sich verbinden können.

Drei Eigenschaften prägen das Projekt:

• Community-getragen, mit Tailscale-Brücke: Die Maintainer Juan Font Alonso und Kristoffer Dalby führen das Projekt seit Jahren. Einer der beiden arbeitet bei Tailscale Inc. und darf während der Arbeitszeit beitragen. Andere Maintainer reviewen seine Contributions. Das ist eine ehrliche, transparente Brücke zwischen dem kommerziellen Produkt und der Community-Variante.
• Bewusster Scope: Das erklärte Ziel sind „self-hosters, enthusiasts und kleinere Open-Source-Organisationen". Eine Headscale-Instanz bedient genau ein Tailnet (Single-Tailnet-Design). Multi-Tenant ist nicht im Scope.
• Reif, aber kein Enterprise-Produkt: Aktuelle Release ist v0.28.0 vom 4. Februar 2026, 38.5k GitHub-Stars, 132 Releases insgesamt. Das Projekt ist aktiv, aber bewusst klein gehalten.

Klare Differenzierung zu Tailscale Cloud und NetBird: Bei Headscale gibt es kein gehostetes Angebot, kein Subscription-Modell und keine kommerzielle Hotline. Dafür gibt es volle Kontrolle.

Architektur in einem Bild

Fünf Punkte erklären den Aufbau:

• Der Headscale Server ist die Control-Plane, koordiniert Keys, Knoten, ACLs und MagicDNS-Einträge. Er liegt nicht im Datenpfad.
• Die offiziellen Tailscale-Clients verbinden sich gegen Headscale statt gegen die Tailscale-Cloud (tailscale up --login-server=https://hs.example.com).
• Das WireGuard-P2P-Mesh zwischen den Knoten ist identisch zum nativen Tailscale-Datenpfad. Headscale beeinflusst nur, wer wen kennen darf.
• DERP-Relays dienen als TURN-Fallback. Sie können eigene DERP-Server registrieren oder das öffentliche DERP-Netz von Tailscale mitnutzen.
• OIDC-IdP für Authentifizierung, ACL-Datei in HuJSON für Policies, beides versionierbar in Git.

Da Headscale nur Koordination übernimmt, kommt es mit erstaunlich wenig Hardware aus. Eine kleine VM reicht für mittlere Setups locker.

Features im Überblick

Was Headscale heute liefert:

• MagicDNS mit eigener Zone. Hostnamen werden automatisch im Tailnet aufgelöst.
• ACLs als HuJSON-Datei, vollständig versionierbar in Git und damit GitOps-kompatibel.
• Tags für Knoten (z. B. tag:server für VMs, tag:ci für ephemere CI-Runner).
• Ephemere Knoten, die nach einer Session automatisch wieder verschwinden, ideal für GitHub-Actions oder andere CI-Workloads.
• Pre-Auth-Keys für automatisches Onboarding, mit konfigurierbarer Gültigkeitsdauer und Tag-Zuordnung.
• Subnet-Router und Exit-Nodes wie bei Tailscale.
• OIDC-Auth mit Authelia, Authentik, Google, Kanidm, Keycloak, Microsoft Entra ID. Generisch funktioniert jeder OIDC-konforme Provider.

Womit Headscale (noch) nicht punktet

Ein ehrliches Wort zu den Lücken, bevor wir zum Praxisbericht kommen:

• Keine offizielle Web-UI. Das Drittanbieter-Projekt headscale-ui (BSD-3, aktiv gepflegt, 2.6k Stars) füllt die Lücke, ist aber eben nicht „first-class" aus dem Projekt selbst.
• OIDC-Gruppen sind in ACLs nicht nutzbar (Stand v0.28.0). Wer feingranulares Group-RBAC will, muss in Headscale-Tags abbilden.
• Mobile-Login-Flow ist holpriger als bei Tailscale Cloud, weil die offizielle App standardmäßig zur Tailscale-Cloud verbindet. Auf Android funktioniert der Custom-Server-Override gut, auf iOS braucht es einen Browser-Schritt.
• Single Tailnet pro Instanz. Multi-Tenant-Setups erfordern mehrere Headscale-Instanzen.
• Operative Verantwortung liegt komplett bei Ihnen. Patches, Backups, TLS, IdP-Anbindung, Monitoring: alles Ihre Baustelle.

Wie wir Headscale für die Infralovers Cloud nutzen

Wir haben uns vor über einem Jahr für Headscale entschieden, als wir unsere interne Infralovers Cloud auf eine saubere, souveräne Basis stellen wollten. Hier die ehrliche Architektur:

Hosting: Eine dedizierte Instanz hs-control läuft ausschließlich die Headscale-Control-Plane. Andere VMs tragen die Applikationen. Die Trennung ist bewusst: Ein Anwendungsproblem darf die VPN-Verfügbarkeit nicht mitreißen, und der Blast-Radius eines Incidents bleibt klein.

IaC: Das gesamte Setup ist mit Terraform konfiguriert und mit Ansible provisioniert. Das Repo lebt in Git, Änderungen gehen durch Pull Requests, und das CI deployed automatisiert.

Container-Runtime: Podman, nicht Docker. Vor Headscale läuft Caddy als TLS-Reverse-Proxy. Caddy hat sehr guten Support für Headscale und übernimmt die Let's-Encrypt-Zertifikate ohne Konfigurations-Akrobatik.

VPN-First-Security: SSH (Port 22) ist auf beiden VMs nur über das VPN erreichbar. Direkter SSH-Zugriff aus dem Internet ist per Firewall geblockt. Wer Wartung machen will, geht zuerst ins VPN. Für den Notfall steht eine Konsole zur Verfügung, falls das VPN selbst Probleme hat.

CI/CD-Integration: GitHub-Actions-Runner verbinden sich als ephemere Knoten ins Tailnet, ausgestattet mit dem Tag tag:ci. Sie holen sich nur die Berechtigungen, die der Tag in der ACL erlaubt, deployen, und verschwinden danach wieder. Es gibt keine persistenten Credentials in der CI-Konfiguration, was Auth-Key-Rotation und Incident-Response massiv vereinfacht.

MagicDNS: Hostnamen werden automatisch über das VPN aufgelöst. Wir bekommen damit den gleichen Komfort wie bei Tailscale, aber komplett unter eigener Kontrolle und unter unserer eigenen DNS-Zone.

Backups: Die Headscale-SQLite-Datenbank, die ACL-Datei und sonstige Konfiguration liegen auf einem persistenten Volume. Restic sichert das Volume täglich auf einen S3-kompatiblen Storage, mit "retention policy" und Health-Checks.

Wichtiger Hinweis: Headscale ist in unserem Setup als „Lab / Semi-Production" klassifiziert. Wir verteilen damit Admin-Zugriff auf Infrastruktur und schützen interne Services. Wir vermarkten den eigenen Headscale nicht als externen Dienst, und wir setzen es bewusst nicht für Kunden-Workloads ein.

Wenn Sie diesen Stack interessant finden: Wir prüfen aktuell parallel auch eine Migration zu NetBird für bestimmte Teile, weil die mobile Erfahrung dort runder ist. Das Schöne an diesem Setup ist, dass eine solche Migration evaluierbar bleibt, ohne dass uns ein Vendor das diktiert. Wenn Sie mehr über NetBird lesen wollen gibts es hier einen gute Post von uns dazu!

EU-Souveränität: bei Headscale endlich auf Ihrer Seite

Souveränität ist der rote Faden dieser Serie, und Headscale ist das Stück, bei dem die Antwort vollständig in Ihren Händen liegt:

• Headscale selbst ist BSD-3-Open-Source und jurisdiktionsneutral. Die Souveränität wird durch das Hosting-Ziel bestimmt, nicht durch den Anbieter.
• Hosting-Wahl: Bei uns Hetzner-Cloud in Nürnberg und Falkenstein, also vollständig EU. Sie können genauso IONOS, OVH, Open Telekom Cloud oder eine eigene On-Prem-Infrastruktur wählen.
• Keine Telemetrie nach außen: Im Default sendet Headscale nichts an Tailscale Inc. Sie können den DERP-Layer ebenfalls selbst betreiben, sodass kein Byte das eigene Netz verlässt.
• Audit: Voller Source-Code-Zugriff, eigene Logs und eigene Metriken. Sie wissen jederzeit, was passiert.

Für NIS2- und DORA-Kontexte bedeutet das ein sauberes Mapping: Der VPN-Anbieter sind Sie selbst, was die Lieferantenbewertung deutlich vereinfacht. Es bleibt nur die klassische Sub-Processor-Bewertung des Compute-Hosters.

Wo Headscale heute glänzt, und wo nicht

Stärken

• BSD-3, komplett self-hostbar, keine Vendor-Bindung.
• Volle Kompatibilität mit den offiziellen Tailscale-Clients.
• Geringe Betriebskosten: Eine kleine VM reicht für mittlere Setups.
• Hervorragend für IaC-Stacks (Terraform, Ansible, Podman/Docker, GitOps).
• Klares Tag- und ACL-Modell, perfekt für CI-Use-Cases mit ephemeren Nodes.

Limitierungen

• Keine offizielle Web-UI, headscale-ui als Drittanbieter-Lösung.
• OIDC-Gruppen aktuell nicht in ACLs verwendbar.
• Mobile-Login-Flow umständlicher als bei Tailscale Cloud.
• Single-Tailnet, kein Multi-Tenant.
• Operative Verantwortung vollständig beim Betreiber.

Wann Headscale die richtige Wahl ist

Vier Szenarien, in denen Headscale aus unserer Sicht klar nach vorne rückt:

1) "Wir wollen Tailscale-Komfort, aber volle Souveränität."

Genau dafür wurde Headscale gebaut. Sie behalten Mesh-VPN-Komfort, MagicDNS und die offiziellen Clients und übernehmen die Control-Plane vollständig selbst.

2) "Wir bauen eine private Cloud unter eigener Kontrolle."

Mit Hetzner, IONOS oder OVH plus Headscale haben Sie einen vollständig EU-betriebenen Mesh-Zugang ohne Drittanbieter im Datenpfad. Genau das ist unser eigener Stack bei der Infralovers Cloud.

3) "Wir lieben IaC und CI/CD."

Terraform, Ansible, Podman und Headscale ergeben einen GitOps-tauglichen VPN-Stack. Ephemere Knoten für Deployment-Pipelines sind ein Killer-Feature, das wir bei uns täglich nutzen.

4) "Wir wollen keine laufenden Lizenzkosten."

Headscale ist kostenlos. Sie zahlen nur die VM und Ihre Zeit. Für kleine Teams ist die Total-Cost-of-Ownership deutlich unter dem, was Tailscale Standard ($8/User) oder NetBird Team ($5/User) auf Jahressicht erzeugen.

Fazit

Headscale ist die Wahl, wenn Sie den Komfort des Tailscale-Ökosystems mögen, aber Control-Plane und Verbindungsdaten selbst in der Hand halten wollen. Wir nutzen es bei Infralovers seit über einem Jahr und betreiben damit unsere eigene private Cloud auf Hetzner. Die Trade-offs (keine offizielle Web-UI, holpriger Mobile-Login, operative Verantwortung) sind real, aber für Teams mit IaC- und CI/CD-Affinität sehr gut tragbar.

Damit ist diese Serie inhaltlich rund. Den abschließenden direkten Vergleich von NetBird, Tailscale und Headscale entlang der Achsen Self-Hosting, private Cloud, Lizenzkosten, Client-Komfort und EU-First gibt es in Post 4.

Wenn Sie den Aufbau einer privaten, souveränen Cloud planen, ein NIS2- oder DORA-Programm aufsetzen oder eine konkrete Headscale-Implementierung umsetzen wollen, unterstützen wir Sie bei Infralovers gerne. Wir teilen unsere eigene Erfahrung aus der Infralovers-Cloud-Architektur, und kombinieren das mit unseren Schulungsangeboten zu Sovereign Cloud, NIS2-Compliance und Cloud Native Essentials.