Cloudflare is a kit of parts

Workers is the only platform in this series that was actually designed for small software. It has every piece the job needs. It just expects an engineer to assemble them, and it never stops expecting that.

Second post in a series where we count what it costs to get agent-built software running on the platforms that exist today. The first one was about Google Cloud Run, a machine built for organisations: a very good runtime whose real price is everything you have to already know to reach it. Cloudflare Workers has the opposite temperament. It was built for exactly the category we care about, software that is small, cheap to run, and everywhere at once. The path in is the shortest we'll cover and the config is a file next to the code.

So this should be the happy post. It isn't quite, and the reason is worth being precise about. On Cloudflare, everything is possible and everything is a programming project. You don't deploy software to Workers so much as develop software for Workers, and the difference between those two sentences is the whole post.

The accounting is the same as last time: what it costs to start the machine, then what it costs to keep it running, counted from nothing. And a disclosure before we start: the site you're reading is a Worker, deployed through Wrangler and the OpenNext adapter. We picked it, we pay for it, and we like it. That's also why we know where it pinches.

What Workers actually is

A Worker is JavaScript, WebAssembly, or Python (still beta) running in a V8 isolate on workerd, Cloudflare's open source runtime, replicated across a network that carries a meaningful share of the internet's traffic. This is a company that builds serious low-level software, and the isolate explains most of how the platform feels: isolates start in milliseconds and cost almost nothing while they sit idle, and that's what lets Cloudflare keep your code in hundreds of locations at once. The economics fit small software exactly. Idle programs cost approximately nothing, per-request pricing rounds to zero for things that run occasionally, and the free plan carries real traffic without a credit card.

The tooling around the runtime is machined to the same standard. The configuration is a file next to the code: wrangler.jsonc holds the worker's name, its bindings, and its schedule. A KV namespace, a D1 database, an R2 bucket, a queue, a cron trigger, all of them fields in one document that wrangler deploy reads and makes true. An agent can read the whole file and edit any part of it. Of everything in this series, this is the closest to what we're building.

And the local loop is genuinely good. wrangler dev runs your code in the real workerd runtime on your machine, not a simulation of it, with local emulation of the bindings: a local KV, a local D1, a local R2. Change a file and it reloads in about a second. For a developer, and for an agent sitting in a terminal, that's the right shape: a fast loop with real semantics, no cloud round-trip to find out whether the code works. Most platforms in this series can't offer anything like it.

The cost to start it

Here's the path from Cloudflare's own get-started guide, counted from nothing. No account, no CLI, no project on disk.

1. Create a Cloudflare account (handoff)
2. Install Node and the Wrangler CLI
3. Answer the scaffold prompts from npm create cloudflare (handoff)
4. Run wrangler login, which opens a browser (handoff)
5. Deploy, claiming your workers.dev subdomain on the way

Five steps and three handoffs, one of them soft, since an agent with a terminal can answer scaffold prompts itself. There's no billing form, which removes the handoff that stings most on the big clouds. And unlike Cloud Run, the path needs almost no hidden knowledge. There are no APIs to enable, no registry URL to assemble, no region to guess. This is the cheapest start in the series, and we'll say so plainly.

Which sharpens the question. If the start is this cheap and the config is a file, where did the cost go?

The cost to keep it running

It went into the runtime, and it lands on the smallest software hardest, in ways that aren't obvious until they've cost you an afternoon. Call it the paradox of this platform: small is complex here.

A Worker is not a container, and the constraints are the same thing as the speed: you cannot have millisecond starts in hundreds of locations and also have a Linux box. So there's no filesystem, no processes, no listening sockets, no binaries. CPU time is metered and capped per request. Node compatibility comes from a flag called nodejs_compat that covers a growing subset of Node rather than Node, and the failure mode is quiet: set the wrong compatibility date and imports don't error, they just come back empty at runtime.

