How our free plan stays free
tailscale.com
tailscale.com
This is mentioned in passing, but shows a very good technique. They incentivize technical excellence by tying it to a concrete cost. A free plan, with DERP, is the sacred cow that must not ever be removed. If they don't fix the "ever more obscure situations", then the cost goes up. If they pay an engineer to investigate and fix this, not only does the engineer get to do interesting technical work, and not only does the system become more reliable and "good", they can also think of it as increasing the profit margin of the product (by not increasing costs).
I worked with Avery on Google Fiber, and we did the same thing. Our sacred cow was excellent US-based phone support. That is quite expensive. If there were bugs in our product, users would call in, and our call center costs would increase because we'd have to have more people working. So every week in our team meeting, we would look at summaries of calls, and take on engineering work to address the most common class of problems. That let us scale up the business and still provide friendly and competent phone support, because we were reducing the problems that people called in about. (This was things like having our Wifi access points steer 5GHz capable devices away from flakier 2.4GHz signals, or fixing "black screen" bugs where TV randomly stopped playing for software or network reasons.) Because we had that "sacred cow", every obscure bug that we spent months fixing not only made the product better and were intellectually stimulating to finally figure out, but had a concrete impact on how costly it was to deliver the service.
What most companies would do here to reduce costs is simple. Don't fix DERP bugs, just charge for it. Don't fix "black screen" bugs, just hide the phone number on your website so people can't figure out to call.
Avery has found the perfect balance between cost reduction, interesting engineering, and the somewhat nebulous "good product". Normally conflicting concerns, all living together in harmony. If everyone copied his technique here, the world would be a better place.
There is a reason Comcast is everywhere and Google Fiber is nowhere...
They found out that doing things in real world is hard. So they took their ball and went home. Pretty usual for them.
A good internet provider, though living in a snowy city, the signal can deteriorate a bit when you get heavy snowfall. Still usable, but slow in those cases. The symmetrical gigabit is damn nice 99% of the time.
As for the experiment... I guess the answer was not much? More high definition streaming, some few companies attempting the streaming of games. It certainly hasn't been the panacea of innovation, but it is also still early days I suppose.
It is now at the point where you can't commit to a new google thing and would rather use the competitor instead because you know they will likely outlast Googles corporate attention span...
They also found that when you light a fire under the butts of incumbent telcos, they can deploy modern infrastructure really quickly. And the telcos already know how to get lines on poles and how to site equipment boxes.
They are alive, and they use no opt-in for their marketing emails. I know that because my old gmail account has been getting those mails for over a year already. They keep trying to sell me fiber, but unless they also sell me an address is in the US, it’s not very useful.
(Yes, I could unsubscribe. But I prefer to report every opt-out mail like that as spam and also look at what kinds of opt-out spam I get. Some are even more interesting, unsubscribing requires logging into an account I don’t have access to.)
Of course, you could also lower support costs by having a mostly ignored user support forum.
Traditional relational DBs like Postgresql are very scalable on modern hardware. If you take the time to craft a normalized schema with low redundancy being careful about keeping data small, you can achieve performance and resource efficiency and cache efficiency hundreds of time better than bloated distributed document nosql based systems. You can also get better transactional integrity, reduce reliance on queues (use load balancers instead) and get more instant and more atomic error propagation and edge case resolution. You can really build something lean and mean to a point that would be physically impossible in distributed systems or systems that involve multiple hops over potentially congested networks (as Admiral Grace Hopper likes to remind us, distance matters in computing https://www.youtube.com/watch?v=9eyFDBPk4Yw). As far as I know, normalized relational databases are still the best at efficiently using multiple levels of physically near caches to their full potential. Most applications don't need to scale horizontally and can easily fit on single servers (that can scale to dozens of cores and terabytes of ram).
I hear arguments that it's the engineers that are expensive so it's ok to be wasteful with hardware if it saves engineering time but in my experience the type of engineers that are good at optimizations are often good at engineering in general and the ones that forget to think about efficiency are also sloppy with other things. It doesn't mean you have to write your code in C. Very fast code can be written in high level languages with the proper skills (See projects like Fastify).
I sometimes wonder why we don't have mandatory coursework that demonstrates the upper bound of what a modern x86 system is capable of in practical terms.
If developers understood just how much perf they were leaving on the plate, they would likely self-correct out of shame. Latency is the ultimate devil and we need to start burning that into the brains of developers. The moment you shard a business system to more than 1 computer, you enter into hell. We should be trying to avoid this fate, not embrace it.
We basically solved the question "what's the fastest way to synchronize work between threads" in ~2010 with the advent of the LMAX Disruptor. But, for whatever reason this work has been relegated to the dark towers of fintech wizardry rather than being perma-stickied on HN. Systems written in C#10 on .NET6 which leverage a port of this library can produce performance figures that are virtually impossible to meet in any other setting (at least in a safe/stable way).
This stuff is not inaccessible at all. It is just unpopular. Which is a huge shame. There is so much damage (in a good way) developers could do with these tools and ideologies if they could find some faith in them.
I learned about engineering away support costs from Robert McNeel & Assoc (RMA). They used to sell AutoCAD. The value added reseller racket is to slough off support costs onto their dealer channel, which Autodesk did shamelessly. (Probably learned from auto mfg.)
RMA thought about revenue in terms of ROI and velocity. Instead of increasing margins, RMA reduced transaction costs.
So RMA made AutoCAD add-ons, nominally low price but actually given away, to reduce support costs. Stuff like plot drivers which actually "just worked". Over time, customers learned that TOC working with RMA was lower and hassle-free.
--
I applied this strategy as an engineering manager. I had inherited some products (necromancy) with a lot of technical debt. There was intense pressure to add features, restart the software upgrade revenue (long before subscriptions).
I insisted on also chewing thru our hottest support costs. Burned A LOT of political capital and goodwill. (One of my rationales was that our small team simply didn't have the resources to manage the high support burden.)
The intangible, unquantifiable benefit was that velocity improved for every one of our products. Each release got easier and proved more rewarding.
It was like printing money. Our customers sold our products for us (word of mouth). So we saved even more money (less need for marketing).
We somehow created a virtuous cycle.
--
Back then, I had guessed that tech debt piles up because of suboptimal bookkeeping. The costs of poor quality were externalized. Meaning lazy, aloof devs cutting corners increased costs for QA and tech supp. And worse, negatively impacting sales and marketing.
Today, I'm not so sure. Unifying dev and supp (DevOps) hasn't improved quality. Maybe poor quality is something like a natural law. Sturgeon's Law applied every where. The only big examples of aggressive continuous improvement I'm aware of are Musk (Tesla & SpaceX) and Haier. And probably Apple too.
But it seems they attain their results by whipping their employees. Whereas back in the day, we improved quality by doing less work (taking the time to save time).
FWIW, Sandy Munro of Munro & Assoc remains an outspoken proponent of 90s era concepts like quality, continuous improvement, "muda" (remove waste), etc.
If any one has other links, resources for 3rd millennium era quality obsessives, please share.
Mesh VPNs have substantial control over networks that they manage (they bypass firewalls by having users instal agents from within). They could add hidden nodes to networks, which is a major security concern, and see who is taking to who, how long, what service they are running, etc, which can be a privacy concern. They are targets.
Is there a way to address these concerns, and make them “really” (not just on website) zero trust or at least minimal trust? Will Wireguard preshared keys as an option help (a maliciously added public key lacks a secret key exchanged among peers out of band)?
What are the implications of the substantial control that Tailscale has?
Or we have no way, but to trust someone? Looking at events of the past decade, I don’t have a good feeling about this!
The concern is that, if an attacker (such as a government) compromises Tailscale, or Tailscale wants, they could probe your applications. It would be like your SSH being exposed to internet.
These products bypass firewalls, which is a good thing if they are secure, and a terrible thing if they are not.
There have been cases where the coordination servers have been (sometimes silently) compromised; see stories about encrypted phones. Users thought they were secure.
And unfortunately small companies may not have sufficient resources to secure their infrastructure against more resourceful adversaries.
That’s why it’s better to pay, so that the startups have funds to improve the product.
Isn't the main alternative also an ACL, just in the form of a more course grained firewall? The idea of these networks AIUI is that some of the existing infra, such as firewalls and even application level encryption, are replaced by something that is subjectively easier to administer and monitor. Not saying it is better, just that's it's different. And if it's different, then it makes sense that the attack surface is different too.
This is the direction I'd like to see networking go in general. Everything can have a public IP, but applications won't talk to anything that's unauthenticated. No more VPCs, VPNs, "kubectl port-forward", jumpboxes, etc. In practice, this is a colossal pain that nobody really knows how to do right. It requires rewriting all existing software, a secure way of issuing certificates (ideally not controlled by the cloud provider that runs your applications), and it can very easily fail open.
(I do mTLS for my personal projects, but my cloud provider can easily issue themselves a trusted cert and use that to poke around if they really wanted to. They own the machines that my CA runs on, so they are the root of trust. At some point, what you end up with is something that feels correct, but is in practice the same thing as just trusting Tailscale. The first 99% of security is making sure some rando on the Internet can't download your HR database and secret plans for world domination. The remaining 99% of security is making sure the NSA can't do that. Maybe you're OK with the NSA mucking about with your internal network, and in that case, you can save yourself a lot of trouble.)
However, it's very cumbersome to setup, nowhere near as easy as Tailscale.
We believe that our security, performance and integration with the rest of Cloudflare are already quite awesome. We're going to raise our usability by quite a notch with the news coming up. Stay tuned with blog.cloudflare.com
(I work at Tailscale)
Even with a on-prem control plane, you probably want logging setup to detect when unusual nodes get pushed to the accessible list of nodes on your clients.
It doesn't matter that you've authenticated to the network, you still need to authenticate to the application. SSO and the like become increasingly important in this kind of world mind.
It's not not a concern, it is something you can think about and work out how to mitigate, but the benefits to their product of Tailscale hosting the control plane are going to outweigh the objections.
Just getting access to our Tailscale networks doesn't get you anything; having your account in a group with access to an application gets you the right to attempt an SSO login to it and nothing else.
I mitigate the potential risk of a compromised control plane by using secure protocols on top of Tailscale. Namely SSH and HTTPS with a custom CA and proper authentication wherever possible.
Cloudflare, who almost single-handedly pushes the CDN industry ahead. So much respect for what they do and how they explain it in easy to understand terms.
IntelliJ family of IDEs and their extensive release notes and forum discussions; it can be a bit overwhelming and disorganized at times though
My personal favorite headless CMS: DatoCMS, small company but highly involved devs and iterating very quickly
Google USED to be really good at this long ago, but since Alphabet, they've become less and less transparent and more and more evil
Airtable, for bridging that gap between Excel and a proper database, with a heavy focus on UX and great release notes
I will say to Google's benefit, the Data Studio team is building a pretty nice product, but there are some crazy gaps and the custom connector docs leave a lot to be desired.
The other software I'd put in that bucket is Caddy.
As a long-time Next.js user, I'm deeply disappointed by the way Vercel (the company, fka Zeit) has so tightly coupled vercel (the platform / hosting service, fka 'Now') with Next.js (the framework). I absolutely loved Zeit (the company, before it was rebranded Vercel), with its amazing DX-first ecosystem. But now, to the detriment of it all, only those specific patterns of Next.js usage that align perfectly with the vercel hosting platform's opinionated approach are treated as first-class citizens. Vercel the company makes its money from vercel the hosting platform, and it employs all the Next.js maintainers. As a result, simple economic incentives have shaped the framework, making it much more rigid and limited than it'd otherwise be.
Examples include:
- proper support for "12-Factor App"-style immutable build artifacts, deployable to multiple envs (eg DEV, QA, STAGE, PERF, UAT, PROD). The way .env files are handled makes this incredibly cumbersome. Vercel only supports (local development) + (preview deploys) + (production), so for anything outside that tri-fold paradigm you're on your own.
- removal of support for custom servers
- reliance on unofficial 3rd-party serverless framework to support deployment to Lambda@Edge, and problematic or missing documentation for any non-Vercel serverless deploy target
I still think Next.js per se is pretty great*, but in my direct experience working with consulting clients to leverage it in their non-Vercel, multi-environment infrastructure, the pain points are significant and caused largely by the coupling I described.
If you embrace vercel as the hosting platform, with its specific conventions and limitations, and can accept severe vendor lock-in, then sure, it's going to be a pretty smooth ride.
*For my part, when it comes to picking a React-based framework that provides SSR / BFF, Remix.run is looking better and better all the time.
I see the same thing with $CURJOB, which has a downloadable, self-hostable fully featured solution. The operational dynamics are different (it is harder to convince folks to run software themselves than to sign up for a SaaS, all other things being equal) but the overall dynamic is the same: offer a spectacular free product to allow for scaling customer discovery and word of mouth, then charge for things that people with money care about:
> At each level, the value proposition is different, so that users use your tech differently and benefit differently from it. And at each level, the buyer is different, so the messaging is different.
This is market segmentation 101, but it's nice to read about it from an infrastructure company perspective.
One thing they didn't mention which I would in their shoes is how powerful $0 is in terms of letting folks kick tires and self-select their solution. (Or not select it, which is fine too.) Especially for dev focused products, a $0.01/month charge is such a barrier compared to a free solution.
I was just thinking about this, I tried a hosted solution with $25 in free credits the other day and liked it, so we're now using it. It's not that we needed the $25, but if I had to talk to finance and get authorization first, we would never have gone with it.
Free trials work, I guess!
They reduce the sand in the gears, for sure.
Same with educational material, especially if it useful beyond the service providing it. (See Digital Ocean's playbook, including their purchase of CSS Tricks.)
> It's not that we needed the $25, but if I had to talk to finance and get authorization first, we would never have gone with it.
This is it, this is the truth!
Every single developer tooling company should have this tatooed on their collective forehead. Or something like that :) .
What are some good resources / blogs on the topic? Also: Am I right to assume that market segmentation is what product people call "personas"?
Market segmentation is which features and offerings apply to which buyers and what can you charge them. I don't have a great reference, though. So here's a grab bag:
Patio11 talking about segmentation w/r/t SSO: https://threadreaderapp.com/thread/1481293027331440640.html
Here's a non-tech focused piece on market segmentation: https://www.investopedia.com/terms/m/marketsegmentation.asp
This article seems to cover the basics: https://www.albertocarniel.com/post/market-segmentation
I like the folks at Reifyworks for all their developer marketing writing: https://www.reifyworks.com/writing but they don't cover segmentation directly that I can find.
- People living on retirement income generally have less spending money than mid-career professionals. - Companies recognize this so they offer "Senior discounts" for those over 65 years old. - The old people who have less money save money by presenting an ID proving their age. - Boom, you can now choose a different (profit maximizing) price for the groups of older and younger consumers.
Basically, if you can check membership in a group or get people to self select into different groups (based on features, pricing, convenience, etc), you can charge different prices to each group. This is a great way to increase profit.
Hope that helps with the basic idea. Source: I am getting a PhD in economics.
Sometimes it can be a useful filter. There are a lot of time wasters at the bottom end of the market. There could also be people who are willing to pay but the free tier is good enough for their requirements.
Since the marginal cost of delivery of software is essentially zero, it turns into a customer service and marketing question.
> There could also be people who are willing to pay but the free tier is good enough for their requirements.
Sure. Again, will you turn off more folks and lower growth by charging? Or is it better to let some folks use your software for free and not capture all of the consumer surplus as a company?
But credit to David Anderson at Tailscale. Their NAT traversal article is excellent, the best I've seen on the topic: https://tailscale.com/blog/how-nat-traversal-works/
We found the best solution was to claim that pricing kicked in at certain usage tiers, whereas everything is actually free all the time.
We don’t measure it at all, but there’s plenty of companies we know are over 1k users.
Plus, this is a great blog post on its own merits. Someone like me (who has never used Tailscale) might find this interesting just as an explanation of SaaS economics. That might lead to me actually using Tailscale, or applying for a job there, or whatever.
Even if 1% of users are satisfied by this post... that's a lot of people!
And if it gains them even one enterprise client, I'm sure that's a massive ROI.
Asking from a place of curiosity, I don't quite understand this company. I suspect it solves a lot of issues related to provisioning your own networks ... Which would explain why I don't quite get it because I've never done that.
I will say, and I think this is right, the proposition here isn't a VPN like Nord which you'd use to hide your traffic from your ISP or masquerade into a different geolocation, but rather a VPN for connecting to your own devices.
Can you really not see the difference between this[0] and this[1]?
This really feels like a "What's the value in Dropbox when everyone has access to rsync and bash?" situation.
I think it's more like... "What's the value in Dropbox when I'm already running Nextcloud?"
I won't talk much about ACLs since if you're the only user on your VPN, they don't matter. E.g. I use Tailscale but I don't use ACLs because who am I going to block from connecting to what? Am I concerned about my server trying to compromise my Raspberry Pi? (Maybe I should be, but life's too short so I don't bother.)
Automatic peer configuration is a pretty killer feature, though. If you're just running plain vanilla Wireguard, then you have to manually copy keys between every pair of devices that need to be able to talk to each other. That's fine if you only have a few devices, or if you have a large number of devices but you're happy to use a hub-and-spoke model where each "client" only talks to the hub, and the hub routes all traffic. But once your number of devices starts to grow, or you decide you want direct links instead of hub-and-spoke, it can start to get unpleasant.
NAT holepunching may seem unnecessary if you're used to having a VPN hub and just port-forwarding to it. But it opens up a whole set of possibilities that would just be non-starters without it. Just off the top of my head, here are some things that I would consider easy with Tailscale but cumbersome-to-impossible without:
1. Not having to worry about static IP assignments on my LAN. Admittedly, this is more of a convenience than a true barrier to anything, but with vanilla wireguard one of the devices needs to be able to initiate the connection, meaning that the other has to be able to receive unsolicted traffic on some port. Normally I'd do that with port forwarding, but all of the port forwarding I've ever done requires a fixed internal IP to which to forward the port. Instead, with Tailscale, you can just plug in your server/RPi/whatever and forget about it.
2. Similarly, you can take advantage of this to get a window into a network that you don't control. (It sounds bad when I put it that way.) Say you've got a relative a long ways away, and they're constantly calling you for help with their network and you're constantly walking them through how to fiddle with their router settings or something - with Tailscale, you could just preconfigure a Raspberry Pi, ship it over, and not have to worry about being able to connect to it once they plug it in. Voila, you have an entrypoint into Grandma's network or whatever.
3. Self-hosting afficionados like myself tend to turn to "can I put a thing on a server somewhere" as a solution to many problems involving cross-device communication: file synchronization is an obvious example. But what if all the devices could seamlessly talk to each other, anywhere and anytime? Then you could pop, say, Syncthing on each device and not have to worry about having a server up.
Tailscale also has some extra goodies like being able to share a device to someone else's Tailnet, so if you run (say) a Plex server and you want to let someone else talk to it without exposing it to the greater internet that's pretty easy.
Their "Magic DNS" feature is also quite convenient - I used to pride myself on being able to remember all the IPs I had assigned to all my network-connected stuff and therefore not needing DNS, but since I've started using Tailscale I've found myself defaulting to DNS names more and more without ever even consciously deciding on it. Words are just more memorable than numbers, there's no need to fight it.
All that said, if none of those use cases seem compelling to you then maybe Tailscale just isn't for you. Different strokes for different folks.
Tailscale is also deceptively powerful, and that's why people love it. In particular: getting WireGuard deployed across a whole team with a single source of authentication truth and role-based default-deny ACLs is not, in fact, very easy to do. The massively more common pattern in tech companies with access VPNs is something like OpenVPN, with separately-managed credential stores (that get desynced and lock people out --- or accidentally retain access for separated team members) and default-allow network policy that gives anyone with access to the VPN direct access to Redis, databases, staging instances, and stuff like that.
I don't just like Tailscale. I fucking hate Tailscale for how simple they've made one of the larger problems in corpsec. It's maddening.
So let's say the local government blocks access to certain content, you can connect to a VPN provider's network, select an exit point (a server) and your traffic is routed through them. But this can be monitored by that provider and I read an article recently that highlighted a lot of free VPN providers cannot be tracked down to companies, so you couldn't say who is running those servers. Which means, you don't know if all your traffic isn't actually recorded in the end and sold on to someone.
This brings me to the first difference - you can setup your own server (at home or more likely through an infrastructure as a service provider like Hetzner, Ovh, DigitalOcean, etc) and install Tailscale on it and on your device(s). This way your connection is secured to the server and the server is the exit point now. Your provider in this case, cannot see what your server is serving you. The added control here is that the server IS YOURS, so you can clear logs, take it down and setup another one and so on.
The second difference is that a VPN in most canonical cases has a client-server construction. But this means that there is a hierarchy and that all your devices use that server as a gateway of sorts. If I understand it correctly, Tailscale acts as a mesh that is laid on top of your existing connections, but it means that devices that you connect to the same mesh, behave as if they were on the same LAN network, but over the internet. So let's say you're on holiday, you can connect to your home computer (assuming your device and your home system have Tailscale, an internet connection and are running ofc) as if it was on the same network. Because it is. It's on a virtual network where Tailscale creates these connections and manages the IPs on the network. So you can view your movies, copy over your pictures from your phone to your home computer and so on.
You could also maybe have a home server which might be running a number of services. Enabling SSH over the internet has it's risks, but Tailscale could alleviate a lot of these risks because you would have a fixed IP on this virtual network and so does your server. So suddenly, you can define a rule on your server firewall that says "hey, block everyone, except THIS ip".
Lastly, you could maybe even just share pictures, documents and whatever else with friends, family or anyone else who is running on the same Tailscale network.
I really hope I haven't completely misunderstood the service and I'd be happy to get more clarity or some better examples. These are SOME of the use cases I can think of, but there are probably more! Btw, I don't use Tailscale, I am considering it after having considered other mesh networks like Yggdrasil as that's the part I'd be interested in...
I have a Synology on my home network which I use for Time Machine backups among other things. My Mac has a Tailscale client and I can backup to my Synology from anywhere.
I have a number of random servers I keep for hobby stuff, a mix of hosted bare metal, VMs and VPS. None of them have SSH open to the internet. My access is all over Tailscale. It was super easy to setup, and now I never have to touch it. Occasionally I'll see that the Tailscale daemon was updated on some host.
If I were starting a company today, as soon as I had any resources that needed any kind of remote access for the team, I'd use Tailscale to provide that access.
I have been pondering setting up Tailscale just to get remote access but I haven’t found good examples of people doing this.
Thanks!
Then I can check experiments from wherever without worrying about a lot of the fiddly details.
Tailscale unfortunately uses user-space wireguard still - other than that I think it's a strict "value-add" on top of manually configuring wireguard.
The option to route traffic through an exit-node can also be useful (make your phone behave as if it connects through your corporate VPN, with the fixed IP address that your clients white-list for access, for example) - but it's not the primary usecase.
While "VPN Services" like Nord are really anonymizing internet access providers routers - and while technically using VPN-technology, they're not really enabling Virtual Private Networks in a meaningful way - it's just your computer, and their exit-node - a tiny network of two - and they don't have anything to talk about - the exit node doesn't run a web site or a service - it's just a router.
A good alternative is: https://github.com/tonarino/innernet
I'm not affiliated with Tonarino. But sure its interesting: https://tonari.no/
So what they are saying makes sense but is very far from revolutionary.
To compare, logistics was Amazon's main cost driver and yet Bezos mandated to not only make it free for Prime customers but deliver orders in 2 days! This forced Amazon on a path to optimize the hell out of fulfillment and logistics so much so that they now own airports and cargo planes, build electric vehicles for middle mile and last mile themselves, have a tremendous network of distribution centers across the US / world etc. In essence, sustaining Prime drew a proverbial moat around Amazon (though, companies like Facebook, Snap, Uber, Instacart, Klarna, Alibaba, Wish have inflicted damage, inspite that).
Cloudflare's doing the same with bandwidth.
Performance and stability especially on SMB shares and ARM based SBCs is so far way better than on zt
They were on the short list for deploying an overlay network for work, and when I started thinking hard about it, I was concerned about availability if their controllers went down, I didn't want to tie our availability to theirs.
So I asked their sales a question about if we could host a backup controller or something to allow our network to operate if their controllers went offline. It took (IIRC) a couple weeks to get a reply and that reply was along the lines of "It's impossible for all our controllers to go down, but if you want to self hose you lose the web UI." I replied linking to a ZeroTier tweet saying "Hosted controllers are coming back up" and asking "What was the event referred to in this tweet", and got only crickets in response.
So I'm planning on going with Nebula, but also keeping an eye on DefinedNetworking.
https://twitter.com/ZeroTier/status/1389766385480372225?s=20
You should check them out. Lots of videos showing interesting features over on youtube too if you like a video... https://www.youtube.com/channel/UCAsrfQasdZmp2Gq07Ej_5cQ/vid...
But I don't want to use them when they don't support email based logins. I did read their explanation[0], but I am not sure how it actually makes sense - if they don't want to have passwords, why not a client cert?
All those stories like "Google blocked my account without recourse and don't answer tickets anyway" have put me off. I lost editing rights to a Google My Business profile that I was the sole owner of, because they gave third party input precedence over the owner's own entered data (opening times of all things) then locked the ability to update it, so I know loss of control over one's own account isn't that rare with Google.
It's not just Google. So I trust my domain provider more than I trust any third party SSO, because I believe I have legal ownership of domains in case all else fails. I don't seem to have equivalent rights over SSO accounts at any third party. So, for now until something better is available, email-based accounts are a must-have for any critical service.
But they don't trust Google, and have been looking for a way to migrate everything away (IdP, docs and email) for some time.
Everything you said about the benefits of IdP, SSO and enrolling/offboarding employees is spot on.
The only problem is that some third party IdPs aren't as low-risk as they seem, if you're a small entity who cannot get corporate support in case of a problem. The risk is small but not enough, and the consequences for a small entity are severe. Loss of access to docs, email and your other service provider logins can kill a business.
For larger tech companies the support hotline will answer, so it's not a problem and it makes sense to outsource. It would still be better if the company had legal rights to their own credentials on IdP as a backup, though, similar to the way they have legal rights over their domains.
It's also not super great for some workplaces because tailscale kinda...gets superpowers in your network.
It is definitely something smaller companies are using though.
There are banks [1] using Tailscale. If their security concerns can be addressed, I'm sure it can work for pretty much any company.
It's an easy way to get remote access to services when away from home, or when the family lives in different homes but wants to share services. I wrote a guide explaining how to set up remote access for Jellyfin using Tailscale[1], which may illustrate the use case.
[0]: https://tailscale.com/kb/1084/sharing/ [1]: https://www.ethanmad.com/post/jellyfin_remote_access/
> The Community on GitHub plan can get you up to 25 users, 5 devices per user, and 2 admins for free.
I just installed the tailscale app on my home assistant server (ubuntu) and then installed it on my iPhone. Then once they're both logged in I can use the IP address in the tailscale app to connect to the server from anywhere.
Like mentioned in the article it just works and is perfect just the way it is, for free. I don't need any extra features or improvements.
if i have to add a node, i install the app on the device, open the account, copy the code and authorize it and done. no config, ever.
can anyone tell me what is the difference between free account of zerotier and tailscale? the configuration, management, setup, ease, limits?
again, zerotier is set up once and forget. oh, no login on the clients as well, they are preconfigured because they use a key and that key gets verified in the client so no login issues even
I don't mind paying for a service. But to use Tailscale for personal use with a commercial identity provider would get into the "prohibitively expensive" category for me.
Paranoid firewalls blocking NAT traversal are a pain. I am running a private DERP relay to get around public relay congestion. I also have a subnet relay running - I am watching which solution will be long-term more performant and reliable.
Their ACLs definitely take some getting used to but I think I have things about where I want them.
Surprising issue - conflicting address ranges between home users and corporate network prevent subnet relays from working seamlessly.
Centralized logging would be a cash-worthy feature.
Adoption by the team is a bit slow, most people are still using SSH tunnels despite the clumsy nature.
Conflicting address ranges for subnets isn't especially surprising to me. Making sure your corpnet isn't on 192.168/16 probably is the most helpful thing to do there.
I run a pastebin server using the legacy t1.micro AWS instance - or even less, i run it on lightsail now. upon reboot, it sets up ~250MB of tmpfs, unzips the actual server code - nodejs in this instance - to tmpfs, and sets the data directory in tmpfs as well. The only way it could cost me a ton of money is someone maliciously requesting the same paste from thousands of remote machines, but my understanding is amazon would reverse the charges, and i'd probably just not run the service anymore. I can almost as easily paste and link stuff using mattermost - except full-frame images from one of my cellphones, which i can't figure out! there's no setting to allow larger format images anywhere in the configs. So i'd be out a few dollars, know that someone had it out for me or one of my anonymous users, and just walk away.
I would miss being able to upload obscenely large (108MP) images and pinch zoom them forever, which is a quirk of the pastebin software i chose.
I'd be more worried about the VC funding they've taken ($15M according to crunchbase). It may take years, but eventually, somehow, VCs will need to get their money back. That may be an IPO and then public market scrutiny, it may be acquisition, but if the company is a going concern, the VCs will want ROI.
> Our free customers create scale, serve as efficient brand marketing, and help us attract developers, customers, and potential employees...
So for as long as they note that free Tailscale users are worthwhile for how they are effectively free marketing and attract clientele, it shouldn't be a problem. Tailscale doesn't proxy traffic either so the overhead of having free tier customers shouldn't be huge.
0: https://github.com/judge2020/cloudflare-connectivity-test/wi...
Grandfathering in old ones for a decade after that seems about as generous as businesses get.
Anyone figured out how to bridge the gap from legacy here?
Running a subnet router is a matter of installing the Tailscale package on a server and authorizing it to route traffic to certain subnets over Tailscale.
Maybe we're just not normal? (UK/EMEA, public company)
Many companies just run tailscale in a VM to replace their physical VPN concentrator boxes.
if the named service completely integrates with whatever access control a company uses (radius, SAP, whatever) then there shouldn't be any reason to not use this in lieu of concentrators. At least you lose that bottleneck and point of failure. For larger and more geographically disparate companies, i could see this being an even better proposition, but only because this is merely the second time i've seen tailscale at all.
All i know is i've used wireguard recently, and it took me a few tries to get it to do what i wanted. a decade ago i was trying to get some corporate VPN software working on Gentoo, and i managed to cobble enough correct settings to get it working, too. I don't wish that on any user.
I loathe setting up a dialer to connect to a VPN, and even worse is the 3rd party app "ssl VPN" junk - most of the ones we've tried just lose settings on my computers, to the point where dark fiber seems like a better investment of my time.
I'm not sure how high priority this is. We've been wanting a way to force traffic over a private network, for example, but it's still not possible. It's really the only thing we've asked for for our business, and we hope they will introduce it soon, it's easier keeping a lot of ACLs in one single place.
To clarify, we are a happy paying customer.
(I’m aware of headscale as an open-source control plane, but the iOS client is still closed-source and hard-coded to only use the first-party control plane :( )
Headscale has the preauthkey, it is still valid even but I need to do the tailscale up --login-server ... dance every time to get it connected.
Not ideal.
I've probably logged in a grand total of two or three times (during initial testing in Jan). Everything "just works" for us.
> defaults write io.tailscale.ipn.macos ControlURL ...
Know who you are on Google and associate you with the personal info you have made public
“First, the protocol should be based on UDP. You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go. We’re going to focus on UDP for the rest of this article. If you’re reaching for TCP because you want a stream-oriented connection when the NAT traversal is done, consider using QUIC instead. It builds on top of UDP, so we can focus on UDP for NAT traversal and still have a nice stream protocol at the end.”
That article is the best article I have ever read on the nitty gritty of how NAT traversal works.
“We’ll probably also still want fallback relays that use a well-like[d] protocol like HTTP, to get out of networks that block outbound UDP.”
“Having relays to handle the long tail isn’t that bad. Additionally, some networks can break our connectivity much more directly than by having a difficult NAT. For example, we’ve observed that the UC Berkeley guest WiFi blocks all outbound UDP except for DNS traffic. No amount of clever NAT tricks is going to get around the firewall eating your packets. So, we need some kind of reliable fallback no matter what.”
Well no, Tailscale's free plan is free because this is a user acquiring strategy (as it is described later in the article ) not because of your low cost. You could have a higher cost and still be free and typical Saas companies have the exact same reasoning than Tailscale, that's why Notion has a free plan, that's why Cloudflare has a free plan.... That's the whole point of a freemium model. What VC call product led growth.
The if you are not paying you are the product is true for free products not for freemium
Ie high enough and you're doing sketchy shit and selling every ounce of user data you can because you have to recoup some of the user costs. Low enough and users could "just" be a mind-share cost.
If true, the devil is really how the user has no information here. All we can do is assume we are the product and they're fully-evil. Unfortunately.
They’re solving a problem that, in the past, has caused me to be dramatically less productive. I set up Tailscale on all my devices in 20 minutes. It’s like magic.
You can bet that the next time I’m working somewhere and we face a problem Tailscale solves, I’m going to advocate to use it.
I wonder how companies split their features among pricing tiers? what is the right feature split between free and paid (in the context of B2C)?