Fly.io 首席执行官 Kurt Mackey 即将卸任，公司转向 AI 智能体平台 Sprites

嗨，是我们，Fly.io。我们和任何人一样讨厌这些东西，但市场营销之神要求转化指标。

我们是 Fly.io，一个公共云平台，它既是我们在互联网上部署应用程序的最喜欢方式，也是我们安全地让前沿代理编程资源工作的最喜欢方式。这是一篇关于我们公司、未来，以及 Sprites 的文章，Sprites 是面向代理的计算机，你现在就可以查看： https://fly.io/sprites

这是一篇复杂的文章。所以我需要你答应我一件事：如果你读过了这个介绍段落，你将会读完剩下的全部内容。这是一种荣誉的事情。

几个月前，Theo Browne 制作了一段视频，对“2026 年托管新应用程序的最佳地点”进行了评分：https://www.youtube.com/watch?v=yfxDdQo2cyI。Theo 倾向于说我们好话。这次他也这样做了。但随后他总结说，在所有他关注的提供商中，我们是他最不确定能坚持到年终的。

Theo 让我们吃惊，因为我们正处于一系列强劲季度中，其中包括公司历史上最好的财务月份。但这个观点一直在我脑海中回响。它直接触动了我的敏感神经，让我思考我们正在做的事情以及公司未来的方向。

老实说，我本应预见到这一点。Fly.io 今年一直在高速发展，但我有点放松，让公司在未解决的身份危机中继续热闹。

我接下来会再分享到更多内容，但不会让你处于悬念中。所以：我们又筹集了一大笔资金。我们正在推出 Sprites 的新版本，并将公司聚焦于它们及它们解决的问题。同时，我将 Scott Johnston 任命为 CEO。

我创立 Fly.io 时遵循了两个明确的原则，而这两个原则现在可能已经不再重要。

第一个是互联网应用程序在快速运行时效果最佳，而这发生在它们部署得离用户很近的时候：https://news.ycombinator.com/item?id=22616857。我在 Ars Technica 工作的多年中学到了这一点，并部分因为这个原因创立了 Fly.io。这也是公司前几年一直奉行的口号。

第二个问题是云基础设施太复杂。开发者需要既具备 AWS 弹性又具备 Heroku 人机工程学的平台。当我们创办 Fly.io 时，你不可能同时拥有这两个特点，而现在你可以，在这里和其他地方都可以。

你读到这里可能会说，“废话，当然这些东西很重要。”但是我要告诉你，它们并没有你想象的那么重要，原因很明显——这是现在人们谈论的唯一原因。人工智能已经彻底改变了软件开发。野狗真的吃了我们的孩子。

† 在过去的 18 个月里，每次我说出这些话，它们都变得更加真实。

我觉得人们还没有完全意识到[†]。我们仍在尝试将编码代理整合到我们的职业中，就像它们是足够聪明的编译器一样。但人工智能并不只是像从 C 语言发布到 Ruby 的差异那么简单。它要大得多。

每个人都忘了，在 Dan Bricklin 发明电子表格之前，世界上的每一个“Excel 文档”都是由程序员制作的计算机程序。短短几年时间，每个商业专业人士都成为了程序员，使用世界上最重要的编程语言——电子表格公式。人工智能就是这样，但影响更大。几乎任何人可能都能构建几乎任何类型的计算机程序。

现在考虑传统的公共云基础设施。我们将按照严格标准、在挑剔的 CI/CD 流水线上构建的固定功能应用程序，分发给数百万用户：https://fly.io/blog/the-5-hour-content-delivery-network/。但是拥有数百万观众的计算机程序，很快就会像拥有百万读者的电子表格一样。它们存在！但它们不是常态。

押注 2020 年的有见解的公共云设计，就等于押注个性化、适应性软件的失败：https://sockpuppet.org/blog/2026/05/12/emacsification/。我认为这不是一个好赌注。即便我认为是，我也不想去做。我想要一个世界，我的朋友和家人可以让计算机完全按他们的想法工作，而不用等待我为他们构建一切。

这把我们带到了我们的第二个创始原则，那就是：对于开发者来说，严肃的云基础设施太难以使用得很好。而这仍然是真的！但这一点现在显然已经不重要了。

† 事实上，现在拥有一个精心策划、带有明确默认设置的人类开发者体验可能反而更差。智能代理在一切都明确时表现最佳。

初步来看，现在几乎没有人再看文档了。他们也不会通过反复试验来学习新的命令行工具并掌握使用方法[†]。这正是智能代理的用途。一个代理可以一次性完成 Fly.io 部署：只需在本地构建一个网站，然后说“现在让它在 Fly.io 上运行”，它就会运行得很好。但一个代理也可以一次性完成 AWS 部署。我们在做什么呢？到底发生了什么？

