Nice business decision. Just like their reaction to Headscale, I'm reminded Tailscale 'gets it' when interacting with the dev community and why their popularity will continue to grow.
Although not sure why that's preferable to converting it once-off, so it's still not something a user has to worry about, but then the old way is done with.
Now that I think of it Adyen did this to us a few years back. We’ll probably stay in the v5 branch until they politely poke us to upgrade again in another 5 years…
This way also supports users who have scripts or workflows that produce the old form of ACLs. If you had a single cut-off date, those scripts would presumably need to be updated.
We are indeed converting the old syntax to grants behind the scenes. In fact, we have been quietly doing this for months :)
As tczMUFlmoNk mentioned further down, we wanted to allow both syntaxes in perpetuity to account for scripts, Terraform configs, version-controlled policy files, and other automation that may rely on the original syntax.
We will provide a button on the JSON editor in our admin console to do a one-click conversion for anyone who would like to make a hard switch.
> Headscale is an open source alternative to the Tailscale coordination server and can be self-hosted for a single tailnet. Headscale is a re-implemented version of the Tailscale coordination server, developed independently and completely separate from Tailscale. Headscale is a project that complements Tailscale — with its own independent community of users and developers. Tailscale does not set Headscale’s product direction or manage the community, and neither prohibits nor requires employees from contributing to Headscale.
> Our opinion is that Headscale provides a valuable complement to Tailscale: It helps personal users better understand both how Tailscale works and how to run a coordination server at home. As such, Tailscale works with Headscale maintainers when making changes to Tailscale clients that might affect how the Headscale coordination server works, to ensure ongoing compatibility.
We're really happy Tailscale users at home. No bullshit, just works.
I can't say for certain (I do not work for TailScale, nor have I ever) but I suspect you are right.
TailScale was _immediately_ surfaced in our team's "what could we replace open-vpn with?" conversation recently... precisely because most of us _are_ using it at home and have nothing but praise.
> I'm sure a lot of their sales funnel is just nerds like us using Tailscale at home, and then bringing it to their employers.
Honestly, I don't know why this stopped being the dominant strategy. Matlab, Adobe, Solidworks, and many other tools used to be free for students. It's not hard to see how people working with certain software while in school translates to using that same software outside. The same is true for at home! You get frustrated with whatever BS thing your work has and then ask your boss if you can use X instead.
I think it stopped because they got too big. Becoming the de facto tool they figured they could charge students and hobbiests too. I'm pretty sure this just lead to more piracy and open source solutions. I mean Coca-Cola still advertises... they sure aren't doing it for brand recognition... everyone knows who they are (same with McDonalds!). They do it to associate feelings. These companies should still do those student and hobbiest versions for the same reasons. It prevents others from displacing you. Companies aren't going to complain about the price and pirate your stuff instead, they have the money. Only hobbiests and students do that stuff...
There is one problem... I've seen employees at certain places use personal accounts for business work. Worse, I've seen them do this despite the business already having seats! I don't know why this is going on, but maybe we should do a bit of peer pressure if we want to ensure we keep those free hobbiest licenses. Plus, it puts your business in a legally dubious area. Not likely to get sued, but it sure isn't legal...
Agreed on the licensing concerns. I hate seeing members of commercial entities discuss using personal/non-commercial products like that. I moved to a new company and wanted to use Obsidian for some individual note-taking purposes, then realized I could only use it for 30 days before I needed a commercial license if I did anything work related with it. I know Obsidian proper wouldn't even know if I used it this way, but I avoided doing so until I got word that Obsidian was changing their commercial licensing policy.
The ones that have an MBA-driven anti-user mindset IMO:
Apple, Google, Microsoft, Meta, Oracle, Adobe, Nvidia, AMD1) hobbiests that are obsessed with self-hosting can use it -- tailscale will never see a penny from them anyways
2) some businesses will consider headscale as an escape hatch de-risking if tailscale were to be purchased out by an extortionist (like broadcom's acquisition of VMware)
3) It signals they are doing business in a position of strength: businesses don't buy software, they buy solutions to problems
Competition can be beneficial for all parties involved. If the Headscale devs make novel contributions and solve problems Tailscale didn't think of or figure out themselves, Tailscale can copy Headscale just as Headscale copies Tailscale. Competition has this benefit of distributing research expenditures.
I think it is easy to forget that even monopolies are bad for monopolies. They can benefit by being fat and lazy, but this is at the cost of larger future profits. It's "safer", but there's plenty of competitive markets where there is little risk of failure. At least compared to the risk that naturally exists.
5) Headscale users may convert to Tailscale users.
That can happen if Headscale was implemented by a enthusiastic employee who later leaves. Company learned to like the benefits but no longer has the support. This makes a natural conversion. The same thing happens if Headscale fizzles out.
I really just don't see how Tailscale really has much, if anything, to lose from Headscale. It definitely has things to gain! The only reason to go after Headscale would be if they are greedy and irrationally fearful. Which the action itself would scare a lot of its users. Tailscale really is in touch with its users and honestly, I'm not sure there's anything negative I have to say about them. They're not creating enemies, they're paying attention to users, and they're just focusing on making a great product. Seems like the ideal strategy that we'd want all businesses to follow.
They hired the dev: https://tailscale.com/blog/opensource#the-open-source-coordi...
Fun fact: Tailscale have an almost-assuredly-accurate count of Headscale users due to how few people disable the Tailscale client's telemetry which by default sends them real-time events about everything you do on a Headscale network. See KB1011: https://tailscale.com/kb/1011/log-mesh-traffic
“Each Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.io). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network.”
It's possible to opt out of this spying on Unix/Windows/Mac by starting Tailscale with `--no-logs-no-support` or `TS_NO_LOGS_NO_SUPPORT=true` environment variable (see https://tailscale.com/kb/1011/log-mesh-traffic#opting-out-of...), but it is not currently possible to opt out in the Android/iOS clients: https://github.com/tailscale/tailscale/issues/13174
This is why they had the data telling them they should hire the Headscale dev to nip that competition in the bud before it had any chance to usurp their business by overtaking them in mindshare using their own client. Definitely a sound business decision, but it really really irked me when I realized I was feeding Tailscale detailed usage data for everything I did on my supposedly “““private””” Headscale network despite having no business relationship with them.
For an example of how invasive this is for the average user, this person discovered Tailscale trying to collect ~18000 data points per week about their network usage based on the number of blocked DNS requests for `log.tailscale.com`: https://github.com/tailscale/tailscale/issues/15326
The privacy-adversarial behavior made me switch from Headscale to NetBird for my personal network now that it's available in FreeBSD Ports: https://www.freshports.org/security/netbird/
18000 data points per week seems IMHO pretty low (only 1.7 requests per minute for a whole network? Unlikely, even my Android phone does way more that 1.7 requests per minute just to ad networks, nevermind everything else on the network summed), it's probably way more.
18000 data points is also a lie, that's a different issue - the issue of UDP DNS sucking in general so your average application/OS keeps reissuing requests if they think the UDP packet got dropped.
Connections != Requests
Telemetry consisting of an open/close event pair would be, like, one entire SSH session, or one RDP session. Even HTTP has supported Keep-Alive since 1997.
> Fun fact: Tailscale have an almost-assuredly-accurate count of Headscale users due to how few people disable the Tailscale client's telemetry which by default sends them real-time events about everything you do on a Headscale network. See KB1011: https://tailscale.com/kb/1011/log-mesh-traffic
That is not true. We actually instruct all the clients to send no logs - since at least three years:
https://github.com/juanfont/headscale/blame/main/hscontrol/t....
And also in the config example:
https://github.com/juanfont/headscale/blob/main/config-examp...
That said, I would have loved to know how many nodes use Headscale... :)
This needs to be more widely known.
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...
> It's possible to opt out of this spying on Unix/Windows/Mac by starting Tailscale with `--no-logs-no-support` or `TS_NO_LOGS_NO_SUPPORT=true` environment variable
Network flow logs are available to help you understand which devices are connecting to one another over time, that is, the flow of traffic across your tailnet.
These logs strictly do not contain any information about client operations or contents of network traffic.
Network flow logs must be enabled[1].
[0] https://tailscale.com/kb/1011/log-mesh-traffic
[1] https://tailscale.com/kb/1219/network-flow-logs#enable-netwo...
Yes, but don't feel bad, because this seems designed to be confusing and easy to overlook. See the privacy policy: https://tailscale.com/privacy-policy#information-we-collect-...
“When you use the Tailscale Solution, we collect limited metadata regarding your device used to access the Tailscale Solution, such as: the device name; relevant operating system type; host name; IP address; cryptographic public key; user agent (where applicable); language settings; date and time of access to the Tailscale Solution; logs describing connections and containing statistics about data sent to and from other devices (“Inter-Node Traffic Logs”); and version of the Tailscale Solution installed.” (emphasis mine)
Here's a Tailscale client startup with telemetry enabled, which is the silent default:
2025/04/13 17:02:07 logtail started
2025/04/13 17:02:07 Program starting: v1.82.0, Go 1.24.2: []string{"/usr/local/bin/tailscaled", "-port", "41641", "-tun", "tailscale0", "-statedir", "/var/db/tailscale"}
2025/04/13 17:02:07 LogID: b933623d2f5012930c72af6593b1a94f36749b5495076c937bde51dd620d21e5
2025/04/13 17:02:07 logpolicy: using system state directory "/var/db/tailscale"
2025/04/13 17:02:07 dns: using dns.openresolvManager
2025/04/13 17:02:07 ifconfig destroy: exit status 1
ifconfig: interface tailscale0 does not exist
2025/04/13 17:02:07 wgengine.NewUserspaceEngine(tun "tailscale0") ...
2025/04/13 16:29:20 You have disabled logging. Tailscale will not be able to provide support.
2025/04/13 16:29:20 logtail started
2025/04/13 16:29:20 Program starting: v1.82.0, Go 1.24.2: []string{"/usr/local/bin/tailscaled", "-port", "41641", "-tun", "tailscale0", "-statedir", "/var/db/tailscale", "--no-logs-no-support"}
2025/04/13 16:29:20 LogID: b933623d2f5012930c72af6593b1a94f36749b5495076c937bde51dd620d21e5
2025/04/13 16:29:20 logpolicy: using system state directory "/var/db/tailscale"
2025/04/13 16:29:20 dns: using dns.openresolvManager
2025/04/13 16:29:20 ifconfig destroy: exit status 1
ifconfig: interface tailscale0 does not exist
2025/04/13 16:29:20 wgengine.NewUserspaceEngine(tun "tailscale0") ...For anyone wondering, Lammy provided the head of journalctl for tailscaled.service. I got similar results.
I think my confusion comes down to there being two different types of logging. It is the network flow logs that are on the enterprise.
Per the privacy policy statement, this does not set off any alarm bells for me. Reason being that the capacity to create logs would necessitate that language. But I definitely don't like that they are collecting that much information. Thanks, I'll change /etc/defaults/tailscaled
But changing ACLs and many other changes can be done from the WebUI without needed authorization from a host. So I have to authorize the change in the UI - but Tailscale could really also do it without my consent. Would be great to have a mode that _ANY_ change to the Tailscale network must be authorized from a trusted node with a detailled changeset. So I could be sure that Tailscale can't tamper with my network.
Sure, I could run Headscale and completely work without the Tailscale servers. But I prefer to pay them the small monthly fee to not have to manage this central service of my fleet.
It's not for everyone, but if you're into control of your netfilter tables, it's certainly not for you.
Are you saying you need an easy way to match up a Tailscale user’s email to a user on the host? (Ie, sam@tailscale.com matches to the username sam)
If that’s the case, take a look at the local-part section here: https://tailscale.com/kb/1193/tailscale-ssh#users
If that’s not what you meant, could you clarify a bit further? I’d love to understand how to close this gap for you.
While I have you here, it would also be neat if there were a way to supplement regular SSH's auth with tailscale SSH's keys. Specifically for situations where the target machine has lost internet connectivity but you can still get onto the same network as it. More robotics problems. :) Can understand if this would never "work" for tailscale's auth model.
On the second item- this is interesting. I definitely see the reason for asking :) We actually don’t use SSH keys for Tailscale SSH, since the auth is handled within Tailscale (more info at https://tailscale.com/kb/1193/tailscale-ssh#authentication-a...). I’ll think more about this. Do you have a break-glass setup with a normal SSH key for this today?
In fact, comma usage seems inconsistent for the last element of some of the nested objects.
To be fair, I don't remember what's the json rule either and would need a quick lookup.
But it doesn't accept things like the example that omits an intermediate comma:
{
"foo": 42
"bar": 123
}
> hujson: line 3, column 5: invalid character '"' after object value (expecting ',' or '}')I assume everyone using Tailscale are opting for "simple code and adminstration" instead of "let me pierce NAT and handle Wireguard tunelling myself". On that point of view, "Identity management" is part of "stuff" that Tailscale helps you in the first place. So why not use it as the "Identity management" solution as well?
When you use `tailscale serve`, you get the headers Tailscale-User-Login, Tailscale-User-Name and Tailscale-User-Profile-Pic that identifies who connected thru the tailscale endpoint. https://tailscale.com/kb/1312/serve#identity-headers
On a separete side note, if you had an exposed OpenID Connect service in the first place, you can use it as the Tailscale tailnet auth SSO: https://tailscale.com/kb/1240/sso-custom-oidc
So it‘s not part of what Tailscale brings, it just adds another layer of indirection between the SSO / IdP you have already and the app, plus requires some custom library integration work, further enhancing lock-in.
You don't have to think about redirects, sessions, cookies, syncing your users and their roles in TS and Keycloak, maintaining two separate policy files and all that.
> For private services inside your tailnet, like internal tools, implementing auth on every app is overkill. That’s why we developed tsnet, a Go library that embeds Tailscale directly in your applications. This lets you see and react to the identity of every user who makes a request to your app. So, authentication is handled…what about authorization?
The article then proceeds to show how to modify an application using tsnet to embed in the application. Which sounds a whole lot like modifying the application. The point might be that it’s more straightforward to do this then gate behind something like keycloak, but fundamentally it still requires modifying the application