What the Cloudflare free tier actually covers for an email stack

You want to run sending, an inbox, and a newsletter on Cloudflare's free tier, but the pricing page lists six services with six different units (requests, rows, GB-months, operations) and none of them say "emails." So how far does free actually carry you?

The Cloudflare free tier carries a real email workload further than you would expect: 100,000 Workers requests per day, 5 million D1 rows read and 100,000 written per day with 5 GB of storage, 10 GB of R2 with free egress, and 10,000 Queues operations per day. For a small transactional sender plus a human inbox plus a modest newsletter, the binding limit is usually D1 writes per day or Queues operations per day, which works out to a few thousand emails per day before you pay anything. When you do cross over, it is a flat $5/month Workers Paid minimum, not a per-email charge.

This guide tallies each limit against actual email operations, shows where the curve bends, and is honest about which limit bites first. The numbers below are the published Cloudflare free-tier limits as of mid-2026; always confirm against the live pricing page before you build a budget on them.

What are the Cloudflare free tier limits for D1, R2, Queues, and Workers?

Here are the published free-tier limits for the four services an email stack leans on, with the paid-tier price for context so you can see what crossing the line costs.

Service	Free tier (per day or per month)	Paid tier overage
Workers	100,000 requests/day, 10 ms CPU per invocation	$5/mo min; 10M req/mo included, then $0.30/M
D1 reads	5,000,000 rows/day	25B/mo included, then $0.001/M rows
D1 writes	100,000 rows/day	50M/mo included, then $1.00/M rows
D1 storage	5 GB total	5 GB included, then $0.75/GB-month
R2 storage	10 GB-month	$0.015/GB-month
R2 Class A ops (writes/lists)	1,000,000/month	$4.50/M
R2 Class B ops (reads)	10,000,000/month	$0.36/M
R2 egress	Free	Free
Queues	10,000 operations/day	1M/mo included, then $0.40/M

Two things on this table matter more than the rest. First, R2 egress is free, full stop. That is the structural difference from S3, where egress is the line that grows with your traffic. Second, Cloudflare Queues moved onto the free plan in February 2026 (10,000 operations per day), which means you no longer need a paid plan just to run a queue-backed sender. Before that, Queues alone forced the $5/month upgrade.

Note the mix of daily and monthly windows. D1, Workers, and Queues meter per day; R2 storage and operations meter per month. That distinction is what makes capacity planning for email slightly fiddly, because email volume is rarely flat, and a daily limit punishes spikes that a monthly limit would absorb.

What does one email actually cost in Cloudflare operations?

One sent email is not one operation: it is roughly 2-4 D1 writes, 2 Queues operations, and 1-3 R2 puts, depending on how your stack is built. The "emails per day" question only has an answer once you count operations per email, so here is a realistic accounting for a queue-backed transactional sender.

A typical send path looks like this:

POST /send  (1 Workers request)
  -> INSERT into outbox            (1 D1 write)
  -> enqueue(message)              (1 Queues operation: write)
  -> PUT raw body to R2            (1 R2 Class A op)

queue consumer fires
  -> dequeue + ack                 (1 Queues operation: read/consume)
  -> HTTPS POST to delivery API    (1 outbound fetch, no extra CF metering)
  -> UPDATE outbox status          (1 D1 write)
  -> INSERT delivery log row       (1 D1 write)

That single email costs about 3 D1 writes, 2 Queues operations, 1 R2 Class A operation, and 1 Workers request (the consumer invocation is metered too, so call it 2 requests). Receiving and storing an inbound message is similar: parse on a Worker, write the raw .eml to R2, insert a messages row, maybe run an interpreter that writes a verdict row. Inbound that hits an AI classifier or full-text index will cost a few more writes.

Now divide each daily free limit by the per-email cost to find the ceiling:

D1 writes:   100,000 / day  ÷ 3 writes  ≈ 33,000 emails/day  (write budget)
Queues:       10,000 / day  ÷ 2 ops     ≈  5,000 emails/day  (queue budget)
Workers:     100,000 / day  ÷ 2 reqs    ≈ 50,000 emails/day  (request budget)

The Queues budget is the one that bites first, at roughly 5,000 emails per day. Add inbound mail, a newsletter blast, and the inbox UI polling for new messages, all of which spend from the same daily Queues and D1 budgets, and the real free-tier ceiling for a mixed workload lands somewhere around 2,000-4,000 emails per day. That is genuinely useful: it covers a side project, an early SaaS, a small newsletter, or a personal inbox replacement without spending a cent.

If your sender does not use Queues at all (synchronous send straight from the Worker), Queues stops being the binding limit and D1 writes take over at around 33,000/day, but you lose retry and backpressure handling. For anything beyond toy volume, keep the queue and treat 10,000 daily operations as your real budget.

Which limit do you hit first as you grow?

For an email stack the limits fall over in a predictable order: Queues operations per day, then D1 rows written per day, then D1 storage, then R2 storage, and you will likely never touch Workers requests or D1 reads. Knowing the order tells you what to optimize and what to ignore.

Queues operations (10,000/day). First to fall because every send and every inbound message touches the queue at least twice. Mitigation: batch. Cloudflare Queues lets a consumer pull a batch of messages in one operation, so a newsletter of 500 recipients enqueued as batches costs far fewer operations than 500 individual enqueues. Batching is the single highest-leverage optimization on the free tier.

