Turn And Face The Strange

Image by

Annie Ruygt We’re Fly.io, a public cloud platform that is both our favorite way to put an app on the Internet and our favorite way to safely let a frontier agent coding harness cook. This is a post about our company, the future, and Sprites, which are computers for agents that you can check out right now. This is a complicated post. So I need you to promise me something: if you read past this introduction, you’ll read the whole rest of the way through. It’s an honor thing.

A couple months back, Theo Browne ran a video rating the “best place to host a new application in 2026”. Theo tends to say nice things about us. He did this time too. But then he concluded by saying that of all the providers he pays attention to, we were the one he was least confident would be around by the end of the year.

Well, fuck.

Theo startled us, because we’re in the middle of a run of strong quarters that have included the best financial months in the company’s history. But that take has been rattling around in my brain. It whacked me right on a raw nerve, about what we’re doing and where we’re going as a company.

Honestly, I should’ve seen this coming. Fly.io has been motoring along this year, but I’ve coasted a bit, letting the company smolder in an unresolved identity crisis.

I’m going to overshare some more in a second, but I won’t leave you hanging. So: we’ve raised a bunch more money. We’re launching a new iteration of Sprites, and focusing the company on them and the problem they solve. And I’m tagging in Scott Johnston as CEO. Product-Market Fit I started Fly.io with two clear principles that probably don’t matter anymore.

The first is that Internet applications work best when they’re fast, and that happens when they’re deployed close to users. I learned this over many years of working at Ars Technica, and started Fly.io in part to scratch an itch. It was our mantra over the first several years of the company.

The second is that cloud infrastructure is too complicated. Developers need platforms with the flexibility of AWS and the ergonomics of Heroku.

When we started Fly.io, you couldn’t get both things at the same time, and now you can, here and elsewhere.

You read this and say, “no shit, of course these things are important.” But I’m here to tell you they’re less important than you think, for an obvious reason — the only reason anybody talks about anymore. AI has transmogrified software development. The dingo has truly eaten our baby. † For the past 18 months, every time I’ve said these words, they’ve gotten even truer. I don’t think it’s fully sunk in yet[†]. We’re still trying to integrate coding agents into our profession like they’re sufficiently smart compilers. But AI isn’t like the difference between shipping C code and shipping Ruby. It’s much bigger.

Everybody forgets that before Dan Bricklin invented the spreadsheet, every “Excel document” in the world was a computer program, built by a computer programmer. In just a matter of years, every business professional became a programmer, using the world’s most important programming language, spreadsheet formulas. AI is like that, but bigger. Almost anybody will probably be able to build almost any kind of computer program.

Now consider conventional public cloud infrastructure. We take fixed-function applications built to rigorous standards on fussy CI/CD rails and ship them to audiences of millions of people. But a computer program with an audience of millions will soon be like a spreadsheet with an audience of a million readers. They exist! But they’re not the norm.

Betting on an opinionated public cloud design from 2020 is the same as betting against personalized, adaptive software. I don’t think that’s a good bet. And even if I did, I wouldn’t want to make it. I want a world where my friends and family can make computers do exactly what they want, without waiting for me to build everything for them. What Agents Want That brings us to our second founding principle, which is that serious cloud infrastructure is too hard for developers to use well. And: still true! But this even more obviously doesn’t matter anymore. † It is in fact possible that it’s now worse to have a carefully curated human developer experience with opinionated defaults. Agents work best when things are explicit. To a first approximation, nobody reads documentation anymore. They’re not picking up new CLIs and figuring out how to use them by trial and error, either[†].

That’s what agents are for. An agent can one-shot a Fly.io deployment: just build a site locally and say “now get this working on Fly.io”, and it’ll work great. But an agent can also one-shot an AWS deployment. What are we doing here? What’s going on?

I wrote about this last year, in a post about how our fastest-growing customers were all robots. Then I stopped retconning what we’d already built and got to work figuring out what the robot customers actually want. Here’s what I came up with.

Thing 1: Coding agents expect to run on developer workstations.

Thing 2: Even in a sandbox that you trust, running an agent on your physical dev laptop is annoying, because your laptop stops running when you close the lid. Raise your hand if you’ve walked up or down a flight of stairs with your MacBook open this year. Is your hand down? I’d guess your home doesn’t have stairs. And so people all end up running their agent sandboxes in the cloud.

Thing 3: Public clouds are an irritating place to run agents. We divide servers into “pets” or “cattle”, but for agents, even a herd cow is too much commitment. You want, I don’t know, a semi-disposable cow, a cow that comes into existence exactly when you want it to and sticks around for exactly as long as you want and doesn’t cost very much — and this is why analogies are hard to write.

Earlier this year, our team made what I believe is a breakthrough in systems engineering and perhaps all of computer science: we launched the semi-disposable cow. We call them Sprites.

Sprites take an odd shape that comes from shrink-wrapping them around what I think the robots are looking for. You can create hundreds or thousands of them quickly, but all of them have 100GB durable disk drives. Like everything in the cloud, they have metered utility billing, but the meter doesn’t run when they’re not doing anything, and they’re smart about figuring out when they’re idle. And you can host an app on them and share it with your coworkers, over the Internet.

This grab-bag of features adds up to a proposition about agents. The industry obsesses over sandboxes. But robots don’t want sandboxes.

They want computers. That’s what our semi-disposable cow is: a computer for an agent.

You Can Go Make A Sprite Right Now It’ll take, like, a minute  ✨ Go!→

Computers For Agents I’m happy with how the Sprites launch played out. But honestly, Sprites were a skunkworks project. We didn’t even host them on the main Fly.io website! A weird move. I’m not rationalizing it. We were in an identity crisis. But the clouds have parted, and Computers for Agents are, going forward, the focus of our company. † (to get a flavor of how true that is: a git blame of the whole codebase shows my name more than any other) Fly Machines and our Platform As A Service features aren’t going anywhere. But Sprites was the product of a tiny skeleton crew inside of Fly.io[†], and now it isn’t.

Ordinarily we’d spend thousands of words on deep-dive technical content about how we built any new product we launched. We’ll do that for Sprites too. But I’m pretty deep into this post already and I have other stuff to share. So for now, I’m going to keep it brief.

In addition to behind-the-scenes work we’ve done on scaling and orchestration, nu-Sprites introduces two big subsystems that get us to a place I’d finally consider “feature-complete” for what we’re trying to do.

The first is the Sprite Block Device (SBD). The original Sprites storage stack was a goblin contraption I personally derived from JuiceFS and wired into our system using Ben Johnson’s Litestream. You should be glad to hear that Ben and Tim Newsham tore that whole stack down to the studs and rebuilt it. It’s faster, more reliable, and still does instant checkpoint-and-restore.

More importantly, SBD enables drive forking: you can create a template Sprite, and then efficiently clone millions of times.

The other big new thing in Sprites is Connectors. Connectors build on work we did to secure our core platform: they let Sprites make authenticated requests to other systems, without giving agents anything useful to exfiltrate.