图片作者：Annie Ruygt

我们是 Fly.io，一个公共云平台：它既是我们最喜欢的将应用部署到互联网的方式，也是我们最喜欢的、能安全地让前沿 Agent 编程工具链尽情运行的方式。这篇文章讲的是我们公司、未来，以及 Sprites——一种面向 Agent 的计算机，你现在就可以体验。

这是一篇复杂的文章。所以我需要你答应我一件事：如果你读过了这段引言，就请一直读到最后。这关乎荣誉。

几个月前，Theo Browne 发布了一段视频，评选“2026 年部署新应用的最佳地点”。Theo 通常会夸我们几句，这次也一样。但他最后的结论是：在他关注的所有服务商中，他最不确信我们能活到年底。

好吧，操。

Theo 的说法让我们吃了一惊，因为我们正处于连续多个强劲季度之中，其中包括公司历史上财务表现最好的几个月。但这番评价一直萦绕在我脑海里。它正好戳中了我的痛点：关于我们在做什么，以及公司要走向哪里。

坦白说，我本该预见到这一点。Fly.io 今年一直在高速前进，但我有些随波逐流，让公司陷入了一场悬而未决的身份危机。

我马上还会透露更多个人层面的事情，但不会让你一直猜下去。所以先说结论：我们又融了一大笔钱。我们将推出新版 Sprites，并让公司聚焦于它们及其解决的问题。而 Scott Johnston 将接任 CEO。

产品市场契合

我创办 Fly.io 时有两条明确的原则，现在它们可能已经没那么重要了。

第一条是：互联网应用在速度快时表现最佳，而这意味着它们要部署在离用户更近的地方。这是我在 Ars Technica 多年工作中学到的道理，我创办 Fly.io 的一部分原因就是想解决这个痛点。在公司最初几年的时间里，这一直是我们的信条。

第二条是：云基础设施太复杂。开发者需要兼具 AWS 灵活性和 Heroku 易用性的平台。我们创办 Fly.io 时，你无法同时获得这两者；现在，你可以在这里以及其他地方获得。

你读到这些会说：“废话，当然很重要。”但我要告诉你，它们没有你以为的那么重要，原因显而易见——也是如今唯一还有人在讨论的原因。AI 已经彻底改变了软件开发。野狗真的把我们的孩子叼走了。

过去 18 个月里，每次我说这句话，它都会变得更加真实。

我不认为人们已经完全意识到这一点。我们仍在试图将编程 Agent 整合进职业流程，仿佛它们只是足够聪明的编译器。但 AI 并不像交付 C 代码和交付 Ruby 代码之间的差别那么简单。它的影响大得多。

所有人都忘了，在 Dan Bricklin 发明电子表格之前，世界上的每一份“Excel 文档”都是一个计算机程序，由程序员构建。仅仅几年间，每一位商业人士都成了程序员，使用世界上最重要的编程语言——电子表格公式。AI 与此类似，但规模更大。几乎任何人都可能能够构建几乎任何类型的计算机程序。

现在再看看传统公共云基础设施。我们把遵循严格标准、在繁琐 CI/CD 流程上构建的固定功能应用，交付给数百万人的受众。但很快，拥有数百万受众的计算机程序，会像拥有百万读者的电子表格一样。它们确实存在！但不会是常态。

押注于 2020 年形成的、有明确偏好的公共云设计，就等于押注反对个性化、自适应软件。我不认为这是一个好赌注。即使我认为它是，我也不想这么赌。我希望生活在这样一个世界：我的朋友和家人可以让计算机精确完成他们想做的事，而不必等我为他们构建一切。

Agent 想要什么

这就引出了我们的第二条创始原则：严肃的云基础设施太难让开发者用好了。而且：这依然是真的！但它显然也不再那么重要。

事实上，拥有经过精心打磨、带有明确默认设置的人类开发者体验，现在可能反而更糟。Agent 在一切明确的环境中表现最佳。

粗略来说，如今已经没人读文档了。他们也不会再通过反复试错来学习新 CLI、弄明白如何使用它们。这正是 Agent 的用途。一个 Agent 可以一次完成 Fly.io 部署：只要先在本地构建网站，然后说“现在让它在 Fly.io 上跑起来”，它就会做得很好。但一个 Agent 也能一次完成 AWS 部署。那我们在做什么？这到底是怎么回事？

