Blog

Just over a year ago, we founded Tailscale with a common sense of nostalgia for the “good old days” of LANs. In our collective opinion (then and now) networking and cloud infrastructure has become too complicated. Attempts to increase team connectivity and migrate towards remote work results in a corresponding burden of security. This reduces productivity. Systems and approaches don’t scale without significant time and effort. Everyone suffers.

That’s why we are happy to announce that we’ve raised a $3M seed round, led by Heavybit with participation from Uncork Capital and others. This investment sets the expectation on what we’re aiming to achieve: a return to simple computer networking for everyone that works anywhere you can access the Internet.

People often ask us for an overview of how Tailscale works. We’ve been putting off answering that, because we kept changing it! But now things have started to settle down.

Let’s go through the entire Tailscale system from bottom to top, the same way we built it (but skipping some zigzags we took along the way). With this information, you should be able to build your own Tailscale replacement… except you don’t have to, since our node software is open source and we have a flexible free plan.

We have some catching up to do. Tailscale opened our waitlist for signups in April 2019, almost a year ago, but we haven’t shared much news! It’s time to rectify that.

Over the past 11 months we’ve grown the team and narrowed our focus to just one core product: a company-wide mesh overlay network based on the WireGuard® VPN.

As a “fully remote work” company, we had to make some choices about the technologies we use to work together and stay in touch.

We decided early on — about the time we realized all three cofounders live in different cities — that we were going to go all-in on remote work, at least for engineering, which for now is almost all our work. As several people have pointed out before, fully remote is generally more stable than partly remote. In a partially remote team, the remote workers seem to always end up treated as an underclass, overlooked in meetings, bypassed for promotions, fired when they eventally refuse to relocate because the remote work policy inevitably changes (hi, Yahoo!), etc.

The good news with our plan is the founders could “dogfood” a few different remote work ideas ourselves before we ever hired anyone. So we decided to try some stuff. Here’s what we discovered.

Some news — we have deb and rpm package repositories up!

pkgs.tailscale.com

Currently serving unstable-track packages for tailscaled, a replacement for our current linux relaynode.

If you’re brave, give it a try! Stable release with docs coming soon.

We just made the first bits of the Tailscale code public, starting with the Linux client and its dependent/common code.

https://github.com/tailscale/tailscale

Still lots of rough edges & TODOs everywhere so temper expectations accordingly. We want to hack in open and not wait until it’s perfect.

I used to tolerate and expect complexity. Working on Go the past 10 years has changed my perspective, though. I now value simplicity above almost all else and tolerate complexity only when it’s well isolated, well documented, well tested, and necessary to make things simpler overall at other layers for most people. For example, the Go runtime is relatively complex internally but it permits simple APIs and programming models for users who then don’t need to worry about memory management, thread management, blocking, the color of their functions, etc. A small number of people need to understand the runtime’s complexity, but millions of people can read & write simple Go code as a result. More importantly, Go users then have that much more complexity budget to work with to build their actual application. I would’ve never built Perkeep had I needed to fight both its internal complexity and the complexity imposed on me by other contender languages/environments at the time.

All that is to say, simplicity is not only refreshing, but it also enables. Go made me feel productive in a way I hadn’t felt in many years where everything just felt like it was getting more complex. Ever since finding Go, I’ve been regularly hunting for other technologies that provide simplicity as a feature.

I started programming in the 1990s living above my parent’s medical practice. We had 15 PCs for the business, and one for me. The standard OS was MS-DOS. The network started off using IPX over coax to a Novell Netware server, the fanciest software we ever owned. IPX was so much easier than TCP/IP. No DHCP and address allocation, it just worked.

Eventually the PCs would run Windows, and a Windows NT server took over file sharing over TCP/IP. The business software survived this transition unchanged, though there was more operational overhead. We assigned IPs manually.

Long ago, I wrote git-subtree to work around some of my annoyances with git submodules. I’ve learned a lot since then, and the development ecosystem has improved a lot (shell scripts are no longer the best way to manipulate git repos? Whoa!).

Thus, I bring you: git-subtrac.

It’s a bit like git-subtree, except it uses real git submodules. The difference from plain submodules is that, like git-subtree, it encourages you to put all the contents from all your submodules into your superproject repo, rather than scattering it around across multiple repositories (which might be owned by multiple people, randomly disappear or get rebased, etc).

Identity on the internet is messy. The result is some things that should be easy are hard. The Identity Stack This is an attempt to document how we define a person on the modern Internet. It is analogous to an OSI model for identity. Layer 1: IP addresses The story so far: In the beginning the IP address was created. This has made a lot of people very angry and been widely regarded as a bad move. IP addresses give us everything, and yet surprisingly little. Scribble one on a packet, send it out, and maybe it will get somewhere. Where is anybody’s guess. After a while some packets come back with the that IP address in the sender field. Maybe it’s from them, maybe it makes sense, maybe some got lost on the way. Layer 2: Brands Next come the true foundation of the modern internet: brands. A brand is a domain name that you recognize.

I am leery of jargon. I am as guilty of using it as the next engineer, but there comes a point where there are just too many precise, narrowly-understood terms polluting your vocabulary. The circle of people you can talk to shrinks until going to the store to buy milk feels like an exercise in speaking a foreign language you took one intro course to in college. Less jargon is better.

Thus the first few times I heard the terms zero trust network and microsegments I ignored them. The conversation went on even though I was a bit confused. Eventually I heard these enough that I had to figure out what these words mean. Turns out they are useful!

So what are they?

Growing up, I, like many computery people of my generation, was an idealist. I believed that better, faster communication would be an unmitigated improvement to society. “World peace through better communication,” I said to an older co-worker, once, as the millenium was coming to an end. “If people could just understand each others’ points of view, there would be no reason for them to fight. Government propaganda will never work if citizens of two warring countries can just talk to each other and realize that the other side is human, just like them, and teach each other what’s really true.”

“You have a lot to learn about the world,” he said.