I just set this up the other day, and I got my ping to drop from 16 to 10ms, and my bandwidth tripled, when connecting from a remote natted site to a matter desktop my house. Together with Moonlight/Sunshine I can now play Windows games on my Linux desktop from my MacBook, with 50mbps/10ms streaming. So far so good!
Not a single port forwarded, I just set my router up as peer node.
Neat use case. But in fairness, you've simply 'offloaded' NAT traversal/port forwarding to automagic helper protocols over which you have no control even if you wanted it.
That seems really exciting! If you wanted to share game streaming to a general public would they have to install tailscale on their device/login? How does that work? Am I right in assuming that tailscale is built mostly for sharing resources with people you trust instead of the general public?
I'm confused.
I wanted to do this too with an OpenWRT router, but I was under the impression I still had to open a 40000 port so my NAT devices can see it. Wouldn't it still be on the exposed public Internet?
There are several ports open (you dont open them, Tailscale does), including for peer relay. Some are vpn ports, but the ports for relay servers are not for VPN so my guess is that the software that listens to those ports is a lot less secure (compared to Wireguard or OpenVPN).
How does Tailscale make money? I really like their service but I'm worried about a rug pull in the future. Has anyone tried alternative FOSS solutions?
Also, sometimes it seems like I get rate limited on Tailscale. Has anyone had that experience? This usually happens with multiple SSH connections at the same time.
Our company pays for the premium business plan, $18/mo/user. You have to pay for at least the lower tier plan once your team grows beyond a handful of people. And there's several quite useful features (though maybe not essential) on the premium plan like serve/funnel and SSH.
On the other hand, I do wonder about zerotier. before tailscale we used zerotier for a few years, and during the first 3-4 years we paid nothing because as far as I can recall there was nothing extra that we needed that paying would've gotten us. Eventually we did upgrade to add more users, and it cost something like $5/mo (total, not per user).
> Also, sometimes it seems like I get rate limited on Tailscale.
As I understand it if everything is working properly you should end up with a peer to peer wireguard connection after initial connection using tailscales infrastructure. ie, there should be nothing to rate limit. There are exceptions depending on your network environment where you need one of the relays noted in this post.
Tailscale is a perfect example of using a free tier to become popular with developers, who then evangelize the product to their employers. The employers pay for business scale plans.
Just like cloudflare, a healthy free offering makes lots of happy/loyal developer users. Some of those users have business needs / use for the paid features and support and will convince their managers to buy in.
At this point Tailscale is working so well and I'm so happy with it that I'm afraid it's time to start migrating to Headscale [0] for my home network. The rag pull may just be too painful otherwise!
Just like cloudflare, a healthy free offering makes lots of happy/loyal users. Some of those users have business needs / use for the paid features and support.
I self-host a few apps and use Tailscale to access them remotely. It's worked well, so I recommended it as a possible solution to allow employees at my company to remotely access some on-prem resources while remote, and that's being considered. If we go with that, then that'd be Tailscale making money from me using the free plan.
Free personal tier is basically a cheap advertisement for them. You try Tailscale personally and get used to it, then it is very likely you would want to deploy it at your work seeing the benefits scaling even more with more people.
And then they make money.
There are a number of features and teamsizes that they provide where you have to pay money. Most company users are going to end up paying them money. But also their emphasis on P2P connections means their costs are quite low. It doesn't add much overhead to have the smallish number of personal users out there. They've talked about how having the free tier helps to force them keep those costs down in useful ways.
“Each Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.com). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network.”
They know what you're doing, when, from where, to where, on your supposedly “private” network. It's possible to opt out on Windows, on *nix systems, and when using the non-GUI client on macOS by enabling the FUD-named “TS_NO_LOGS_NO_SUPPORT” option: https://tailscale.com/docs/features/logging#opt-out-of-clien...
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
I'm having a hard time understanding how this is different from a bastion server, where you're tunneling through an intermediary server that you've deployed in the target network.
I guess the difference is the fact that the intermediary server doesn't need a port open (as standard nat punching will work)? Or are there other big differences?
We've setup and used peer-relays since it was first announced and they've been great, but they do solve a somewhat specific problem.
Some of our users experienced fairly limited throughput from time to time. Under certain circumstances (eg. always ipv4 NAT/double-NAT, never for ipv6) their Tailscale client couldn't establish a direct connection to the Tailscale node in the datacenter, so data was relayed through Tailscales public relay nodes. Which at times was rate limited/bottleneck - in all fairness, that is to be expected according to their docs.
The first mitigation was to "ban" the specific public relay they were using in the policy. Which helped, but still not a great solution and we might just end up in a weird whack-a-mole-ish ban game with the public peer relays in the long run.
So we setup a peer relay, which networking-wise is in a DMZ sort of network (more open), but location wise still in the datacenter and allowed it to easily reach the internal (more restricted networking) Tailscale nodes. Which solved all throughput problems, since we no longer have users connecting through the public relays.
Also, the peer relays feels a little bit magic, once you allow the use of them in the Tailscale policy, it just works(tm) - there is basically zero fiddling with them.
EDIT: I'll happily provide more details if interested - we did a fair amount of testing and debugging along the way :)
I think that biggest difference is that your client applications don't need to be explicitly configured to use the bastion server. For example ssh, web browsers, rdp, samba and so on can just pretend that you are inside the target network. Doubly useful if this is a "customer" network and you are working with multiple customers.
I wonder if someone might indulge me by answering a question or two about Tailscale. I have a self-managed wireguard network which works, but probably isn't very smart or elegant.
From what I can gather, Tailscale does a lot of "magic" things to accomplish its goals, and some of them actually have "magic" right in the name. As a system administrator by trade, I have been bitten SO MANY TIMES by things that try to automagically mess with DNS resolution, routing tables, firewall rules, etc in the name of user-friendliness. (Often, things that even ship with the OS itself.)
Are there any documentation or articles detailing exactly what it's doing under the hood? I found https://tailscale.com/docs/concepts but it doesn't really cover everything.
If I have a virtualization host with, let's call it a "very custom" networking configuration, how likely is it to interfere with things? Is it polite and smart about working around fancy networking setups, or does it really only handle the common cases (one networking interface, a default route, public nameserver) elegantly?
It's difficult for us to maintain documentation of exactly the kind you'd want there, though we do try to keep up with docs as best we can. In particular there is a fairly wide array of heuristics in the client to adapt to the environment that it's running in - and this is most true on Linux where there are far far too many different configuration patterns and duplicate subsystems (example: https://tailscale.com/blog/sisyphean-dns-client-linux).
To try and take a general poke at the question in more of the context you leave at the end:
- We use rule based routing to try to dodge arbitrary order conflicts in the routing tables.
- We install our rules with high priority because traffic intended for the tailnet hitting non-tailscale interfaces is typically undesirable (it's often plain text).
- We integrate with systemd-resolved _by preference_ on Linux if it is present, so that if you're using cgroup/namepsace features (containers, sandbox runtimes, etc etc) then this provides the expected dns/interface pairings. If we can't find systemd-resolved we fall back to modifying /etc/resolv.conf, which is unavoidably an area of conflict on such systems (on macos and windows they have more broadly standard solutions we can use instead, modulo other platform details).
- We support integration with both iptables and nftables (the latter is behind manual configuration currently due to slightly less broad standardization, but is defaulted by heuristic on some distros/in some environments (like gokrazy, some containers)). In nftables we create our own tables, and just install jumps into the xtables conventional locations so as to be compatible with ufw, firewalld and so on.
- We do our best in tailscaled's sshd to implement login in a broadly compatible way, but again this is another of those places the linux ecosystem lacks standards and there's a ton of distro variation right now (freedesktops concerns start at a higher level so they haven't driven standardization, everyone else like openssh have their own pile of best-guesses, and distros go ham with patches).
- We need a 1360 byte MTU path to peers for full support/stability. Our inner/interface MTU is 1280, the minimum MTU for IPv6, once packed in WireGuard and outer IPv6, that's 1360.
I can't answer directly based on "very custom" if there will be any challenges to deal with. We do offer support to work through these things though, and have helped some users with fairly exotic setups.
I really like Tailscale. Recently though I’ve been having some hard-to-diagnose slowdowns even on a direct (non DERP) connection. I’m not sure if it’s something to do with MTUs or my ISP.
If you're sold on Tailscale due to them "being open" (as they semi-officially support the development of Headscale), keep in mind, that at the same time some of their clients are closed source and proprietary, and thus totally controlled by them and the official distribution channels, like Apple. Some of the arguments given for this stance are just ridiculous:
> If users are comfortable running non-open operating systems or employers are comfortable with their employees running non-open operating systems, they should likewise be comfortable with Tailscale not being open on those platforms.
A solution like this can't really be relied in situations of limited connectivity and availability, even if technically it beats most of the competition. Don't ever forget it's just a business. Support free alternatives if you can, even if they underperform by some measures.
I don't understand this attitude. Some humans have to eat and put a roof over their heads sometimes, and extracting consulting fees from open-source work (i.e. the Redhat model) is not always a paying business model. A hybrid model is often the best way to compromise.
Disclaimer: I'm pursuing a similar solution on an app I'm working on. The CLI will be free and open-source (and will have feature parity with the GUI), but charging money for the GUI will also help support that development (and put my son through school etc.)
And by "feature parity", I really mean it- The GUI will be translated into 22 languages... and so will the CLI. ;) (Claude initially argued against this feature. I made my arguments for it. It: "You make a compelling argument. Let's do it." LOL)
I'm building something on top of that which will have a nice GUI, do some other data integrity stuff, and also have a CLI. And will be for sale in the Mac and Windows app stores.
"Support free alternatives if you can, even if they underperform by some measure."
I value _control_ more than I do performance
Better performance is, IMHO, not a reason to sacrifice _control_, but that's just me
If users have control, i.e., can compile from source, then in theory performance improvement is possible through DIY or work of others. However performance is not always the only important issue. Today's commercial software tends to be rushed, lower quality, bloated. Releasing work-in-progress software that requires constant remotely-installed "updates" in place of a thoroughly-tested final product is a norm
Without control, if performance, _or anything else about the software_, is unsatisfactory, then there is nothing users can do
So fully available in situations with limited connectivity. The GUI version of the client is closed source though, and it's available as a package or from the app store.
Seems like an odd thing to be concerned about. Most of the apps on my Mac are closed source, that little Tailscale menu bar item is really insignificant. You can always control it through the command line if you're really bothered by it. I'm pretty sure tailscale is on brew.
That justification honestly doesn't sound that ridiculous to me, especially if the closed-source stuff is mostly just platform-specific GUI and integration code. Is there even a practical mechanism to open source an iOS app and then letting users verify that the version they're downloading from the App Store is exactly the same version that is open sourced?
I've been relatively happy with Headscale, but now that I have MacOS/iOS users I'm in the process of testing alternatives like Netbird. I was also surprised that the Tailscale Kubernetes operator is not compatible with Headscale.
As a developer who have been built some tailscale-based clients, I think this maybe acceptable because they running a business with money from the VCs.
And I am also very grateful that tailscale implement some workaround for systems such as apple-based OS with core APIs built into the open source code, thus if you really need you can just look the open source code and doing accordingly, though it really need some research work.
For the long term if they really do not want to open source the core client code (which I do not believe at the moment), I think support a fully open source coordinator and open source client based on the fork will still be doable.
where were the alternatives before tailscale? we could only read bout BeyondCore with envy before tailscale. i'm going to keep supporting them unless they do something naughty.
I looked into tailscale in the past as a way to host a game server such as minecraft on my local machine publicly without port forwarding . It seems that tailscale is mostly configured only to work with people you know and trust. I was hoping that Peer Relays would help alleviate some restrictions with tailwind funnel. Does anyone know any alternatives?
if you have a cheap vps you can use it to forward the traffic to for some benefit, that is what i have been doing when i need compute accessible online and don't want to pay for cloud.
I have my homenas set up with Node Proxy Manager container forwarding requests to different docker machines:ports e.g. I have some TTS/STT/LLM services locally hosted. To increase bandwidth to internet facing nodes, would you use this or some other simpler solution?
(Tailscale founder here) Two main differences: first, every DERP server used by your tailnet must be accessible by every node on your tailnet at all times, otherwise you get hard-to-debug netsplits. That's a very high bar to maintain so we've historically recommended you don't try. In contrast, peer relays are "if a given pair of nodes can connect through any of the relays, go for it" so deploying one is always a performance and reliability improvement.
Secondly, peer relays support UDP while DERP is TCP-only. That would be fixable by simply improving the DERP protocol, but as we explored that option, we decided to implement the Peer Relay layer instead as a more complete solution.
Edit: this is a ridiculous question, I know. Trying to eat my dogfood so to speak
Does Tailscale maintain an q&a agent, mcp, or llms.txt that anyone is aware of?
I’m trying to use Tailscale across my personal networks - without investing a lot of time - and so I’m throwing agents at it. It’s not going well, primarily because their tools/interfaces have been changing a lot, and so tool calls fail (ex ‘tailscale serve —xyz’ is now ‘tailscale funnel ABC’ and needs manual approval, and that’s not in the training set).
One thing I haven't quite understood yet: If I have multiple relays, will Tailscale automatically pick the "best one" for a given connection, e.g. the one closest to the destination in terms of latency?
Oh that's really cool! I hope it alleviates some pressure on the DERP servers, whenever I notice the connection on tailscale is bad, it's usually because the device is connecting over DERP.
For someone who is new in this technically does it work like turn and sturn? Relay communicating over outbound ports? Wouldnt this run into scaling issues?
Peer relays are a bit different from our previously available Custom DERP servers. While the custom DERPs do relay traffic, they also require a bunch of configuration and management for their other jobs and they open up availability concerns that are pretty tough for our average customer.
Conversely Peer Relays are built on top of the shoulders of DERP. For example, they don't need to do peer discovery set connections up end to end - instead connections are brokered via our DERP fleet and then in a sense "upgraded" to an available Peer Relay or Direct connection. Because of that they're super lightweight and much easier to deploy + manage. And, they scale horizontally so you can deploy many peer relays across your network, and they're resilient to downtime (we'll just fall back to DERP).
Tailscale simp here, been using this feature since it launched in beta, can't believe it didn't exist earlier.
This solved every last remaining problem of my CGNAT'd devices having to hop through STUN servers (with the QoS being noticable), now they just route through my own nodes.
I never brought my self to use tailscale because it has a login screen and I absolutely despise that even as a concept for a private NAT. I know headscale exists, but it doesn't seem to even support the features I really want.
I can't believe this isn't a show stopper for more people here. I literally couldn't figure out how use it the first time tried because I didn't know how to comprehend that it was trying to get me to auth via browser window. I kept digging around for a tailscale.conf.
Which is then when I realized it was less a piece of software and more so an auth management provider with some vaguely helpful auxillary services.
The peer relay approach is interesting because it essentially turns every node in your tailnet into a potential relay for other nodes. This is a meaningful architectural shift from relying on Tailscale's centralized DERP servers.
For anyone worried about the "rug pull" concern raised in another comment — this actually makes me more optimistic, not less. By distributing relay infrastructure to the edges, Tailscale is reducing its own operational cost per user while improving performance. That's the kind of flywheel that makes a generous free tier more sustainable, not less. Each new node potentially helps the whole network.
The shift from managed DERP to decentralized Peer Relays is a massive win for self-hosters with difficult NAT situations. I’m curious if this significantly reduces Tailscale's own egress costs or if the primary goal was just improving latency for users who can't establish a direct WireGuard tunnel. Either way, removing the 'hassle' of setting up a custom DERP server is a great UX improvement.
Alex from Tailscale here... We’re users just like you, and we felt this pain point ourselves. The good news is that Peer Relays were able to build on a lot of the existing subnet router and exit node plumbing, so it wasn’t a huge engineering lift to bring to life.
We also have plenty of customers running in restrictive NAT environments (AWS being a common example), where direct WireGuard tunnels just aren’t always possible. In those cases, something like Peer Relays is essential for Tailscale to perform the way larger deployments expect.
So yes, it improves latency and UX for self-hosters, but it also helps us support more complex production environments without requiring folks to run and manage custom DERP infrastructure.
We’ve had issues with the centralized DERPs just blackholing traffic when we startup ephemeral nodes in CI. This is despite us ensuring that all important peers can establish direct connections to each other. But there is some bootstrapping that is happening before both peers negotiate.
Having said this, it’s been almost a year since the last incident of this. It’s been rock solid the last months. Ok sure using these new peer nodes will greatly reduce this from even a chance of happening anymore. :hacks away:
Three AI-generated positive comments in the row from new (green) accounts, with some being answered by Tailscale employees looks like AI-assisted astroturfing PR in hackernews. It’s rampart on every major social network (Reddit especially), interesting to see it live first time on the HN.
I am not anti advertising, I just think pushing AI into places were people interact is very bad behavior and should be punished.
It's a bit disingenuous to present solutions like Tailscale as more secure than opening a VPN port on one's on machine. The latter solution should always be preferred when available just because you don't want your infrastructure to depend on a "free" service which might cease to be free tomorrow.
This is a more all-included and resilient system, especially for logging, than just opening a VPN port. I do a lot of corporate installs, and if we had a system like Tailscale then I would be in heaven. The amount of user-created systems are heinous in regards to security, and hard to setup and keep running. Tailscale lets you setup quickly, and reliably with minimal errors OOTB.
If you feel that tailscale will fold, or the free plan will be future limited, then you can drop in headscale which is a near 1:1 API open source tailscale central server.
If you always want to be open source and not rely on API changes or staying up to green on the headscale development (made by a third party), then you can set up netbird, which is both hosted (for free) as an alternative to Tailscale more tailored for developers, but they also open-sourced their entire stack, so you can always leave and use that on your own servers.
Things are much more unscrupulous than potentially ceasing to be free tomorrow. Nobody who values their privacy would ever route their network traffic through a 'free' service.
One of the many use cases, but basically yes. Other use cases: Home automation, remote backups, media servers, photo libraries, AI assistants... you name it!
It's a vpn from the original definition before vpn meant a proxy to get around geoblocks. I use tailscale for my home servers, my routers, for servers I have in other houses all behind NAT. I have half a dozen raspberry pi print servers in two warehouses also behind NAT and they can connect to each other and I can connect to them from CGNAT
tda|11 days ago
Not a single port forwarded, I just set my router up as peer node.
FrenchTouch42|11 days ago
nickburns|11 days ago
jak6jak|11 days ago
unknown|11 days ago
[deleted]
flowstraume|11 days ago
arjie|11 days ago
aborsy|11 days ago
behnamoh|11 days ago
Also, sometimes it seems like I get rate limited on Tailscale. Has anyone had that experience? This usually happens with multiple SSH connections at the same time.
dimatura|11 days ago
On the other hand, I do wonder about zerotier. before tailscale we used zerotier for a few years, and during the first 3-4 years we paid nothing because as far as I can recall there was nothing extra that we needed that paying would've gotten us. Eventually we did upgrade to add more users, and it cost something like $5/mo (total, not per user).
vizzier|11 days ago
As I understand it if everything is working properly you should end up with a peer to peer wireguard connection after initial connection using tailscales infrastructure. ie, there should be nothing to rate limit. There are exceptions depending on your network environment where you need one of the relays noted in this post.
As for opensource alternatives:
https://github.com/juanfont/headscale can replace tailscales initial coordination servers
and https://netbird.io/ seemed to be a rapidly developing full stack alternative.
evmar|11 days ago
Aurornis|11 days ago
allthetime|11 days ago
Just like cloudflare, a healthy free offering makes lots of happy/loyal developer users. Some of those users have business needs / use for the paid features and support and will convince their managers to buy in.
prodigycorp|11 days ago
Salesforce, stay away from it!
nsbk|11 days ago
[0]: https://headscale.net/
allthetime|11 days ago
Just like cloudflare, a healthy free offering makes lots of happy/loyal users. Some of those users have business needs / use for the paid features and support.
tiernano|11 days ago
thecapybara|11 days ago
mrsssnake|11 days ago
eurg|11 days ago
dec0dedab0de|11 days ago
zaphar|11 days ago
cbility|10 days ago
Lammy|11 days ago
They spy on your network behavior by default, so free users are still paying with their behavioral data. See https://tailscale.com/docs/features/logging
“Each Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.com). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network.”
They know what you're doing, when, from where, to where, on your supposedly “private” network. It's possible to opt out on Windows, on *nix systems, and when using the non-GUI client on macOS by enabling the FUD-named “TS_NO_LOGS_NO_SUPPORT” option: https://tailscale.com/docs/features/logging#opt-out-of-clien...
It is not currently possible to opt out on iOS/Android clients: https://github.com/tailscale/tailscale/issues/13174
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
gz5|11 days ago
https://github.com/openziti/ziti
resiros|11 days ago
UltraSane|11 days ago
Suffocate5100|11 days ago
pkulak|11 days ago
jacquesm|11 days ago
fdefitte|11 days ago
[deleted]
timwis|11 days ago
I guess the difference is the fact that the intermediary server doesn't need a port open (as standard nat punching will work)? Or are there other big differences?
bingo-bongo|10 days ago
Some of our users experienced fairly limited throughput from time to time. Under certain circumstances (eg. always ipv4 NAT/double-NAT, never for ipv6) their Tailscale client couldn't establish a direct connection to the Tailscale node in the datacenter, so data was relayed through Tailscales public relay nodes. Which at times was rate limited/bottleneck - in all fairness, that is to be expected according to their docs.
The first mitigation was to "ban" the specific public relay they were using in the policy. Which helped, but still not a great solution and we might just end up in a weird whack-a-mole-ish ban game with the public peer relays in the long run.
So we setup a peer relay, which networking-wise is in a DMZ sort of network (more open), but location wise still in the datacenter and allowed it to easily reach the internal (more restricted networking) Tailscale nodes. Which solved all throughput problems, since we no longer have users connecting through the public relays.
Also, the peer relays feels a little bit magic, once you allow the use of them in the Tailscale policy, it just works(tm) - there is basically zero fiddling with them.
EDIT: I'll happily provide more details if interested - we did a fair amount of testing and debugging along the way :)
fireant|10 days ago
bityard|11 days ago
From what I can gather, Tailscale does a lot of "magic" things to accomplish its goals, and some of them actually have "magic" right in the name. As a system administrator by trade, I have been bitten SO MANY TIMES by things that try to automagically mess with DNS resolution, routing tables, firewall rules, etc in the name of user-friendliness. (Often, things that even ship with the OS itself.)
Are there any documentation or articles detailing exactly what it's doing under the hood? I found https://tailscale.com/docs/concepts but it doesn't really cover everything.
If I have a virtualization host with, let's call it a "very custom" networking configuration, how likely is it to interfere with things? Is it polite and smart about working around fancy networking setups, or does it really only handle the common cases (one networking interface, a default route, public nameserver) elegantly?
raggi|11 days ago
To try and take a general poke at the question in more of the context you leave at the end:
- We use rule based routing to try to dodge arbitrary order conflicts in the routing tables.
- We install our rules with high priority because traffic intended for the tailnet hitting non-tailscale interfaces is typically undesirable (it's often plain text).
- We integrate with systemd-resolved _by preference_ on Linux if it is present, so that if you're using cgroup/namepsace features (containers, sandbox runtimes, etc etc) then this provides the expected dns/interface pairings. If we can't find systemd-resolved we fall back to modifying /etc/resolv.conf, which is unavoidably an area of conflict on such systems (on macos and windows they have more broadly standard solutions we can use instead, modulo other platform details).
- We support integration with both iptables and nftables (the latter is behind manual configuration currently due to slightly less broad standardization, but is defaulted by heuristic on some distros/in some environments (like gokrazy, some containers)). In nftables we create our own tables, and just install jumps into the xtables conventional locations so as to be compatible with ufw, firewalld and so on.
- We do our best in tailscaled's sshd to implement login in a broadly compatible way, but again this is another of those places the linux ecosystem lacks standards and there's a ton of distro variation right now (freedesktops concerns start at a higher level so they haven't driven standardization, everyone else like openssh have their own pile of best-guesses, and distros go ham with patches).
- We need a 1360 byte MTU path to peers for full support/stability. Our inner/interface MTU is 1280, the minimum MTU for IPv6, once packed in WireGuard and outer IPv6, that's 1360.
I can't answer directly based on "very custom" if there will be any challenges to deal with. We do offer support to work through these things though, and have helped some users with fairly exotic setups.
Computer0|11 days ago
patmorgan23|11 days ago
adithyassekhar|11 days ago
0: https://i.postimg.cc/14h3Q9mD/Screenshot-20260219-001356-Chr...
Edit: Nvm, found it. Weird place to put it.
yardstick|11 days ago
jrm4|11 days ago
What's the big deal here? Any good reason to switch (besides Tinc's obscurity?)
skinner927|11 days ago
marcosscriven|11 days ago
ZoomZoomZoom|11 days ago
> If users are comfortable running non-open operating systems or employers are comfortable with their employees running non-open operating systems, they should likewise be comfortable with Tailscale not being open on those platforms.
https://github.com/tailscale/tailscale/issues/13717
A solution like this can't really be relied in situations of limited connectivity and availability, even if technically it beats most of the competition. Don't ever forget it's just a business. Support free alternatives if you can, even if they underperform by some measures.
pmarreck|11 days ago
Disclaimer: I'm pursuing a similar solution on an app I'm working on. The CLI will be free and open-source (and will have feature parity with the GUI), but charging money for the GUI will also help support that development (and put my son through school etc.)
And by "feature parity", I really mean it- The GUI will be translated into 22 languages... and so will the CLI. ;) (Claude initially argued against this feature. I made my arguments for it. It: "You make a compelling argument. Let's do it." LOL)
The lowest level of it is already available and fully open-source: https://github.com/pmarreck/validate
I'm building something on top of that which will have a nice GUI, do some other data integrity stuff, and also have a CLI. And will be for sale in the Mac and Windows app stores.
dblohm7|11 days ago
1vuio0pswjnm7|11 days ago
I value _control_ more than I do performance
Better performance is, IMHO, not a reason to sacrifice _control_, but that's just me
If users have control, i.e., can compile from source, then in theory performance improvement is possible through DIY or work of others. However performance is not always the only important issue. Today's commercial software tends to be rushed, lower quality, bloated. Releasing work-in-progress software that requires constant remotely-installed "updates" in place of a thoroughly-tested final product is a norm
Without control, if performance, _or anything else about the software_, is unsatisfactory, then there is nothing users can do
varenc|11 days ago
So fully available in situations with limited connectivity. The GUI version of the client is closed source though, and it's available as a package or from the app store.
zarzavat|11 days ago
tshaddox|11 days ago
uneekname|11 days ago
mintflow|11 days ago
And I am also very grateful that tailscale implement some workaround for systems such as apple-based OS with core APIs built into the open source code, thus if you really need you can just look the open source code and doing accordingly, though it really need some research work.
For the long term if they really do not want to open source the core client code (which I do not believe at the moment), I think support a fully open source coordinator and open source client based on the fork will still be doable.
8cvor6j844qw_d6|11 days ago
j-krieger|11 days ago
segmondy|11 days ago
xyst|11 days ago
gzread|11 days ago
icfly2|11 days ago
jak6jak|11 days ago
Computer0|11 days ago
itissid|11 days ago
tecleandor|11 days ago
shj2105|11 days ago
apenwarr|11 days ago
Secondly, peer relays support UDP while DERP is TCP-only. That would be fixable by simply improving the DERP protocol, but as we explored that option, we decided to implement the Peer Relay layer instead as a more complete solution.
unknown|11 days ago
[deleted]
allthetime|11 days ago
Nothing they do was impossible before, but their big win is making world wide private networking easy and accessible.
I’ve been on-boarding my friends who have their own local media servers setup so we can all share/stream content from each other.
threecheese|10 days ago
Does Tailscale maintain an q&a agent, mcp, or llms.txt that anyone is aware of?
I’m trying to use Tailscale across my personal networks - without investing a lot of time - and so I’m throwing agents at it. It’s not going well, primarily because their tools/interfaces have been changing a lot, and so tool calls fail (ex ‘tailscale serve —xyz’ is now ‘tailscale funnel ABC’ and needs manual approval, and that’s not in the training set).
codethief|11 days ago
noirscape|11 days ago
debarshri|11 days ago
aborsy|11 days ago
So it runs a STUN server or similar, for discovery and relaying.
kabirx|11 days ago
Conversely Peer Relays are built on top of the shoulders of DERP. For example, they don't need to do peer discovery set connections up end to end - instead connections are brokered via our DERP fleet and then in a sense "upgraded" to an available Peer Relay or Direct connection. Because of that they're super lightweight and much easier to deploy + manage. And, they scale horizontally so you can deploy many peer relays across your network, and they're resilient to downtime (we'll just fall back to DERP).
yuvadam|11 days ago
This solved every last remaining problem of my CGNAT'd devices having to hop through STUN servers (with the QoS being noticable), now they just route through my own nodes.
hashstring|11 days ago
corford|10 days ago
alberto_delrio|11 days ago
pluto_modadic|11 days ago
himata4113|11 days ago
earthscienceman|11 days ago
Which is then when I realized it was less a piece of software and more so an auth management provider with some vaguely helpful auxillary services.
kittbuilds|11 days ago
For anyone worried about the "rug pull" concern raised in another comment — this actually makes me more optimistic, not less. By distributing relay infrastructure to the edges, Tailscale is reducing its own operational cost per user while improving performance. That's the kind of flywheel that makes a generous free tier more sustainable, not less. Each new node potentially helps the whole network.
solarisos|11 days ago
alexktz|11 days ago
We also have plenty of customers running in restrictive NAT environments (AWS being a common example), where direct WireGuard tunnels just aren’t always possible. In those cases, something like Peer Relays is essential for Tailscale to perform the way larger deployments expect.
So yes, it improves latency and UX for self-hosters, but it also helps us support more complex production environments without requiring folks to run and manage custom DERP infrastructure.
ghthor|11 days ago
Having said this, it’s been almost a year since the last incident of this. It’s been rock solid the last months. Ok sure using these new peer nodes will greatly reduce this from even a chance of happening anymore. :hacks away:
nivcmo|11 days ago
[deleted]
ksynwa|11 days ago
Edit: My understanding of network terminologies is weak. But I assumed that the relay server would have to not be behind a CGNAT.
phrotoma|11 days ago
clarabennett26|11 days ago
[deleted]
samat|11 days ago
I am not anti advertising, I just think pushing AI into places were people interact is very bad behavior and should be punished.
jamiemallers|10 days ago
[deleted]
1necornbuilder|11 days ago
[deleted]
anvevoice|11 days ago
[deleted]
kittbuilds|10 days ago
[deleted]
techpulse_x|11 days ago
[deleted]
drnick1|11 days ago
drannex|11 days ago
If you feel that tailscale will fold, or the free plan will be future limited, then you can drop in headscale which is a near 1:1 API open source tailscale central server.
If you always want to be open source and not rely on API changes or staying up to green on the headscale development (made by a third party), then you can set up netbird, which is both hosted (for free) as an alternative to Tailscale more tailored for developers, but they also open-sourced their entire stack, so you can always leave and use that on your own servers.
nickburns|11 days ago
jahrichie|11 days ago
nsbk|11 days ago
dwedge|11 days ago
josefresco|11 days ago