[HN Gopher] An open source, self-hosted implementation of the Ta...
___________________________________________________________________
An open source, self-hosted implementation of the Tailscale control
server
Author : quyleanh
Score : 307 points
Date : 2025-04-03 00:23 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| telotortium wrote:
| Should add the project name, Headscale, to the title
|
| Headscale has been on HN many times.
| mountainriver wrote:
| Love headscale, we just took it to production and it's been great
| syntaxing wrote:
| As in you rolled out an internal service for the whole
| company?!
| sshine wrote:
| I'd love to see a write-up on that.
|
| Especially in the unlikely event that you used Nix for the
| deployment.
| benley wrote:
| I've done exactly that: headscale in production at work, a
| few hundred client devices, infrastructure mostly powered
| by nix. What would you want to hear about it?
| squiggleblaz wrote:
| * Does it work well? * Do you recommend it? * Do your
| users care? * Is it difficult? Do you have to maintain it
| or is it basically set it and forget it? * What was
| memorable about setting it up? * Why did you go for
| Headscale vs Tailscale or Netbird or some other solution?
| sshine wrote:
| > _headscale in production at work_ - How
| much effort do you put into key management compared to
| plain WireGuard? - How automated is the onboarding
| process; do you generate and hand over keys? - How
| do you cope without the commercial Tailscale dashboard?
| - Do you run some kind of dashboard or metrics system?
| - How long did it take to set up? - Were there any
| gotchas?
| avtar wrote:
| > How do you cope without the commercial Tailscale
| dashboard?
|
| There are a couple open source dashboard options but
| right now only this one comes to mind:
| https://github.com/tale/headplane
| cassianoleal wrote:
| As opposed to what? This seems pretty normal.
|
| We considered it as well but there was a feature missing that
| meant we couldn't use it for one of our main requirements.
| Had that not been the case, we'd have rolled it out.
| mrklol wrote:
| Mind sharing which feature?
| cassianoleal wrote:
| Honestly I'm hazy on the details but we're running a
| fairly complex environment in GCP with PSC everywhere,
| connections to on-prem and other external environments,
| and something wouldn't quite work due to all that.
|
| Sorry I can't provide any more details but I really don't
| remember the specifics. We were in touch with Tailscale
| engineers and they offered some workarounds that we had
| already worked out but that wouldn't help us achieve what
| we were after.
| linsomniac wrote:
| I've been running headscale for 2.5 years and it's been pretty
| good. We use our gmail domain for logging in, which gives a big
| benefit that users can self-serve their devices. Unlike with
| OpenVPN in the past where ops had to hand off the certs and
| configs. Really the only downside has been when they
| accidentally connect to the tailscale login server instead of
| our own and then can't figure out why they can't reach any
| services. We use user groups to set up what services users can
| access.
|
| We are still running the old headscale, because we have some
| integrations that will need to be ported to the new control
| plane. According to "headscale node list | wc" we have ~250
| nodes, most of them are servers.
|
| One thing I really don't love about tailscale some of the magic
| it does with the routing tables and adding firewall rules, but
| it has mostly not been an issue. Tailscale has worked really
| quite well.
| 3abiton wrote:
| This looks interesting! What's the added value over wireguard +
| openwrt setup?
| watusername wrote:
| Your devices will connect to each other peer-to-peer (even
| behind complex NATs) with no manual configuration, subject to
| ACLs you centrally manage. It just works.
|
| People sometimes dismiss Tailscale as "just" a WireGuard
| orchestrator, but it's actually much more than that - From a
| product perspective, WireGuard is just an implementation
| detail.
| compootr wrote:
| it's wireguard that doesn't make me hate myself :)
| usagisushi wrote:
| It's a mesh VPN, so peers communicate directly without
| additional delay.
|
| I opted for Netbird myself because Headscale's UI felt too
| basic for me back then. Has that improved over the years
| probably?
| udev4096 wrote:
| How is netbird? Is it more stable than tailscale/headscale?
| How is your performance while streaming a video?
| usagisushi wrote:
| They are both based on WireGuard (kernel-space and user-
| space `wireguard-go`), so I guess there's no significant
| difference in performance for typical usage.
|
| In terms of stability, Netbird has been pretty good for me.
| I've been using Netbird as the backhaul network for my
| laptop, phone and inter-site k3s cluster for several years
| without major issues.
|
| One major downside of Netbird is that its Android client
| can be quite a battery drainer [1]. (It keeps your fingers
| warm during winter, though!) As for Tailscale, it offers
| some neat features like Funnel, which is missing in
| Netbird, but in my case, covered by DNS and k8s Ingress.
|
| [1]: https://github.com/netbirdio/netbird/pull/3379
| avtar wrote:
| Netbird seems (or perhaps is?) newer. It didn't have some
| basic features baked in when I last looked into it, e.g.
| you couldn't switch accounts on the client
| https://github.com/netbirdio/netbird/issues/3273 and if I
| had an account associated with a single team, then that
| account couldn't be invited to or be associated with
| additional teams.
| sunshine-o wrote:
| Some do not want/have a fixed IP address or anything listening
| on their home network.
|
| Tailscale or having Headscale hosted somewhere else allows you
| to do that.
| alabastervlog wrote:
| Tailscale's value prop is "Wireguard that the merely somewhat-
| technically-inclined can set up and manage unassisted". Across
| tons and tons of clients (my AppleTVs connect to my Tailscale
| network, this took maybe a minute to configure--and they can
| act as gateways)
| pluto_modadic wrote:
| wonder if some of the bugs with self-managing it have been worked
| out :)
| snvzz wrote:
| Headscale has been serving me well for half a year now. It is
| great, to the point I have no idea how I lived without a
| tailscale network before.
|
| It is packaged in openbsd, and that package is the server I am
| using.
| pilif wrote:
| Keep in mind that for many use cases (mobile access, GUI on
| macOS), this relies on the official Tailscale clients keeping the
| ability to set the control server.
|
| The moment the inevitable enshitification will start at
| Tailscale, this feature will go away.
|
| I'm saying this as a currently super happy Tailscale customer who
| was burned multiple times in the past by other companies being
| sold or running out of VC money
| risho wrote:
| arent most of the the tailscale clients open source aside from
| the gui portion of the non open source os's?
| pilif wrote:
| Yes they are, unless you're using a mainstream OS and/or want
| to use a GUI, which is probably the most common use case.
| __float wrote:
| While the GUI is somewhat helpful, at the end of the day
| it's not the key piece, and it could easily be rebuilt.
| notpushkin wrote:
| I think the whole Windows client is closed. On macOS though
| you can use it from the command line just fine (apart from a
| couple quirks due to a completely different VPN
| implementation [1]).
|
| [1]: they have _three_ : https://tailscale.com/kb/1065/macos-
| variants
| squiggleblaz wrote:
| From https://github.com/tailscale/tailscale
|
| "This repository contains the majority of Tailscale's open
| source code. Notably, it includes the tailscaled daemon and
| the tailscale CLI tool. The tailscaled daemon runs on
| Linux, Windows, macOS, and to varying degrees on FreeBSD
| and OpenBSD. The Tailscale iOS and Android apps use this
| repo's code, but this repo doesn't contain the mobile GUI
| code."
|
| and
|
| "The macOS, iOS, and Windows clients use the code in this
| repository but additionally include small GUI wrappers. The
| GUI wrappers on non-open source platforms are themselves
| not open source."
|
| Moreover, there's https://github.com/tailscale/tailscale-
| chocolatey to aid the build process. I haven't built it or
| run it.
|
| On the other hand, while I suppose the Windows app is
| probably reasonably straightforward to replicate, I guess
| it would be much harder to produce an iOS or Android app
| because of the vagaries of mobile programming.
| notpushkin wrote:
| Thanks, I stand corrected then!
|
| Android client is open source (and you can get in from
| F-Droid, even), so that only leaves iOS I guess.
| freedomben wrote:
| Yep, Tailscale takes a pretty reasonable approach to that
| IMHO. Open source on platforms that are open source. I
| think that works out pretty well because it meets people
| where they are. For example the people who care about
| open source (and thus are running linux or android) get
| their open source needs met, and people who don't care
| about open source strongly or at all (as evidenced in
| part by them running closed/proprietary OSes) such as mac
| or windows users are also met where they are. Of course
| this also helps protect their business model because then
| competitors can't just take the open source versions and
| run off with them, and the number of linux users is quite
| small compared to mac and windows so it keeps the
| majority of the client closed while still providing the
| openness to those who truly care about it.
|
| *In my perfect world everybody would care about open
| source, but the evidence is pretty clear that only a tiny
| minority of people actually do, even among engineers
| pilif wrote:
| _> I guess it would be much harder to produce an iOS or
| Android app because of the vagaries of mobile
| programming._
|
| on iOS you also need a special entitlement that's only
| available on specific request and only to known
| developers, so practically impossible for any open source
| project to acquire.
| dcow wrote:
| This was true in 2015. It is not true anymore.
| sixothree wrote:
| Tailscale clients are the thing I am least happy about with
| Tailscale. Specifically mobile clients and battery usage.
|
| The reason I can't use Tailscale at work is because it routes
| traffic through servers we can't control.
|
| I would _love_ to use tailscale at work. It would solve so many
| problems. I am okay with being forced to open ports. But
| tunneling traffic through them is extremely worrysome.
| pilif wrote:
| _> Specifically mobile clients and battery usage._
|
| yes. Battery usage is super bad, mainly because of their DNS
| features which forces every DNS resolution to go through
| their network extension. At least recent updates have stopped
| the background power usage when you disconnect from the
| network in the app.
|
| _> But tunneling traffic through them is extremely
| worrysome._
|
| it only does that in case of super bad NATs that make the
| usual NAT traversal techniques impossible. And presumably,
| the traffic is end-to-end-encrypted, so it doesn't matter if
| they have to be in the loop.
|
| If you don't trust them to properly end-to-end encrypt, then
| it really doesn't matter whether they are in the loop for
| forwarding a packet or not because if you don't trust them to
| encrypt properly, all bets are off to begin with.
|
| If you trust them however, it doesn't matter where the
| traffic is flowing through because only the intended machine
| is able to decrypt it.
| dcow wrote:
| On the battery topic I'm curious if you have anything more
| than anecdotal evidence. A basic full tunnel wg network
| extension doesn't affect battery in a noticeable or
| unacceptable way, in my experience. Is tailscale's
| implementation doing more in a way you can isolate and
| attribute to poor battery?
| sixothree wrote:
| I can see it (tailscale) in my battery usage on multiple
| devices. 20 hours of background usage per day is a bit
| much if you ask me.
| CharlesW wrote:
| FWIW: On iOS 18.4 my Battery report for the last 10 days
| is ~128h of background activity, using ~2% of my battery
| life.
| techsupporter wrote:
| > The reason I can't use Tailscale at work is because it
| routes traffic through servers we can't control.
|
| You can run your own DERP servers and exclude the Tailscale
| ones even if you don't run your own Headscale server:
| https://tailscale.com/kb/1118/custom-derp-servers
| miki123211 wrote:
| I may be misremembering, but I think they have said somewhere
| that Headscale is actually revenue positive for them.
|
| That feels right to me. Headscale is mostly used by home
| labbers and small hobby users, it competes with self-hosted
| OpenVPN and WireGuard, not Pulsesecure, Cisco Anyconnect or
| GlobalProtect. It's a way to introduce Tailscale to people who
| love to try new shiny tech in their spare time, but don't want
| to give up control over their infrastructure.
|
| _Those people will then bring their Tailscale expertise and
| enthusiasm to work_. Work really doesn 't like managing IT
| infrastructure unless it's one of their core competencies.
|
| Sure, some companies will actually choose Headscale over
| Tailscale proper, but I suspect that's a small minority
| (especially if you take company size and the money involved
| into account). That's just cost of revenue, not unlike Facebook
| advertising or billboards on the side of a road in Silicon
| Valley.
| comex wrote:
| > I think they have said somewhere that Headscale is actually
| revenue positive for them.
|
| I have the same memory. But they may not feel that way
| forever. Many a company started by attracting developers with
| a generous free tier or open-source offering, then started to
| clamp down once the going got tough.
|
| Heck, it happened to one of Tailscale's competitors,
| ZeroTier, which used to release their client software under
| GPLv3 but eventually switched to BSL.
| SuperShibe wrote:
| Every few months I come back to this repo to check if they
| finally got Tailnet lock running or if someone security audited
| them in the meanwhile. Unfortunately neither of these things seem
| to make any progress and thus, I've grown uncertain in how much I
| can trust this as a core part of my infrastructure.
|
| The entire premise of Tailscale SaaS builds on creating tunnels
| around your firewalls, then enabling the user to police what is
| allowed to be routed through these tunnels in a intuitive and
| unified way.
|
| Headscale seems to have nailed down the part of bypassing the
| firewall and doing fancy NAT-traversal, but can they also fulfill
| the second part by providing enough of their own security to make
| up for anything they just bypassed, or will they descend to just
| being a tool for exposing anything to the internet to fuck around
| with your local network admin? To me, not giving your Tailscale
| implementation any way for the user to understand or veto what
| the control server is instructing the clients to do while also
| not auditing your servers code at all sure seems daring...
| gpi wrote:
| One of the maintainers work for tailscale now.
| wutwutwat wrote:
| maintainer's employment != security audit
| gpi wrote:
| My thinking is their time is divided now and could lead to
| less efforts spent on headscale.
| palotasb wrote:
| Not compared to the previous state where he worked for an
| unrelated company and only had his free time to
| contribute to Headscale.
| themgt wrote:
| c.f. https://github.com/juanfont/headscale/issues/2416
| nativeit wrote:
| > Headscale seems to have nailed down the part of bypassing the
| firewall and doing fancy NAT-traversal
|
| Did they really roll-their-own for those functions? I thought
| this was just a control layer on top of Tailscale's stock
| services on the backend, are they facilitating connections with
| novel methods? Apologies if I'm asking obvious questions, I use
| ZeroTier pretty regularly, but I am not too familiar with
| Tailscale.
| bingo-bongo wrote:
| They have a really great in-depth blog post describing how
| they do it: https://tailscale.com/blog/how-nat-traversal-
| works
| throawayonthe wrote:
| i think they mean headscale's implementation specifics
| jacobtomlinson wrote:
| This is a fascinating read!
| xrd wrote:
| Can you share why you use ZeroTier over Tailscale? I run
| several headscale control planes and it really is nice to
| self-host. But, I'm curious about other options.
| password4321 wrote:
| Not OP but I'm on ZeroTier because it was one of the best
| free tiers available before Tailscale could run as a
| Windows service.
|
| Also I believe it implements a lower layer of the network
| stack so more options are supported, though I haven't
| needed to investigate in detail.
| password4321 wrote:
| More ZeroTier 3 years ago:
| https://news.ycombinator.com/item?id=30283987#30284754
| bananapub wrote:
| tailnet lock seems way way less important for headscale than
| tailscale, given you personally control the headscale infra.
| botto wrote:
| This is my thought as well, if you are in control then you
| also control which nodes go on your tailnet
| codethief wrote:
| Depends on your threat model. Mine definitely includes one of
| my servers getting compromised. (Which, tbh, is probably more
| likely than Tailscale getting hacked.)
| SuperShibe wrote:
| only until someone finds a zeroday in headscale (remember, it
| never got audited) or until the server running headscale
| itself gets compromised. Especially in countries where
| getting a dedicated public IPv4+IPv6 from your ISP is hard-
| impossible and you'd have to rely on a server hosted
| externally (unless you're large enough to make deals with the
| ISP) some company hosting your server still retains at
| minimum physical control over your headscale infra. For why
| this is a problem, see the recent Oracle cloud breach.
| voxadam wrote:
| Does it run on Plan 9?
| bradfitz wrote:
| Ha! But seriously, it's written in Go, so probably.
| udev4096 wrote:
| How does headscale hold up when you're streaming video over
| jellyfin/plex?
| scottyeager wrote:
| Do you mean when using it as a relay because p2p connectivity
| isn't possible? The preferred operating mode of Tailscale
| networks is for the bulk of traffic to go p2p, using various
| tricks for NAT and firewall traversal.
| cassianoleal wrote:
| I've used it extensively to stream video across continents. No
| issues as long as you can get a P2P connection going. If it
| needs to go through a DERP server, then it may suffer but in my
| experience that's pretty rare.
| watusername wrote:
| > If it needs to go through a DERP server, then it may suffer
| but in my experience that's pretty rare.
|
| It's semi-frequent in my case, and it's painful every time it
| does that since Tailscale's official DERP servers are very
| slow (they seem to have some aggressive QoS). It would be
| nice if Tailscale supported using regular TURN servers so I
| could just use one of the hosted solutions.
| cassianoleal wrote:
| You can self-host DERP if you're up for it.
| LilBytes wrote:
| Yep and most of us are already using Subnet routers it's
| not technically much harder.
|
| Finding a cloud or VPS provider with free or cheap
| bandwidth (egress and ingress) is likely the biggest
| issue.
| Happily2020 wrote:
| If you're interested in self-hosting your orchestration server,
| you can look into Netbird. It's a very similar tool, but has the
| server open sourced as well. So you have a self-hosted control
| server with a nice GUI and all the features the paid version
| does.
|
| https://netbird.io/knowledge-hub/tailscale-vs-netbird
| yamrzou wrote:
| Does it do the fancy NAT-traversal Tailscale does?
| mrbluecoat wrote:
| Yes: https://www.netbird.io/knowledge-hub/netbird-network-
| routes
| davidcollantes wrote:
| Compared to Headscale, Netbird has so many moving pieces! It
| looks robust, and powerful, and featureful... yet, self-hosting
| Headscale is super simple, and less demanding.
| mynameisvlad wrote:
| I've been slowly moving everything over from Tailscale to
| Netbird and aside from some shenanigans with Tailscale taking
| over the entire CGNAT route, it works wonderfully!
|
| Tailscale is still running for now, but I'm getting closer and
| closer to decommissioning it and switching entirely to Netbird.
| unixfox wrote:
| No IPv6 though. Which is real deal breaker:
| https://github.com/netbirdio/netbird/issues/46
| infogulch wrote:
| I think it would be neat if headscale allowed peering /
| federating between instances. (Maybe _after_ the ACL rework.) One
| of the main problems is address collisions.
|
| So here's my proposal: commit to ipv6-only overlay network in the
| unique local address (ULA) range, then split up the remaining 121
| bits into 20 low bits for device addresses (~1M) and 101 high
| bits that are the hash of the server's public key. Federate by
| adding the public key of the other instance and use policy and
| ACLs to manage comms between nodes.
|
| I think it's a nice idea, but the maintainer kradalby said it's
| out of scope when I brought it up in 2023:
| https://github.com/juanfont/headscale/issues/1370
| aborsy wrote:
| How much is the risk of my devices being compromised if Tailscale
| coordination server is compromised, and tailnet lock is enabled?
| 1vuio0pswjnm7 wrote:
| "To me, not giving your Tailscale implementation any way for the
| user to understand or veto what the control server is instructing
| the clients to do while also not auditing your servers code at
| all sure seems daring..."
|
| This statement sugggests that publishing the Headscale control
| server source code is not enough to allow the user to "understand
| or veto what the control server is instructing the clients to
| do".
|
| If using the Headscale control server, the user can "understand
| or veto" anything "the control server is instructing the clients
| to do". This may be accomplished by reading, editing and
| compiling the source code.
|
| If using the Tailscale control server, the user can only
| "understand or veto what the control server is instruction the
| clients to do" to the extent that the Tailscale company permits.
| The user is prohibited from editing or compiling the source code.
|
| Not all users want the option to read, edit and compile third
| party software that they use. Some users may be comfortable
| relying on the ongoing assurances of companies funded by Silicon
| Valley VC. For those users that want the option of 100% open
| source projects, not dependent on venture capital, Headscale can
| be useful.
|
| The author of Headscale calls the Tailscale coordination server
| "essentially a shared dropbox for public keys".
___________________________________________________________________
(page generated 2025-04-03 23:01 UTC)