我去年写过这方面的文章，讲的是我们增长最快的客户全是机器人：https://fly.io/blog/fuckin-robots/。然后我停止了对我们已经构建内容的事后调整，开始研究机器人客户真正想要什么。这就是我得出的结论。

事情一：编程代理期望运行在开发者工作站上。

事情二：即使在一个你信任的沙箱环境中，在你的物理开发笔记本上运行代理也很麻烦，因为当你合上笔记本时，它就停止运行。今年你是否曾经开着 MacBook 上下楼梯？举手。如果手没举，那我猜你家里没有楼梯。所以大家最终都会在云端运行他们的代理沙箱。

事情三：公共云是运行代理的麻烦地方。我们把服务器分为“宠物”或“牲畜”，但对于代理来说，即使是一头普通的牛也是过度承诺。你需要，我不知道，一头半可抛弃的牛，一头在你需要的时候出现、在你想要的时间停留、而且成本很低的牛——这就是为什么类比很难写。

今年早些时候，我们团队取得了我认为是系统工程乃至整个计算机科学的突破：我们推出了半可抛弃的牛。我们称它们为 Sprites：https://fly.io/blog/design-and-implementation/。

Sprites 形成一种奇特的形状，这是因为它们被缩小后包裹在我认为机器人正在寻找的东西周围。你可以快速创建数百甚至数千个它们，但它们都有 100GB 的耐用硬盘。像云中的一切一样，它们有计量的使用费，但当它们什么也不做时，计量表不会运作，而且它们很聪明，能判断自己何时处于空闲状态。你还可以在它们上面托管一个应用，并通过互联网与同事共享。

这一系列功能加在一起，展示了关于代理（agents）的一个理念。行业对沙箱（sandboxes）非常痴迷。但机器人不想要沙箱。它们想要的是计算机。这就是我们的半一次性奶牛：一个为代理准备的计算机。

大概需要一分钟✨

我对 Sprites 的发布过程感到满意。但老实说，Sprites 是一个秘密工程项目。我们甚至没有在主 Fly.io 网站上托管它们！这是一个奇怪的举动。我不是在为此找理由。我们当时处于身份危机。但乌云已经散开，面向代理的计算机（Computers for Agents）将成为我们公司未来的重点。

†（想感受下这有多真实：对整个代码库进行 git blame 会显示我的名字出现次数比其他任何人都多）

Fly Machines 和我们的平台即服务（PaaS）功能不会消失。但 Sprites 曾是 Fly.io 内部一个小骨干团队†的产物，现在已经不是了。

通常，我们会用数千字深入探讨我们如何构建任何新产品。Sprites 也会这样。但我在本文中已经很深入了，而且还有其他东西要分享。所以现在，我会保持简短。

除了我们在扩展和编排方面所做的幕后工作外，nu-Sprites 还引入了两个大型子系统，使我们最终达到了我可以认为“功能完备”的地步，符合我们试图实现的目标。

第一个是 Sprite 块设备（SBD）。原始的 Sprites 存储栈是一个我个人从 JuiceFS 衍生出来的奇怪装置，并使用 Ben Johnson 的 Litestream（https://litestream.io/）接入我们的系统。你应该会高兴地听到，Ben 和 Tim Newsham 把整个栈拆到骨架，然后重建。它更快、更可靠，而且仍然可以实现即时检查点和恢复。

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

Sprites 的另一个重要新功能是连接器（Connectors）。连接器建立在我们为保障核心平台安全所做的工作基础上：https://fly.io/blog/tokenized-tokens/：它们允许 Sprites 向其他系统发出经过身份验证的请求，同时不向代理提供任何可用于外泄的信息。连接器具有有趣的安全属性，但使用起来比手动管理账户和 API 密钥要舒适得多。

这些是我们最受欢迎的功能。这也是为什么许多代理公司在我们专门为他们推出产品的几个月后，仍然在使用 Fly Machines 的原因。因此，我有足够的信心下注：除非有某种新的外星科技出现，其对计算机科学的影响甚至比 Transformer 模型更奇怪，否则 Sprites 是我们未来客户的合适选择，也适合我们现有的大量客户。这就引出了：

你想要一个能自我克隆的奇怪测试版 Sprite 吗？我可以给你一个小脚趾。✨

这事已经等待了一段时间，但对于 Fly.io 目前的阶段，我认为它已经从我作为 CEO 的经历中提取了大部分有价值的东西。所以我打算不再继续这样做。

