{/* banner prompt: A minimal, clean top-down view of a Scandinavian-style light wood desk where a developer's hands arrange five simple wooden cards, each with an icon and a price, bathed in soft natural light from a window.

Additional instructions: The cards must show only simple engraved icons and short word labels, with no numbers, no dollar signs, and no price figures anywhere in the image. Anatomically correct, exactly two hands. */}
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](#references) section at the end so you can re-check them yourself, because cloud pricing pages change.

## D1: Cloudflare's serverless SQL database

[D1](https://developers.cloudflare.com/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.

<Table data={
    {
        headers: ['Dimension', 'Free (Workers Free)', 'Included (Workers Paid)', 'Overage'],
        rows: [
            ['Rows read', '5 million / day', '25 billion / month', '$0.001 per million rows'],
            ['Rows written', '100,000 / day', '50 million / month', '$1.00 per million rows'],
            ['Storage', '5 GB total', '5 GB included', '$0.75 / GB-month'],
        ]
    }
} />

## Durable Objects: stateful coordination at the edge

[Durable Objects](https://developers.cloudflare.com/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.

<Table data={
    {
        headers: ['Dimension', 'Included (Workers Paid)', 'Overage'],
        rows: [
            ['Requests (HTTP/RPC/WS/alarms)', '1 million / month', '$0.15 per million'],
            ['Duration', '400,000 GB-s / month', '$12.50 per million GB-s'],
            ['SQLite rows read', '25 billion / month', '$0.001 per million rows'],
            ['SQLite rows written', '50 million / month', '$1.00 per million rows'],
            ['SQLite stored data', '5 GB-month', '$0.20 / GB-month'],
        ]
    }
} />

## Workers: the compute underneath everything else

[Workers](https://developers.cloudflare.com/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.

<Table data={
    {
        headers: ['Dimension', 'Free plan', 'Included (Workers Paid, $5/mo)', 'Overage'],
        rows: [
            ['Requests', '100,000 / day', '10 million / month', '$0.30 per million'],
            ['CPU time', '10 ms / invocation, no overage', '30 million CPU-ms / month', '$0.02 per million CPU-ms'],
        ]
    }
} />

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](https://developers.cloudflare.com/email-routing/email-workers/send-email-workers/) 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.

<Table data={
    {
        headers: ['Dimension', 'Included (Workers Paid)', 'Overage'],
        rows: [
            ['Emails sent', '3,000 / month', '$0.35 per 1,000 emails'],
        ]
    }
} />

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

[Cloudflare Containers](https://developers.cloudflare.com/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.

<Table data={
    {
        headers: ['Dimension', 'Included (Workers Paid, $5/mo)', 'Overage'],
        rows: [
            ['Memory', '25 GiB-hours / month', '$0.0000025 per GiB-second'],
            ['vCPU', '375 vCPU-minutes / month', '$0.000020 per vCPU-second'],
            ['Disk', '200 GB-hours / month', '$0.00000007 per GB-second'],
        ]
    }
} />

## 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](/blog/2026/10/09-the-vibe-coding-trap-how-ai-written-code-turns-into-a-five-figure-cloud-bill/), which walks through what those bills actually looked like for the people who got them.

## References

- [D1 pricing](https://developers.cloudflare.com/d1/platform/pricing/), Cloudflare Developer Docs
- [Durable Objects pricing](https://developers.cloudflare.com/durable-objects/platform/pricing/), Cloudflare Developer Docs
- [Workers pricing](https://developers.cloudflare.com/workers/platform/pricing/), Cloudflare Developer Docs
- [Email Service (Email Sending) pricing](https://developers.cloudflare.com/email-service/platform/pricing/), Cloudflare Developer Docs
- [Containers pricing](https://developers.cloudflare.com/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.*


d929424c1dcaf173f095ba851c8742134352b25c62c457842e4ccadb48c8e8c0

What Cloudflare D1, Durable Objects, Workers, Email Sending, and Containers actually do, realistic use cases for each, and their current official pricing, verified against Cloudflare's own documentation.

A practical look at five Cloudflare developer products (D1, Durable Objects, Workers, Email Sending, and Containers): what each is for, when it earns its place, and what it actually costs according to Cloudflare's current price sheet.

Tag: Workers

Tag: Workers

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