24 APIs on Workers, $5 a Month, and the 10ms Wall

A developer put 24 APIs live on Cloudflare Workers and reported the bill: about $5 a month. Total. For all of them.

We’ve had clients pay $2,500 a month for Apigee and $300 a month for Azure API Management to do less. So the number is worth taking seriously, and the write-up is honest about where it stops being magic. The $5 is real. So is the 10ms wall that catches integration workloads first. Both belong in the same conversation, and vendor demos only ever show you one of them.

The cost number is not a trick

Start with why the economics work. Workers run at the edge, close to callers, and Cloudflare prices them per request at a rate that rounds to pennies for anything short of huge volume. Twenty-four proxying APIs generating modest traffic genuinely lands around $5 a month.

The bigger lever in the report is edge caching, which cut upstream calls by more than 70%. That’s a cost story and an operational one. Every request the edge answers is a request that never reaches your origin: less load on the system you’re actually protecting, lower latency for the caller, fewer failures to handle because the origin was never involved. For a proxy or gateway layer in front of a rate-limited or fragile backend, that 70% is the difference between a calm origin and a stressed one.

When we compare this against enterprise API management on real workloads, the gap runs from 50x to 500x on cost. That’s not a rounding difference. It’s a different category of spend, and for a lot of gateway and proxy use cases the expensive option buys you very little the cheap one doesn’t.

The wall the demo skips

Now the part nobody puts on a slide. Workers cap CPU time per request. On the free tier it’s about 10 milliseconds of actual compute. That’s CPU cycles burned, not wall-clock time or network wait.

For a proxy that validates a token, checks a cache, and forwards a request, 10ms is enormous. You’ll never come close. That’s why the happy-path demo looks so good.

Integration workloads are not that. The write-up names the exact operations that blow the budget: base64 encoding of anything sizable, complex regular expressions, and large JSON transforms. Those three are the daily bread of integration work. Reshaping a payload from a partner’s schema to yours is a large JSON transform. Parsing a legacy format is often a pile of regex. Encoding a binary attachment is base64. The moment your Worker does real integration instead of pure proxying, the 10ms ceiling stops being theoretical.

This is the gotcha that turns a $5 proof-of-concept into a production incident. The team builds the proxy, it flies, they add “just a little” transformation because the data needed reshaping, and now a subset of requests (the big payloads, the ones that only show up with real customer data) start failing on CPU limit. The failure is data-dependent, so it passes every test with small fixtures and breaks in production with the one 4MB response nobody tested.

Designing for the ceiling instead of into it

The wall isn’t a reason to avoid Workers. It’s a reason to be deliberate about what runs there. The pattern that works is a split.

Keep the Worker doing what the edge is good at: routing, auth, rate limiting, caching, cheap validation. Push the expensive work (the heavy transform, the big-payload encoding) to a backend that has real CPU and no per-request ceiling. The Worker stays inside its budget because it never does the costly thing; it hands the costly thing to somewhere built for it. You keep the $5 edge and you stop pretending the edge is a general-purpose compute layer.

Two operational habits make this hold up. First, validate input hard at the edge, before anything expensive happens. Reject the malformed request while it’s still cheap, so you never spend CPU on garbage. Second, watch for the CPU-limit errors specifically. They’re a distinct failure mode, and if you only track HTTP 5xx counts you’ll see the symptom without the cause. A request killed at the CPU ceiling needs its own line on the dashboard.

The observability you build before you scale

The report’s most useful advice is the one that sounds least exciting: build unified observability before you scale to many APIs, not after.

Twenty-four APIs is not four APIs six times. At one or two, you can hold the whole thing in your head and check the dashboard by eye. At twenty-four, you cannot, and the failures stop being individual: a shared upstream degrades and eight of your APIs get slow at once, and without a single pane that shows all of them you’re debugging blind, one dev-tools tab at a time.

The other operational note worth stealing: put rate limiting in the Worker itself, independent of whatever the upstream does. The edge is where you see all the traffic, so it’s where you throttle a misbehaving caller before it reaches, and takes down, the backend everyone shares. Don’t rely on the upstream to protect itself. It has one client’s-worth of context. The edge has all of it.

What the $5 actually buys

The honest summary is that Workers give you a genuinely cheap, genuinely fast edge for the transport layer of an API, and a hard ceiling the moment you ask it to do integration’s real work. The $5 is not a lie and the 10ms is not a footnote. They’re two true things about the same platform.

The engineering is in knowing which of your workload lives on each side of that line. Put the proxying at the edge and celebrate the bill. Put the heavy transform behind it and stay inside the budget. Get the split wrong and you’ll relearn the 10ms wall the expensive way: in production, with real data, at 3 AM.