在创业公司的最初几年，你在运行的是一个科学项目，一个以实验为驱动的产品市场契合探索。任何在这里工作过的人都可以证明，我们尝试了几十种方法，从未管理的 Postgres（千万别这样）到全球 CDN：https://fly.io/blog/the-5-hour-content-delivery-network/ 以及用户模式 WireGuard：https://fly.io/blog/our-user-mode-wireguard-year/。深入公司内部，我们建立了自下而上的工程组织，避开了产品路线图，并招募了一个全远程团队，其成员分布在十几个国家。

有些实验取得了成果，另一些则是学习的机会。过去八年来，运行这些实验一直是我的全部生活。但 Fly.io 已经不再需要这些科学项目了。

在过去的几个月里，甚至可以追溯到 2025 年，我一直在与 Scott Johnston 讨论，如果由他来制定策略，Fly.io 会是什么样子。Scott 曾是 Docker 的 CEO，并在 Docker 面临企业与开发者身份危机的挑战时期带领公司走过难关，最终让公司业务蓬勃发展。作为 Fly.io 的股东，在 Fly.io 生命周期的这个阶段，我更喜欢他的策略而不是我的。作为 Fly.io 的 CEO，我更期待他来完成这些工作，而不是我亲自去做。我们花了很多时间来商讨这个问题，最终董事会和我说服了他接受这个职位。

在这种文章的这一段，我通常应该告诉你为什么 Scott 是 Fly.io 的完美人选，并回顾他过去的所有经历。而事实的确如此，他的经历也非常辉煌。但你们已经知道我要说什么，这让内容显得枯燥，而 Scott 想介绍自己时完全可以自己介绍，他可不害羞。

同时，我会像所有聪明的曾创业 CEO 一样，转到顾问角色，偶尔随机参与产品设计讨论（我工作中最有趣的部分），同时利用我的董事会席位在 Scott 执行那些（对我来说）不那么有趣的工作时小小捣乱，而他做得比我能做的更好。

我确定 Scott 会详细分析我们刚完成的融资。这也是 Theo Browne 在他的视频中提到的一点（我不生气，对吧？我听起来像生气吗？）——我们好几年没有宣布过融资。答案是：我们筹集了大量资金，并且不需要更多。如果我们坚持原来的计划，并且人工智能没有导致地面裂开吞没我们，我们一直在几乎不需要额外资金的边缘运作。但显然，这已经不再是我们的计划。

听着，我知道这会引起怎样的反应。我本可以写这篇文章而不惹任何人生气，但我不知道如何做到这一点，同时又能让文章值得一读。

我们正在对行业的未来做一个非常具体且可能具有争议的赌注：在未来几年内，代理将决定几乎所有软件的构建和发布方式。软件将变得更加个人化，面向更小的受众，并且更加灵活和多变。

对于这一切，我感到非常兴奋。我有点吃惊自己能够在这样一个转变时期从事这个领域的工作。但如果我对其他专业人士在这一转变中感到不适视而不见，那我就是在装聋作哑。

到今年年中，我们可能会走两条路中的一条：

创业公司中最危险的五个词是“¿Por qué no los dos?”（为什么不两者都做？）。我们做一件事或另一件事。我们不会两者都做。如果失败了，我们会全情投入地失败。虽然我猜从今以后，只是大部分投入会是我的。

在 Fly.io 的这个阶段，管理一个团队、一家公司，以及客户群是一件非常困难的事情。我们已经拖延了几个月才对优先事项做出重大决定。Theo，你注意到了这一点。好观察！我本可以更快、更明确地做出决定；相反，我推出了 Sprites。Sprites 回答了困扰我们的问题。我很高兴花时间去构建它们，也很高兴我们招募了 Scott 将它们转变为我们的核心业务。

Hi, it's us, Fly.io. We hate these things as much as anyone, but the marketing gods demand conversion metrics.

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.：https://fly.io/sprites

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”：https://www.youtube.com/watch?v=yfxDdQo2cyI. 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.

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.

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：https://news.ycombinator.com/item?id=22616857. 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：https://fly.io/blog/the-5-hour-content-delivery-network/. 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：https://sockpuppet.org/blog/2026/05/12/emacsification/. 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.

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：https://fly.io/blog/fuckin-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：https://fly.io/blog/design-and-implementation/.

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.

It’ll take, like, a minute &nbsp✨

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：https://litestream.io/. 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：https://fly.io/blog/tokenized-tokens/: 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:

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

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：https://fly.io/blog/the-5-hour-content-delivery-network/ to user-mode WireGuard：https://fly.io/blog/our-user-mode-wireguard-year/. 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.

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:

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.