Cloudflare's Developer Platform: Services, Use Cases, and Real Pricingeric

Cloudflare has become a default stop for anyone putting something on the internet, and the reason is simple: it gives away an unusual amount for free. Point your domain's nameservers at it and you get DNS hosting that's fast and free, caching and CDN so your site is served from a few hundred cities instead of one box, DDoS protection with no attack-size cap, and free SSL certificates that renew themselves. For a huge number of sites that's the entire relationship with Cloudflare: a free, genuinely excellent front door, and no invoice.

What's less widely known is the rest of the platform sitting behind that front door: a full developer stack (compute, SQL, stateful coordination, email, containers) that a lot of developers end up using once they're already there. These are the services that do meter, and because the free front door sets the expectation that Cloudflare is the cheap option, it's worth knowing in detail what each one does and what it charges before you build on it.

Every number below was pulled from Cloudflare's developer docs at the time of writing; links are in the references section at the end so you can re-check them yourself, because cloud pricing pages change.

D1: Cloudflare's serverless SQL database

D1 is a managed SQLite database that runs close to your Workers. You get normal SQL (tables, indexes, joins, transactions) without running a database server, and it replicates for read availability without you configuring anything. For a Worker that needs structured, queryable state (a SaaS app's primary store, a CMS, a small analytics table), it's genuinely pleasant to use: no connection pooling to think about, no server to patch, first ~5 GB free.

Good use cases: the backing store for a small-to-medium web app, per-tenant data for a multi-tenant SaaS (D1 supports many databases cheaply), read-heavy content like a blog's post index, anything where "a Postgres box I have to manage" is overkill.

How it's billed: per row read and written, not per query. Writes are roughly 1,000x the unit price of reads, which is worth keeping in mind when you design your access patterns.

Durable Objects: stateful coordination at the edge

Durable Objects give you a single, globally-addressable instance of a class that holds state in memory and on disk, with strong consistency. That's the thing Workers alone can't do, since a Worker has no persistent identity between requests. They're the right tool for coordination problems: a chat room, a multiplayer game session, a per-user rate limiter, a websocket hub, a workflow that needs to "wake up" later via an alarm.

Good use cases: anything that needs one authoritative, stateful coordinator. WebSocket fan-out, collaborative editing, a queue-per-tenant, a cron-like job scheduled with setAlarm().

How it's billed: on three axes at once. Requests (including alarm invocations), GB-seconds of duration while the object is live, and the same SQLite row-read/row-write storage rates as D1 for anything it persists.

Workers: the compute underneath everything else

Workers is the serverless JS/WASM runtime everything above actually runs on. It's billed on two axes: requests (how many times your code ran) and CPU time (how long it actually used the CPU per invocation, not wall-clock time spent waiting on I/O, just active compute). The free plan is genuinely usable for small projects; the paid plan's $5/month buys a real amount of headroom.

Good use cases: API backends, edge middleware (auth, redirects, A/B routing), webhook handlers, anything latency-sensitive that benefits from running in 300+ cities instead of one region.

How it's billed: on both axes independently: the number of invocations, and the CPU milliseconds they consume. Note that CPU time counts only active compute, not wall-clock time spent waiting on a fetch() or a database round-trip, so an I/O-heavy Worker is cheaper than its response time suggests.

30 million CPU-ms is about 8.3 CPU-hours a month before overage kicks in. The overage rate works out to roughly $0.072 per CPU-hour, which is cheap per unit but adds up quickly if individual requests are taking seconds instead of milliseconds.

Email Sending: transactional mail without a third-party provider

The Email Workers send binding lets a Worker send transactional email directly (magic-link logins, notifications, receipts) without wiring up a separate provider. It requires the Workers Paid plan, and the price per email is low.

Good use cases: magic-link authentication, transactional notifications, low-volume outbound mail tied to app events.

How it's billed: per email sent, after a monthly allowance. Hard bounces still count against the quota; sends to verified destination addresses in your own account are free and don't consume it.

Containers: a real Docker container, at real-infrastructure prices

Cloudflare Containers let you run an actual Docker container at the edge, orchestrated from a Worker. It's useful when a workload genuinely needs a full OS process (a headless browser, a compiled binary, a long-running agent loop) rather than the constrained Workers runtime. It's the one product on this list that behaves like traditional infrastructure, and it's priced like it too.

Good use cases: sandboxed code execution, headless browser automation, anything that needs a real filesystem and process model Workers can't provide.

How it's billed: unlike everything else on this list, a container is metered on wall-clock time, not on work done. Memory, vCPU, and disk all accrue continuously while it's running, idle or not. The Workers Paid plan's $5 includes a modest allowance, after which a small always-on container runs to roughly $30/month before it has served a single request. That's VPS-shaped pricing, and worth comparing against an actual VPS.

So when does Cloudflare actually make sense?

One point is worth stating plainly, because the free front door tends to obscure it: past a certain scale, serverless on Cloudflare is almost always more expensive than a VPS you manage yourself. That's not a knock on Cloudflare. It's the normal shape of serverless pricing anywhere. You're paying a premium per unit of work in exchange for not running servers, auto-scaling to zero, and being distributed across hundreds of edge locations by default.

That trade is worth it when:

• Traffic is spiky or unpredictable. You'd otherwise be paying for idle VPS capacity most of the time.
• Global latency matters and running your own multi-region fleet isn't realistic.
• You're pre-product-market-fit and the free tiers cover you entirely, genuinely free until real usage shows up.
• The workload is naturally short-lived, like a webhook handler, an API route or a redirect, where CPU time per request is milliseconds, not seconds.

It's worth a second look when:

• Volume is large and steady. A busy, predictable workload is the case where a $20-40/month VPS running Postgres and a web server will beat D1 + Workers + Durable Objects billed per-operation, often by a lot.
• The workload is a persistent process, not a request/response cycle. Containers exist for this, but at VPS-and-up pricing, not Workers pricing.

The other thing to understand before you build on any of this is what happens when the code driving these meters has a bug in it. Every service above bills on a dimension (rows written, GB-seconds, vCPU-seconds, emails) that a runaway loop can multiply by orders of magnitude without ever throwing an error. That's the subject of the companion post, which walks through what those bills actually looked like for the people who got them.

References

• D1 pricing, Cloudflare Developer Docs
• Durable Objects pricing, Cloudflare Developer Docs
• Workers pricing, Cloudflare Developer Docs
• Email Service (Email Sending) pricing, Cloudflare Developer Docs
• Containers pricing, Cloudflare Developer Docs

Prices current as of October 2026 and sourced directly from Cloudflare's own documentation. Always check the live pricing page before budgeting, since cloud providers change these numbers without much notice.