去年我在一篇文章中写过：我们增长最快的客户全都是机器人。之后，我不再试图事后解释我们已经构建的东西，转而开始弄清机器人客户真正想要什么。以下是我的结论。

第一件事：编程 Agent 预期自己运行在开发者工作站上。

第二件事：即使是在你信任的沙箱中，在物理开发笔记本上运行 Agent 也很烦人，因为你合上笔记本盖子时，笔记本就停止运行了。今年有没有人端着打开的 MacBook 上过或下过一层楼梯？请举手。你的手没举起来吗？我猜你的家里没有楼梯。因此，所有人最后都会在云端运行自己的 Agent 沙箱。

第三件事：公共云是运行 Agent 的一个烦人场所。我们把服务器分成“宠物”或“牲畜”，但对于 Agent 来说，即使是一头牛群中的牛也意味着太多承诺。你想要的，我不知道，可能是一头半一次性的牛：它恰好在你需要时出现，恰好存活到你希望的时间，不会花很多钱——这也正是类比难写的原因。

今年早些时候，我们团队完成了一项我认为是系统工程、乃至整个计算机科学领域的突破：我们推出了半一次性的牛。我们称它们为 Sprites。

Sprites 呈现出一种奇特的形态，因为我们是围绕机器人真正寻找的东西为它们量身定制的。你可以快速创建数百乃至数千个 Sprite，但它们全都拥有 100GB 的持久磁盘。与云中的所有服务一样，它们按计量使用收费；但当它们无事可做时，计费表不会继续走，而且它们能智能判断自己何时处于空闲状态。你还可以在其上托管应用，并通过互联网与同事分享。

这一组看似杂乱的功能，最终构成了一个关于 Agent 的主张。行业痴迷于沙箱。但机器人不想要沙箱。它们想要计算机。我们的半一次性牛就是这个：一台面向 Agent 的计算机。

你现在就可以创建一个 Sprite

大概只要一分钟 ✨

现在就去！→

面向 Agent 的计算机

我对 Sprites 的发布过程感到满意。但坦白说，Sprites 原本是一个秘密研发项目。我们甚至没有把它们放在 Fly.io 主站上！这是一个奇怪的决定。我不打算为此找理由。我们当时正处于身份危机中。但如今迷雾已经散去，“面向 Agent 的计算机”将成为我们公司未来的重心。

（要感受这一点有多真实：对整个代码库执行一次 git blame，显示我的名字的次数比任何人都多。）

Fly Machines 和我们的 Platform As A Service 功能不会消失。但 Sprites 原本只是 Fly.io 内部一个极小型骨干团队的产品，现在不再是了。

通常，我们会花数千字深入介绍每一个新产品背后的技术构建过程。对于 Sprites，我们也会这么做。但我已经在这篇文章里写得很深了，还有其他内容要分享。所以现在，我会保持简短。

除了我们在扩展和编排方面完成的幕后工作外，新版 Sprites 还引入了两个大型子系统，让我们终于达到我愿意称为“功能完整”的状态，符合我们想要实现的目标。

第一个是 Sprite Block Device（SBD）。原始 Sprites 的存储栈是一个妖精般拼凑出来的装置，由我个人基于 JuiceFS 设计，并使用 Ben Johnson 的 Litestream 接入我们的系统。你应该很高兴听到，Ben 和 Tim Newsham 已经将整套栈彻底拆除并重建。它更快、更可靠，同时依旧支持即时检查点与恢复。

更重要的是，SBD 支持磁盘分叉：你可以创建一个模板 Sprite，然后高效地克隆数百万次。

Sprites 的另一项重大新功能是 Connectors。Connectors 建立在我们为保护核心平台所做的工作之上：它们让 Sprites 能够向其他系统发出经过认证的请求，同时不向 Agent 提供任何有价值、可被窃取的数据。Connectors 具备有趣的安全特性，也比手动管理账户和 API 密钥愉快得多。