D1 writes (100,000/day). Next, because logging is write-heavy. Every status transition, open, click, and bounce is a write. Mitigation: do not write a row per tracking pixel hit if you can aggregate, and keep raw bodies out of D1 entirely (they belong in R2). See how to design the D1 email schema for keeping writes lean.

D1 storage (5 GB). D1 fills if you store message bodies in the database. Do not. A messages table holding only headers, metadata, and an R2 key stays small for a long time; 5 GB of metadata-only rows is millions of messages. Put every body and attachment in R2.

R2 storage (10 GB). R2 fills slowly because email is small. Ten GB holds something like 100,000-500,000 typical messages with attachments, and at $0.015/GB-month the overage is trivial. With free egress, reading them all back into your inbox UI costs nothing. This is why storing email attachments in R2 is the default move, and why cold archives can live there indefinitely. R2 is one of the five Cloudflare primitives every email stack is built on, and there are more ways to put R2 to work in an email stack than attachment storage alone.

Workers requests and D1 reads. You will almost certainly never hit 100,000 requests/day or 5 million reads/day from email alone. These limits are sized for web traffic, and email is comparatively low-frequency. Stop worrying about them.

When does a Cloudflare email stack start to cost money?

A Cloudflare email stack starts costing money when you exceed a daily free limit, which moves you onto the Workers Paid plan at a $5/month minimum. The important nuance: you upgrade because of a daily ceiling (Queues operations or D1 writes), not because you accumulated some monthly total. A single heavy day, a big newsletter send, a traffic spike, can push you over even if your monthly average is comfortably free.

What the upgrade actually buys you is headroom, not a different pricing model. On Workers Paid you get 1 million Queues operations per month, 50 million D1 writes per month, 10 million Workers requests per month, all included in the $5. For most email workloads that is years of growth before per-unit overage matters. The overage, when it comes, is metered on operations and storage: $1 per million D1 writes, $0.40 per million Queues operations, $0.015 per GB-month of R2. None of it is per email.

That is the part worth internalizing if you are coming from Resend, SendGrid, or Mailgun. Those vendors meter the email itself: $X per thousand sends, plus a per-contact charge on the marketing side. Cloudflare meters the compute and storage underneath, and the email is invisible to the bill. At 50,000 emails a month a per-email vendor charges you for 50,000 emails; Cloudflare charges you $5 and does not notice. The cost curves cross early and diverge hard. The full comparison lives in what transactional email actually costs at volume, and the buy-vs-build math in the total cost of ownership of an email stack. The short version of why the bill stays small is in the reasons Cloudflare email costs a fraction of SaaS.

The honest caveat: free does not mean free of work. You operate the stack, you own the deliverability, you handle the bounces. The dollars are near zero on the free tier; the engineering time is not. Whether that trade is worth it is the real question, and it depends on whether you would rather pay a vendor or own the infrastructure.

How do I keep a real email workload inside the free tier?

Keep the workload inside the free tier by batching queue operations, keeping bodies in R2 instead of D1, and aggregating high-frequency writes like opens and clicks. These three moves push the binding limits out far enough that a small-to-mid email stack runs free indefinitely.

Concretely:

1. Batch queue operations.
   Enqueue and consume in batches. A 1,000-recipient newsletter sent
   as 10 batches of 100 is ~20 Queues ops, not 2,000.

2. Bodies and attachments go to R2, never D1.
   D1 holds headers, metadata, status, and the R2 object key.
   This keeps you under 5 GB D1 storage for millions of messages.

3. Aggregate tracking writes.
   Do not INSERT a row per open/click if you can count in memory
   and flush periodically. Each raw event is a D1 write against
   the 100k/day budget.

4. Use the daily reset, not a monthly average, to plan.
   Daily limits punish spikes. Schedule big newsletter sends to
   spread across days, or accept that one big day flips you to paid.

Do these and a few thousand transactional emails a day, an inbox, and a small newsletter coexist comfortably under the free limits. Skip them and a chatty tracking implementation can burn the D1 write budget by lunchtime.

Where does Tinbox sit on this curve?

Tinbox is built to live on exactly these free-tier limits, because it deploys onto your own Cloudflare account using D1, R2, Queues, and Workers directly. There is no Tinbox-side metering and no per-email fee layered on top; your bill is whatever Cloudflare charges for the operations your sending and receiving actually generate, which on the free tier is zero.

The stack is engineered with the limit order above in mind: raw bodies and attachments go to R2 (free egress, cheap storage), the D1 schema stays metadata-only, and the queue-backed sender batches operations so the 10,000-per-day Queues budget stretches. When you do outgrow free, you cross onto Workers Paid at $5/month, and the overage is Cloudflare's per-operation pricing, not a Tinbox markup. One brand and domain per deploy today, but multiple tenants can share a single Cloudflare account through separate deploys, so an agency can keep many small clients each comfortably inside their own free or near-free footprint.

You can stand the whole thing up and watch the metering yourself:

npx tinbox init example.com

That scaffolds the Workers, D1 database, R2 bucket, and queue on your account, and from there the Cloudflare dashboard shows you the real numbers against the limits in this guide. If you want to see the cost math worked through interactively first, walk through the email cost calculator, and if you are weighing the move off a per-email vendor, the Resend alternative breakdown covers where the curves cross.

Deploy this yourself: npx tinbox init <domain>. The deploy walkthrough and per-service limit notes live in the docs.