Headplane donne enfin une interface web à Headscale, le serveur de contrôle Tailscale auto-hébergé
Headplane, mis en avant le 9 octobre 2026 par selfh.st, ajoute à Headscale — la réimplémentation open source du serveur de contrôle de Tailscale — une interface web avec SSO OIDC, SSH à distance et gestion des réglages du tailnet. C’est la pièce qui manquait pour auto-héberger son propre réseau mesh sans renoncer à l’ergonomie.
9 octobre 2026. La newsletter Self-Host Weekly met en avant Headplane, une interface d’administration pour Headscale. Depuis 2020. Headscale offre une réimplémentation open source du serveur de contrôle de Tailscale — le moyen d’auto-héberger son propre « tailnet » WireGuard — mais uniquement en ligne de commande. Aujourd’hui. Headplane comble ce vide avec une interface web, du SSO OIDC et du SSH à distance. Pourquoi c’est important : la promesse de Tailscale sans sa dépendance au cloud devient accessible à ceux qui ne veulent pas administrer leur réseau mesh à coups de headscale en CLI.
Headscale était puissant, mais réservé aux CLI
Pour comprendre ce qu’apporte Headplane, il faut rappeler ce qu’est Headscale. Tailscale est un réseau maillé bâti sur WireGuard : chaque machine rejoint un « tailnet » chiffré et peut joindre les autres comme sur un LAN, sans exposer de port. Son point sensible, pour les tenants du self-hosting, est le serveur de contrôle : c’est lui qui distribue les clés, applique les ACL et orchestre le mesh — et chez Tailscale, il est fermé et hébergé.
Headscale réimplémente ce serveur de contrôle en open source. Vous l’installez sur votre propre machine et vous récupérez la maîtrise complète du plan de contrôle : les ACL, les clés, la DNS, tout est à vous. Le prix à payer, jusqu’ici, était l’ergonomie : pas d’interface, une configuration en YAML et des commandes headscale pour chaque opération. C’est exactement la friction qui décourageait une partie des self-hosters, habitués à des outils comme Tailscale ou Netmaker qui offrent un tableau de bord.
Ce que Headplane apporte concrètement
Headplane est une interface d’administration complète qui se branche sur un Headscale existant. Son positionnement est simple : on ne remplace pas le plan de contrôle, on lui ajoute la couche de gestion qui lui manquait.
Les fonctionnalités annoncées dessinent un vrai poste de pilotage. La vue d’ensemble du tailnet expose l’état des machines et du réseau pour chaque nœud. La gestion des réglages donne accès à ce qui était enfoui dans le fichier de configuration de Headscale : serveurs DNS, enregistrements, contrôle d’authentification, paramètres réseau. Le SSO permet de déléguer l’authentification à un fournisseur OpenID Connect — Google Workspace, Azure/Entra ID, Okta, ou tout autre compatible. Enfin, le SSH web à distance ouvre un terminal vers les machines du tailnet directement depuis le navigateur, en s’appuyant sur Tailscale SSH.
Le tout se déploie en Docker (méthode recommandée), en mode natif sur un serveur, ou en mode limité pour un simple test. L’image officielle est ghcr.io/tale/headplane, et l’interface se sert ensuite sur http://localhost:3000/admin.
Le déploiement Docker, pas à pas
Le point de départ est un Headscale 0.26.0 ou plus récent, déjà en marche. Headplane s’installe par-dessus, via un simple fichier compose.yaml :
services:
headplane:
image: ghcr.io/tale/headplane:latest
container_name: headplane
restart: unless-stopped
ports:
- "3000:3000"
volumes:
- "./config.yaml:/etc/headplane/config.yaml"
- "./headplane-data:/var/lib/headplane"La première connexion exige une clé d’API Headscale, à générer côté serveur :
# Ajustez la durée de validité selon vos besoins
headscale apikeys create --expiration 90dPour activer les fonctions avancées — notamment la gestion du réseau depuis l’interface — Headplane doit pouvoir lire et écrire le fichier de configuration de Headscale, et accéder au socket Docker. Les deux services doivent alors tourner dans le même environnement Docker, avec un volume partagé pour la config et le socket monté en lecture seule :
services:
headplane:
image: ghcr.io/tale/headplane:latest
container_name: headplane
restart: unless-stopped
ports:
- "3000:3000"
volumes:
- "/chemin/vers/config.yaml:/etc/headplane/config.yaml"
- "/chemin/vers/headscale/config.yaml:/etc/headscale/config.yaml"
- "/var/run/docker.sock:/var/run/docker.sock:ro"
headscale:
image: headscale/headscale:0.26.0
container_name: headscale
restart: unless-stopped
command: serve
labels:
me.tale.headplane.target: headscale
ports:
- "8080:8080"
volumes:
- "/chemin/vers/headscale/config.yaml:/etc/headscale/config.yaml"Deux détails comptent plus qu’ils n’en ont l’air. Le label me.tale.headplane.target est indispensable pour que Headplane retrouve Headscale. Et le montage du socket Docker est une surface d’exposition : montez-le en lecture seule, ou passez par un proxy comme Tecnativa/docker-socket-proxy si vous préférez ne pas donner le socket directement.
En production, Headplane se met derrière un reverse proxy (Caddy, Nginx ou Traefik) et se sert sous un chemin /admin, exactement comme la console d’administration de Tailscale.
Le vrai bénéfice : la souveraineté sans l’austérité
Ce qui rend Headplane intéressant, ce n’est pas une fonctionnalité isolée, c’est qu’il abaisse le coût d’entrée d’une architecture que beaucoup de self-hosters convoitent sans oser la franchir : posséder son plan de contrôle réseau.
Les avantages de Headscale restent intacts. Vous ne dépendez plus du service hébergé de Tailscale pour l’identité de vos machines, vos ACL ou votre DNS. Vos clés et votre topologie ne quittent pas votre infrastructure. Et vous gardez la compatibilité avec les clients Tailscale existants, ce qui évite de reconfigurer chaque appareil.
Headplane ajoute la couche qui manquait : l’administration au quotidien. La délégation d’accès via OIDC est le point le plus décisif pour un usage à plusieurs — famille, association ou petite équipe — où donner la CLI à tout le monde n’est tout simplement pas raisonnable. Le SSH à distance, lui, élimine l’aller-retour entre l’interface et un terminal séparé pour dépanner une machine.
Il faut rester lucide sur les limites. Headplane est un projet jeune, porté par un mainteneur principal, et il dépend de Headscale, lui-même un projet au rythme de développement soutenu mais pas institutionnel. Le risque de rupture de continuité — le syndrome du mainteneur unique — est réel, et il faut le mettre dans la balance avant d’en faire un pilier de son infrastructure.
Verdict
Si vous avez déjà un Headscale en production administré en CLI, ajouter Headplane vous coûte un conteneur et vous apporte l’interface, le SSO et le SSH web sans toucher à votre plan de contrôle : c’est un gain net, à condition de monter le socket Docker en lecture seule. Si vous hésitiez à quitter le service hébergé de Tailscale à cause de l’ergonomie, c’est le moment de tester : l’écart d’expérience s’est réduit à presque rien. Et si vous tenez une infrastructure critique, n’en faites pas encore le cœur de votre réseau — gardez Headplane en périphérie, derrière un reverse proxy avec TLS, et surveillez la santé du projet avant de lui confier davantage.