这些是用户需求最强烈的功能。它们也是为什么在我们专门为 Agent 公司推出产品数月后，许多 Agent 公司仍然在使用 Fly Machines。因此我有足够信心下注：除非出现某种新的外星科技，对计算机科学造成比 Transformer 模型更离奇的影响，否则 Sprites 将非常适合我们未来的客户，以及我们现有客户中非常大的一部分。这就引出了：

Fancy Sprite Beta

你想要一个能自我克隆的奇特 Beta Sprite？我可以先给你一点尝尝。✨

报名参加 Beta →

我辞职了

这件事酝酿了一段时间，但对于 Fly.io 当前所处的阶段，我认为由我担任 CEO 所能带来的大部分价值已经被发挥出来了。所以我将不再继续做这件事。

在一家创业公司的最初几年，你是在运行一个科学项目：一场由实验驱动、寻找产品市场契合的探索。正如任何曾在这里工作过的人都能证明的那样，我们尝试过几十种东西，从非托管 Postgres（千万别这么做），到全球 CDN，再到用户态 WireGuard。在公司更深的组织结构中，我们建立了自下而上的工程组织，避免制定产品路线图，并招募了一支全远程团队，成员来自十多个国家。

一些实验取得了回报，另一些则是 学习机会。在过去 8 年里，运行这些实验就是我的全部生活。但 Fly.io 已经不再需要这类科学项目了。

过去数月里，实际上可以一直追溯到 2025 年，我一直在和 Scott Johnston 讨论：如果由他来掌舵，Fly.io 会是什么样子。Scott 曾任 Docker CEO，并带领 Docker 度过了一段极具挑战性的时期——始于 Docker 自身在企业客户与开发者之间的身份危机，终于他们将业务彻底做大。作为 Fly.io 的股东，在 Fly.io 生命周期的这个阶段，我更喜欢他的打法，而不是我的。作为 Fly.io 的 CEO，比起由我来做这些工作，我更喜欢由他来做。我们花了很长时间推敲这件事，最终，董事会和我说服他接受这份工作。

在这类文章中，这一段通常应该由我来解释：为什么 Scott 完美适合 Fly.io，并回顾他过去所有的冒险经历。他确实适合，那些经历也确实非凡。但你已经知道我会怎么说了，这就变得无聊；而且 Scott 想自我介绍时完全可以自己来。他并不害羞。

与此同时，我会做所有精明、疲惫的创始人 CEO 会做的事：转任顾问角色，随机空降到产品设计讨论中——这是我工作中有趣的部分；同时利用我的董事会席位，在 Scott 执行那些对我而言无趣的工作、且做得比我更好时，去烦他。

我相信 Scott 会详细解释我们刚刚完成的融资。这也是 Theo Browne 在视频中提到的另一件事——我没生气，我听起来像生气了吗？——那就是我们已经好几年没有宣布融资了。对此的答案是：我们融了他妈的一大笔钱，而且不需要更多。只要坚持原先的计划，并且 AI 没有让大地裂开、把我们所有人整个吞掉，我们一直都处在一个几乎 永远 不需要再次融资的临界点上。但显然，这已不再是我们的计划。

Ch-ch-changes

听着，我知道这篇文章会引发什么反应。我可以写一篇不惹任何人生气的文章，但我不知道怎么做到这一点，同时又让它值得一读。

我们正在对行业未来做一个非常明确、也很可能两极分化的押注：在几年之内，Agent 将决定几乎所有软件如何被构建和交付。这些软件将变得更个人化，面向更小的受众，并且更加灵活、更难以固定定义。

我对此感到兴奋。在如此巨大的变革期间，我居然能在这个领域工作，这让我有一点受宠若惊。但如果我没有看到这种变化令业内其他专业人士感到多么不安，那我就太迟钝了。

到今年年中，我们本可以走两条路中的一条：

• 第一条路：继续将精力投入到我们一直在扩展和打磨的方向——一个面向人类设计的固定功能全栈应用的平台。
• 第二条路：聚焦并打造一个契合 Agent 驱动的软件近未来的产品。

创业公司中最危险的五个词是：“为什么不两者兼顾？”我们只做一件事 o

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. 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:

Fancy Sprite Beta

You want a weird beta Sprite that can clone itself? I can get you a toe. ✨

Sign up for the beta →

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.