Today we're announcing Tailscale Community Projects — projects by ourselves and our community that work well with Tailscale, are easy to collaborate on, and will keep working if you adopt them.
That's an unusual set of promises. Let's talk about why.
Stopping the upgrade treadmill
You might not even notice it anymore: the pervasive idea that, if you stop upgrading software, it'll eventually break. Or at least become a security hole. Or unsupported by the vendor. Or, I don't even know what, but definitely something bad. Old software is bad. So you'd better upgrade.
That applies recursively across every application. If an app depends on a framework that has been updated, well, the app vendor had better update the framework. And if that breaks the app, well, the vendor has to change the app. And so you'd better upgrade the app.
Modern apps and frameworks have hundreds of dependencies, and all those dependencies are on an upgrade treadmill. A dependency might change every week, or every day, or more. If bad things will happen unless you continuously upgrade, then you'd better get processes in place to do that. Now you need a full time devops team, continuous deployment, and continuous integration... just to stand still.
Well, almost stand still. New versions of apps also move buttons around, change APIs, break old APIs, deprecate features, charge you more money for features you didn't ask for, and occasionally get abandoned by the vendor and never upgraded again — which means you have to migrate off them in a hurry, because the upgrade treadmill never stops, even if at the end of the treadmill there's a cliff of despair. And that cliff is, mercifully, the end of my metaphor.
At Tailscale we're taking a different path which I call, "But what if we didn't?"
What does it take to stop that recursive upgrade treadmill in its tracks? I think it needs to work like this:
- I won't upgrade the app
- Because I'm certain that only people I trust [1] can access the app
- And so security holes in the app don't matter [2]
- And even if those supposedly trusted people exploit the holes, they can't move laterally from there to attack other places in my network
- And the platform the app runs on will be backward compatible forever
- And therefore the libraries and frameworks my app depends on will also work forever
- And therefore I only need to upgrade if I actually want new features
- And even if I do want new features, I can modify the app without upgrading a bunch of frameworks
- Unless I really want the features in new versions of the frameworks.
Phew. That whole liberating chain depends on two items that I bolded above.
First, only people I trust can access the app. That doesn't make security holes go away; it just makes them irrelevant. One of the founding principles of Tailscale is Remembering the LAN: before the Internet, security holes didn't matter because nobody was there to exploit them. With appropriate security measures, we can bring that world back. In security terms, there's strong evidence that multiple "good" layers of security are not as good as a single comprehensive layer of security. You really can put all your eggs in one basket. But, guard that basket.
Second, the platform the app runs on will be backward compatible forever. Forever. If the underlying platform's ABI changes — whatever level you define "platform" at — it triggers a cascade of upgrades that could be visible all the way back to the surface.
We're trained to be paranoid about security holes at every layer. As a natural consequence, platforms must always change — every time there's a hole. And therefore no platform can ever be stable, and therefore the upgrade treadmill is systematically inevitable.
But it's not true.
Stable platforms exist, but are expensive to maintain
If we look at platforms in the tech world, we can find examples that don't follow the pattern of breaking stuff all the time, even when they get upgraded with new features and security fixes. It's not a coincidence that these are the platforms almost everything is built on.
- The compute platform: x86 (and nowadays, modern arm64[3])
- OS platforms: DOS. Win32/Win64. Linux kernel ABIs. [4]
- The web platform: HTML and Javascript (and now wasm)
For all of these platforms, some central company or committee puts an astonishing amount of work into making sure stuff stays compatible year after year, version after version, forever, even when painful architectural security holes need plugging or the original idea really sucked.
Even when a platform dies off — as DOS did, and win32 did, and x86 probably will eventually — the things built on those platforms survive thanks to emulation. It's so valuable to keep platforms intact that we insert a new compatible layer underneath the defunct platform to transparently fix what's on top.
It's really expensive to maintain these stable platforms. So why do people do it? Because it's also really profitable. In fact, it's a survivorship trait: the only platforms that survive, long term, are the ones that do this.
Every time a vendor breaks their platform, they give you two choices: upgrade to their new thing, or upgrade to someone else's new thing. Every time "just stick with it" becomes a choice, they lose some people. Vendors who keep their platform stable benefit from the overwhelming majority, people who are satisfied with the status quo. Most people simply have better things to do than switch away from a working platform with a working solution on top.
The Internet is a platform
In my list of stable platforms above, I missed one: TCP/IP.
The history is fascinating. TCP-over-IPv4 has persisted since the 1980s, through uncountable numbers of hardware platforms, OSes, reimplementations, optimizations, congestion control algorithms, security fixes, workarounds, extensions, middle boxes, proxies, and NATs. And yet, if you wrote a program in 1983 using TCP over IPv4, and you run it today in an emulated computer from that era, chances are it can talk to a 2025 iPhone, 42 years later. Wow. Now that's stable.
But, as I wrote in The New Internet, the Internet platform has been so stable for so long that its oldest design flaws are really holding us back. Our long battle to deploy the incompatible[5] IPv6 — you were the chosen one! — has left the original and still-dominant IPv4 mostly as it was, with an ever-growing pile of hacks on top.
We can do better. And, we can do better without breaking anything.
Tailscale is a stable platform
We don't talk about it much, but when we started Tailscale we made a few quiet promises to ourselves. [6]
First, we would never break any client release that people were still using.[7]
Second, that we would never break any of our public-facing coordination server APIs or policy file syntax.
Third, we would clearly identify which set of APIs in our Tailscale client in Go that we promised not to break. (And conversely, which you shouldn't touch because they were implementation details.)
Fourth, we would find some way to support both IPv4 and IPv6, for every node that wants it, forever. Including transparently cross-connecting between the two. And regardless of what shape the public Internet takes (pure IPv4, pure IPv6, or some new thing).
Fifth, we would integrate security into what already exists, in an application-transparent way. Old-school IPv4 apps like telnet, ftp, rsh, and SMB are hopelessly insecure on the public Internet. But on Tailscale they're totally safe to use. We fixed the glitch by adding end-to-end encryption and identity. And without modifying any app, any protocol, or any part further up the stack.
As a result, people who deployed a Tailscale node onto an embedded device at a factory three years ago won't have nasty surprises when they take it out of the box three years from now.[9] It'll work fine (assuming you set its key expiry correctly :))
We dogfooded our own Tailscale platform
Right, so, that was a long setup for what can now be a shorter payoff.
At Tailscale over the years, we've built several small tools that depend on our core product. Some of these are written by one person and only sporadically maintained, even though we use them heavily in production.
In most situations, "sporadically maintained" would be a little scary. You can't use that, right? Can you really rely on a tool that isn't updated every week to keep up with all its dependencies? Well, if it's on Tailscale, then: yes. We do, and you can too. It's awesome. We want to share that awesomeness with you.
For the Tailscale-owned tools below, I'm going to make a bold combination of claims.
- They are not maintained (except if we really do find an exploitable security hole... or when we feel like it).
- But, they are supported.
Let's read that again. Normally it's the other way around. Typically, popular projects are heavily maintained, but you still won't get official help when you ask, unless you pay up. But Tailscale offers free email support for our products for everyone, even free users, and starting today, this extends to our community projects.[11]
Yes, we'll help you get these tools working on your tailnet. Since the tools aren't officially maintained, we can't guarantee new features or even bug fixes. They're provided as-is. But, they work. And even more importantly, once you get them working, they're going to keep working, no exceptions.[12] That's the promise.
Of course, patches are welcome. Tailscale's core does the hard parts (backward compatibility, connectivity, NAT traversal, authentication, and authorization), and we know it can be hairy to contribute to that. By comparison, these community projects tend to be fun and easy to fork and hack on. They make excellent toys, templates for new toys, or starter projects for new open source developers.
Avery's favourite Tailscale community projects
Okay, so today we're launching the first batch of projects. Some of these have been out there for a while, but in many cases they've been <cough> only lightly documented or they had big warning signs on them, or it wasn't clear whether they were maintained or trustworthy. We've put some work into fixing up all those issues so you can feel safer about playing with them.
Here are some of my favourites!
- The JIT accessbot is an excellent, straightforward example of how to host a Slackbot on your tailnet that can call into Tailscale and Slack APIs. The current version uses our enterprise device posture APIs (also available on personal plans) to temporarily adjust device postures after a request/approval process, which then affects access rights. But you can straightforwardly modify it to cause whatever tailnet changes you want based on whatever triggers you want, or whatever UI you want.
- setec is a sort of "safety deposit box" <ahem> for your keys and other secrets. The hardest part of storing secrets is bootstrapping: where do you put the key you'll use to authenticate yourself to the secrets store? And once you've got all that done, do you really need another secrets store or can you just use that one? But with Tailscale, we already do the auth for you, which means the hard bootstrap problem is solved already. That means setec can be really simple; it's just a secure key/value store and some config settings for who can read and write which things. It's also a great example of how to write an app that's configured by Tailscale using ACL Grants.
- tsidp is the world's smallest OIDC provider. Every Tailscale packet has an identity attached. But, not every app knows how to read that identity from Tailscale. On the other hand, lots of apps know how to auth against an OIDC provider. So, tsidp bridges the two. Ask it for an OIDC key, and it gives you one instantly, because it already knows who you are. And, it even works with apps outside your tailnet (like other people's SaaS apps!), if you export it over Tailscale Funnel. And best of all, nobody can track which apps you use with your tsidp identity — because you, not we, are the identity provider. As always with Tailscale and Funnel, your traffic is end-to-end encrypted and we can't decrypt it ourselves.[13]
- golink is an example of how to make trivial apps using Tailscale's built-in auth, built-in https, and MagicDNS. Install golink in a container somewhere, and then for everyone on your tailnet, you can make memorable "go/whatever" links that redirect to whatever URL you want. No browser extensions needed. Also, um, we would appreciate patches that make it prettier.
- tclip is a privately hosted pastebin alternative with a trivial command-line client. Cut and paste text from the command line, and share it with others. The command line tool requires no login, no keys or tokens, and no magic strings, because thanks to Tailscale, the server always knows it's you.
- The Tailscale plugin for Caddy makes it easy to publish internal services publicly using your own domain name, complete with automatic LetsEncrypt certs and forwarding to your tailnet.
To check out the whole list of tools and extensions, take a look at our brand new and shiny Community Projects home page.
Enjoy living in the future! And please send us your comments on bluesky, twitter... sorry, X, Mastodon, Linkedin, or if none of those work for you, maybe try carrier pigeon or a message in a bottle.
Avery Pennarun
