Fly.io is a fleet

Fly.io is CLI-first, and that is the closest anyone in this series comes to the right primitive. CLI-first is not the same as agent-first. Fly has built an excellent computer for an agent to work on. What it hands back is still a fleet you operate.

Last post in a series where we count what it costs to get agent-built software running on the platforms that exist today. So far: Google Cloud Run, a machine built for organisations; Cloudflare Workers, a kit of parts built for engineers; Vercel, a workflow that starts from a repository; and Railway, a canvas for systems you tend. Fly.io is the other platform that hands you a container and a dashboard, and it is the one that has thought hardest about agents. It is also the one whose design centre is furthest from where it points.

We should start by correcting ourselves. Three posts in this series have said that no platform here gives you a one-off job — run this once, tell me the exit code, keep the logs. Fly does. fly machine run <image> <command> --rm runs a command in a machine and removes it when it exits, and --schedule takes hourly, daily, weekly and monthly. We were wrong to keep saying nobody had it, and the honest position is that Fly got there first.

What Fly.io actually is

The unit is a Machine: a Firecracker microVM you place in a region, running an image you built or one they built for you. An app is a set of those machines behind Fly Proxy, described by a fly.toml next to the code. Around it sit volumes, private networking, Postgres, and a global anycast edge that is genuinely theirs rather than resold.

fly launch is the front door and it is good. It scans the source, recognises the framework — Django, Rails, Laravel, Phoenix and the rest — writes the fly.toml, and shows you what it intends to do before it does it: organisation, app name, region chosen by latency, machine size, and whether you want Postgres or Redis alongside. Then it asks whether you want to tweak any of it. fly launch --no-deploy stops before shipping. It is the most considerate first-run experience in this comparison, and unlike Vercel it does not need a repository to work from.

Idle costs almost nothing, and this is the part most relevant to small software. New apps come out of fly launch with auto_stop_machines = "stop", auto_start_machines = true, and min_machines_running = 0. Fly Proxy stops machines when there is no traffic and starts them when a request arrives, and stopped machines are not billed for CPU or RAM. A shared-cpu-1x with 256MB starts at about $2.02 a month if it never sleeps, and less if it does. For software that runs twice a week, those are the right economics, and Fly built them years before most of this industry noticed the category.

The cost to start it

Counted from nothing, following Fly's own documentation. No account, no CLI, no app.

1. Create an account (handoff)
2. Install flyctl with curl -L https://fly.io/install.sh | sh
3. Run fly auth login, which opens a browser (handoff)
4. Add a credit card (handoff)
5. Run fly launch and answer the prompts (handoff)
6. Run fly deploy

Four handoffs, and they are not all the same kind. Account and login are the two everybody pays, including us. The launch prompts are soft in the way Railway's are: flags answer them, and an agent with a terminal can answer its own questions.

The card does not move either. Fly's pricing page is unambiguous: all organizations except linked ones require a credit card on file. It is a sensible anti-abuse decision from a company that rents real compute to strangers, and we ask for one too, for the same reason.

So the honest count is three: account, card, login. We ask for a card as well, as part of signing up. On setup cost there is not much between us, and there was never going to be.

The cost to keep it running

The fly.toml is the best configuration file in this comparison. It sits next to the code, it is small, it describes the build and the service and the autostop behaviour in one place, and fly launch writes a working one for you. If you asked us to name the file this series is arguing for, it looks a lot like fly.toml.

What surrounds it is a fleet. Machines are placed, scaled, and moved between regions; an app is a set of them and you are the one holding the picture. fly scale count, fly scale vm, regions to choose, volumes pinned to the machines that mount them. This is real operational surface, and it is the price of Fly being a genuine cloud rather than a place to drop a container. For a system that serves traffic in five regions, that surface is the product. For a script an agent wrote on Tuesday, it is a fleet of one that you now own.

The dashboard is where the fleet lives, and like Railway the deploy hands you a URL for your app on .fly.dev rather than a dashboard link, which is better than Railway's behaviour and worth saying plainly. Fly's deploy finishes the job.

The agent story, taken seriously

Fly has done more here than anyone in this series, including Railway, and their marketing says so directly: the homepage sells computers for agents.

There is an MCP server built into the CLI. fly mcp server --claude wires it into Claude Code, and --cursor, --vscode, --windsurf, --zed and --neovim do the same for the rest; it covers apps, certs, logs, machines, orgs, platform, secrets, status and volumes. There are Sprites: Firecracker microVMs with their own kernel, where Claude Code, Gemini and Codex come preinstalled, that sleep when idle and wake in under a second, and that ship machine-readable documentation at a known path so an agent can learn the environment without being told. Code an agent runs in a Sprite cannot reach the agent's host, your secrets, or your network.

That is excellent work and some of it is exactly right. It is also the clearest illustration of a distinction worth naming: CLI-first is not agent-first.

Fly is properly CLI-first. flyctl is the product, the dashboard trails it, and a terminal can drive the whole platform — which is more than most of this series can say, and it is why Fly is the closest thing here to the primitive we think is correct. But a CLI is a way in, not a design centre. Everything Fly has built for agents assumes the platform is the given and the agent is the new operator: the MCP server exposes Fly's existing surface, and the Sprite is somewhere an agent works. Neither changes the unit. An agent that finishes its work still has to make an app, place its machines, and hold the fleet, exactly as a person would. The machine-readable docs at a known path is the same instinct as our agent skill. The sub-second wake from sleep is the economics small software needs. The isolation model is stronger than ours: a Firecracker microVM has its own kernel, and our sandbox is gVisor on a tenant-only node pool, which is a different and lighter boundary. We are not going to pretend otherwise.

But look at what all of it is for. The MCP server lets an agent operate Fly. The Sprite is a computer for the agent to work in — a development environment with a lifecycle you manage, not the place the finished thing lands. Fly has built, very well, the machine an agent works on. The question this series asks is what happens to the software the agent produces, and for that the answer is still: make it an app, place its machines, hold the fleet.

Our own count, honestly

Three against two, and that gap is not interesting enough to build an argument on. Fine. The count was always a proxy for something else.

On almost everything else Fly is ahead of us today. It has the one-off job and the scheduled run; we do not, and this is the fourth post in which we have had to say so. Its isolation boundary is stronger. Its edge is real and global and ours is one region. Its fly.toml is a better-developed version of the file we are arguing for. We would rather write all of that down than be caught being quiet about it.

What we think is different is the unit and what it costs to have one. A Fly app is a fleet: named, placed, scaled, and yours to hold. A Shed is one piece of software and the file next to it that says how to run it, and shed deploy returns an address without asking you to name a project, choose a region, size a machine, or decide about Postgres. When an agent produces forty of these in a quarter, the difference between a unit you operate and a unit you forget is the whole thing.

The other difference is where we are going, and it is fair to state it as intent rather than fact: we want the access question answered the way a document answers it. Deploy something and it is private until you name someone, and then they can open it and nobody else can. Fly gives you an app on the public internet and the tools to put authentication in front of it. That is the normal answer. We think the normal answer is why so much small software never leaves a laptop.

The closest thing to us, aimed at the other half

Fly saw the category early, built the economics for it, and took agents seriously before it was obvious. On the primitive — a CLI that can drive everything, a small file beside the code, machines that sleep — they are closer to us than anyone else here, and we would rather be measured against them than against a dashboard.

The split is clean enough to state in a sentence. Fly built the best place for an agent to work. We are building a place for what the agent made to live.

That is the end of the series. Six platforms, one count, and the number that matters least is the count itself: everybody lands within a handoff or two of everybody else, and it was never really about the setup. It was about what you are holding afterwards.