The ordinary output of an agent isn't shaped for any of this. An Express server won't run here as written, and neither will a Python script that imports pandas, or a binary that reads a file and exits. That isn't our lab result, it's years of public record: the community's long-running threads about deploying Node apps to Workers get answered with migration guides rather than deploy guides. Enable the flag, audit every middleware for filesystem assumptions, replace bcrypt and sharp with WASM alternatives, move session state somewhere else. Whole adapter ecosystems exist to do this translation for entire frameworks, and this site is one of the examples: it needs OpenNext, two compatibility flags, and a hand-written worker wrapped around the generated one just to serve what is otherwise a plain Next.js app.

State is where the kit shows most clearly. On a machine, state is a disk and a database. Here it's a catalogue: KV for eventually consistent lookups, D1 for relational data, R2 for objects, Durable Objects for coordination, Queues for delivery, each with its own consistency story and its own limits page. It's a good catalogue, assembled by people who understand distributed systems deeply. Choosing correctly from it is also a distributed-systems design exercise, which is homework a script with a SQLite file never asked for. The platform that's cheapest to enter is the one where the smallest program has to make the most decisions.

Containers, explained properly

The obvious question is whether Containers fix this, since Cloudflare now ships them next to Workers, generally available since 2026, with real Linux filesystems, native binaries, and Docker images. The design is worth explaining, because it's clever in a way that tells you exactly what the platform is.

A Cloudflare container is not a freestanding thing you deploy. It's an appendage of a Durable Object. You write a TypeScript class extending Container, you point wrangler.jsonc at a Dockerfile, and wrangler deploy builds the image and pushes it to Cloudflare's registry. Each instance of your class is addressed by an ID and owns one container instance: the class decides when it starts, what runs in it, and when it sleeps. The container's own disk is ephemeral, so anything worth keeping goes into the Durable Object's persistent storage. Since mid-2026 the class can exec() processes inside the running container and read back exit codes and output. And nothing reaches a container except through a Worker, which decides which instance ID to talk to.

Is that good? For what it was designed for, honestly, yes. If you're building a product that needs a thousand isolated sandboxes, one per user or one per AI session, each addressable by ID with its own lifecycle and its own state, this is a beautiful primitive, and it's no accident that running untrusted agent-generated code is its flagship use case. Programmable infrastructure, containers as objects in your program: that's a genuinely new idea done well.

But look at it from the other side, as a place to run a script. To execute one Python file and learn whether it worked, you write the TypeScript class, manage the lifecycle by hand, exec() the process, write the exit code into the Durable Object's storage, and put a Worker in front to route to the right instance. The API is well made and the result is still a job runner you built yourself, in Cloudflare-dialect TypeScript that runs nowhere else, with your portable script sitting inside it. Containers answer the question "how would a Workers engineer add Linux to the kit". They don't answer "how do I run my software here". And they need the paid plan, which means the free tier we praised covers exactly the software with the longest rewrite distance, and the moment you need Linux the card comes out anyway.

Our own count, honestly

Shed from nothing is five steps and two handoffs, both of the irreducible kind, so on start cost Workers and Shed are within a step of each other and nobody should choose a platform over that.

The difference is what each one accepts. Cloudflare takes software written for Cloudflare, and rewards it richly: a new thing, built in their shape by someone who enjoys the engineering, gets a superb runtime and the best local loop in the business. Shed takes software as it already exists, because that's what agents produce: a container, described by one file, deployed with one command. That unit is the same whether the thing is a service, a job or a cron, with the exit code and the logs kept for you. No harness, no dialect, no catalogue exam before the first deploy.

The platform that proves the point

Workers is the strongest evidence anyone has produced that small software deserves its own cloud. The economics work, the tooling is real, and Cloudflare proved the category years before agents made it urgent.

But it built that cloud for engineers, in the years when engineers were the only ones writing software, and every assumption from that era is load-bearing: that the person deploying will happily learn the runtime, pick the right state primitive, and write the harness. Agents break that assumption. They write ordinary software in enormous volume, whatever their training data taught them, and they need it running before the session ends. A platform that answers "first, rewrite it for us" loses the session to translation, no matter how short the path in was.

The pieces are all there, and they're excellent. What's missing is the machine around them, and that's the bet we're making.

Next in the series: Vercel is a workflow.