This past July, we raised $25MM from A16Z and our existing investors, including Intel Capital and Dell. Recently, we raised an additional $70MM led by EQT Ventures.
Why do startups write announcements like these? We went back and forth on it. There are lots of reasons, most of them dumb.
Our first reason is obvious, and mercenary. It’s the same reason we write anything: to woo customers. We’re all adults here, we can talk about this stuff, right? There are customers who are comfortable engaging with tiny Fly.io, and others who are comfortable engaging with the Fly.io that raised an additional $70MM led by EQT ventures. Alcoa: ring us up!
More compellingly, it’s an opportunity to gaze deeply into our own navels. We’ve been talking to users, fans, and detractors about what we’ve been doing, for years. We evolved, and got religion about a particular vision of what we’re building. We shared that with investors, and they bought it (suckers). Now we’ll share with you.
The Two Hour Problem
Here’s what we believed in 2020: apps work better when they run closer to their users. Some kinds of apps, like video or real-time presence, can’t be done without physical locality. So, that’s what we expected to talk about on our HN launch thread: WebRTC, edge caching, game servers.
What people actually wanted to talk about, though? Databases.
Here’s what we missed: we thought there was a particular kind of “edgy” app that demanded global deployment. But it turns out, most apps want to be edgy… if it’s easy.
What’s going on here? Why is edge deployment table stakes for a game server and an untenable science project for an online bookstore? We think it’s because game servers have to be edgy, and online bookstores don’t. The game server team will bang on edge deployment until it’s solved. The bookstore team will try for about two hours, not find a clear path forward, and then give up and move on to other things.
The result of this is an Internet where all of the world’s CRUD apps are hosted in Loudoun County, VA (motto: “where tradition meets innovation”), at Amazon’s us-east-1 in Ashburn, a city with so many Rails apps that one of them was elected to the county Board of Supervisors.
We think everybody understands that it’d be better to run close to users rather than in the Internet’s least worst data center. But with ordinary tooling, getting an app running in more than one city at the same time isn’t a two-hour problem: in two hours, you’ll learn that it’s possible to run simultaneously in Sydney, Frankfurt, and Dallas, but not how to do it, or how long it’ll take.
So our bet is simple: with the right platform and toolchain, people building bookstores, sandwich rating apps, music recommenders, mailing list managers for churches, and every other kind of app will build apps that run fast globally. Not just walking distance from Carolina Brothers BBQ in Ashburn, but in Chicago, or Sydney, or Singapore, or São Paulo. Because being fast in more than one city at the same time is a super valuable feature!
We think this pattern holds for a lot of things. We’re going to track those things down and build them.
For example: sandboxing, code editors and REPLs, and CI/CD applications all have to figure out how to run untrusted customer code. They all figure out how to spin up locked down containers on demand. But being able to spin up a VM on the fly is a super valuable feature for all kinds of apps (as anyone who’s ever debugged a stuck job queue can attest). Why doesn’t everybody do it? Because it isn’t clear after two hours of investigation how to do it. So we built Fly Machines, which makes spinning up a VM as straightforward as calling a function.
We’ve got more things like this coming. Real-time features and user presence are two-hour features. So is encryption and secret storage. And clustered databases. And hardware-accelerated inferencing.
There are other companies looking to solve “two hour window” problems for developers: distributed databases, data locality, storage, AI, app frameworks. If we get Fly.io right, we’ll give those platforms new primitives to build on top of, get new ideas in front of users faster, and ratchet up the quality of every application anywhere.
Sounds like an investment pitch? Well, yeah, it was.
Why We Raised A Bunch Of Money
Here’s what we think it takes to build this kind of platform:
- A hardware fleet. Fly.io has always run on its own hardware. There are fun, technical, “control your own destiny” reasons to rack hardware instead of layering on top of commodity clouds. But it’s really just economics. If you want to get people to build apps on your platform, you need a shot at being around 10 years from now. Hardware is what makes the margins work.
- All the regions. This is subtle! We launched with 19 regions, which, if you’re just serving individual application developers, is plenty. But alongside individual apps, we want other platforms running on us — managed databases, developer tools. And those companies need all the regions. We’re up to 33 regions now, and we’re getting much faster at lighting new ones up.
- Support and reliability. We’re under no illusions about the platform reliability task we’re facing, or about our ability to clever our way through it (we’re not that clever to begin with).
Those things are all capital intensive, and alongside them we’d like to place more bets: on advanced storage, on security capabilities, on new kinds of hardware. So you see where the money goes.
Here’s What’s Not Changing
🎶 There are two kinds of platform companies 🎶 : the kind where you can sign up online and be playing with them in 5 minutes, and the kind where you can sign up online and get a salesperson to call and quote you a price and arrange a demo.
🎶 There are two kinds of platform companies 🎶 : the kind you can figure out without reading the manual, and the kind where publishers have competing books on how to use them, the kind where you can get professionally certified in actually being able to boot up an app on them.
🎶 There are two kinds of platform companies 🎶 : the kind where you can get your Python or Rust or Julia code running nicely, and the kind where you find a way to recompile it to Javascript.
The kind of platform company we want to be hasn’t changed since 2020. Our features are all generally a command or two in flyctl, and they work for any app that can be packaged in a container.
You can take our word for that, but if you’ve already got a working Docker container for your app, you can put us to the test. From a standing start, you should be able to get it running on Fly.io in single digit minutes, and on every continent in just a minute or two more.