Turn And Face The Strange

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.

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.

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.

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.

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. Connectors have fun security properties, but are also much more pleasant to use than manually managing accounts and API keys.

These are our most requested features. They’re the reason so many agent companies are still using Fly Machines many months after we launched a product specifically for them. So I’m confident enough to bet: unless some new space alien technology arrives that does something even weirder to computer science than what Transformer models have done, Sprites are the right fit for our future customers, and a very large portion of our existing ones. Which brings us to:

I Quit

This has been a little while coming, but for the stage Fly.io is at, I think it’s extracted most of the good stuff out of me being CEO. So I’m going to stop doing that.

For the first several years of a startup, you’re running a science project, an experiment-driven search for product-market fit. As anybody who’s worked here can attest, we tried dozens of things, from unmanaged Postgres (never do this) to global CDNs to user-mode WireGuard. Deeper into the company fabric, we built a bottom-up engineering org, avoided product roadmaps, and recruited an all-remote team with members in over a dozen countries.

Some experiments paid off, and others were learning opportunities. Running them has been my whole life over the last 8 years. But Fly.io doesn’t need these kinds of science projects anymore.

For the past many months, stretching way back into 2025, I’ve been talking to Scott Johnston about what Fly.io would look like if he was calling the plays. Scott was the CEO of Docker, and led that through a really challenging time that began with Docker’s own enterprise-vs.-developer identity crisis and ended with them blowing the doors off the business. As a shareholder of Fly.io, for this stage in Fly.io’s lifecycle, I liked his playbook better than mine. As the CEO of Fly.io, I liked the prospect of him doing all this work more than I liked the prospect of me doing it. We took a lot of time to work this out, and ultimately the board and I convinced him to take the job.

This is the paragraph in these kinds of posts where I’m supposed to tell you why Scott is a perfect fit for Fly.io and recount all his past adventures. And he is, and they were majestic. But you already know what I’m going to say here, which makes it boring, and Scott can introduce himself just fine when he wants to. He’s not shy.

Meanwhile, I’m going to do what all the smart spent founder CEOs do, and move to an advisor role parachuting randomly into product design discussions (the fun part of my job) while using my board seat to annoy Scott as he executes what (for me) was the unfun part of my job better than I could have.

One of the things I’m sure Scott will break down is the fundraise we just did. That’s another thing Theo Browne called out in his video (I’m not mad, do I sound mad?) — that we hadn’t announced a raise in several years. The answer to that is: we raised a fuckload of money and didn’t need more. We’ve been operating on the threshold of never needing more, if we stuck to our original plans, and if AI didn’t cause the ground to open up and swallow us all whole. But obviously, that’s no longer the game plan.

Ch-ch-changes

Look, I know how this is going to go over. I could write this post without pissing anybody off, but I don’t know how to do that and still have it be worth reading.

We’re making a very specific and probably polarizing bet on the future of the industry: that agents, within a few years, are going to determine how almost all software is built and shipped. That software is going to become much more personal, with smaller audiences, and much more flexible and slippery.

I’m excited about all of this. I’m a little taken aback that I get to work in this field during a shift like this. But I’d have to be oblivious not to see how uncomfortable that shift makes other professionals in the field.

By the middle of the year, we could have gone one of two ways:

• On the first path: keep investing our energy in exactly what we’ve been scaling out and refining, a platform for fixed-function full-stack applications designed by humans.
• On the second path: dial in and nail a product that fits an agent-driven near future of software.

Five of the most dangerous words in startups are “¿Por qué no los dos?”. We do one thing or the other. We don’t limp in on both. And if we fail, we fail with our full asses. Though, I guess only most of mine going forward.

It’s a hell of a thing, steering a team, a company, a base of customers at this stage in Fly.io’s life. We’d been putting off a big decision about priorities for several months. Theo, you picked up on that. Good note! I could have decided quicker, and more clearly; instead, I shipped Sprites. Sprites answer the question that’s been facing us. I’m glad I spent the time building them, and I’m glad we’ve recruited Scott to turn them into our core business.