Cost
Self-Hosted Email on Cloudflare: The Setup That Replaces Your Monthly Email Bill
Add up what receiving email costs you: a per-seat fee times every mailbox, every month, forever, climbing each time you add an address. Now price the very same mail as what it actually consumes — a sliver of compute when a message arrives, a little storage while it sits. The two numbers aren't close, and the gap between them is the whole case for self-hosted email on Cloudflare.
The pieces of this setup are quickly told: your domains' MX records point at Cloudflare Email Routing, a Worker seals each arriving message to your key, encrypted storage holds the ciphertext, and an app on your device unlocks it. That's the machinery. This article is about the arithmetic — why moving your mail onto services you pay for directly, by the resource, breaks the link between what you pay and how many addresses you keep.
Two different meters
A per-seat plan and a resource bill don't just differ in size. They measure different things, and that's why one grows without limit while the other barely moves.
- The per-seat meter counts labels. It charges for every mailbox and often every domain, so the total is a multiplication: price per seat times number of seats times months. Add an address and you've added a term to the product — the meter spins whether or not a single extra message ever arrives.
- The resource meter counts work and bytes. It charges for the compute a message actually uses and the storage it actually occupies. Those depend on how much mail you have, not on how many names wear your domain.
The inversion sitting inside that difference is the entire point: you have one person's worth of mail no matter how many addresses answer to you.
Priced as resources: what one message really uses
"Rounding error" and "sliver" are easy to say and easy to doubt, so price the mail in the platform's own two units — one invocation each time the Worker runs, one gigabyte of storage at rest — and read the result as ratios, the way any break-even is read.
Compute, per message
One arriving message triggers about one invocation: the Worker wakes, parses the message, seals the body to your public key, writes the ciphertext, and exits — a fraction of a second of processor time, then nothing until the next message. Call it one invocation per message, a few at most if a large attachment is chunked. Now size a heavy correspondent: tens to low hundreds of messages a day is, generously, a few thousand invocations in a month. The entry allowance for that same work is counted in the millions of invocations a month. Thousands against millions is three orders of magnitude of headroom — that is what "rounding error" means, said as a ratio. And the count tracks messages, not names: ten addresses funnelling into one inbox fire the same few thousand invocations as one, because the Worker runs once per message no matter which address carried it.
Storage, per year
A year of ordinary correspondence — text, threads, the occasional attachment — lands in the low single-digit gigabytes for a heavy writer and a fraction of one gigabyte for most people. Encrypted storage is sized in gigabytes, so even the smallest allowance holds not one year but a decade and more of one person's archive before the figure so much as twitches. As a ratio: a normal year is a small fraction of the smallest tier, and every address pours into that one archive, so a stack of domains stores one person's mail, not one copy per name.
The same bill, itemized
Strip the metaphor away and here is literally what the meter sees, per message and per year:
- Per message: one short compute run — receive, seal, store — then idle. Measured in invocations and milliseconds, a few thousand of them across a busy month.
- Per year: a few gigabytes of ciphertext at rest at the very outside, growing only as fast as you actually write and receive.
- Per address: nothing the meter can see. An address is a routing rule, not a resource — a line in a DNS zone, not load on the Worker.
| What it measures | Per-seat plan | Resource bill on Cloudflare |
|---|---|---|
| Unit you're billed for | Mailboxes and domains | Compute per message, storage per byte |
| What makes it grow | Adding addresses | Adding actual mail volume |
| Cost of your next address | Another full seat | Effectively nothing |
| Cost of your next domain | Often another line item | A DNS change, no added fee |
| What the total tracks | How many names you have | How much mail you have |
A worked example, in magnitudes
Put those units to work. Picture someone with a dozen addresses spread across a few small projects — hello@, support@, invoices@ and the rest. On a per-seat plan that's a dozen line items, each billed every month. Priced by resources it is still one person's correspondence: the same few-thousand invocations a month and the same low-gigabyte year, whether that mail enters through one address or twelve. The invocations stay in the thousands against an allowance in the millions; the storage stays a fraction of the smallest tier; the total is dominated by a flat platform floor that never notices the twelfth address, because nothing the meter counts has changed.
Where the resource model has an edge — and where it doesn't
Be honest about the shape of the curve. The resource model wins precisely because a normal person's mail is small and steady: tens of messages a day and a low-gigabyte year never trouble the bottom tiers, so the bill is a flat floor. That advantage would narrow only at volumes an individual or small team never reaches — a firehose of messages, or an archive the size of a media library — where compute and storage finally become the thing you're paying for. For the person juggling a stack of custom domains, that crossover is purely theoretical; you'd have to multiply your real mail by orders of magnitude to feel it. The per-seat plan, by contrast, has already started climbing at address number two. That's the asymmetry: one meter charges you for having many names today, the other only at a scale you'll almost certainly never touch.
The honest limits worth knowing first
Cheaper and yours doesn't mean magic, so here are the caveats before you commit:
- A plaintext moment on arrival. Mail reaches the Worker in plaintext and is sealed a split second later. Zero-access encryption protects what's stored, not what's in flight into your inbox. The window is brief and on infrastructure you control, but it's real.
- Sending rides on a provider. Cloudflare receives your mail; getting replies reliably delivered to the rest of the world is handled by a sending provider. You own the inbox and the key; the last hop out isn't yours.
- No "unhackable" claims. The honest promise is specific: what sits in your inbox at rest is unreadable to anyone but you — including Cloudflare and the people who wrote the software — because only you hold the key.
None of those touch the arithmetic. The cost case stands on its own: the day you stop paying by the seat and start paying by the resource, your email bill stops tracking your growth and starts tracking something that barely changes.
- What exactly do I pay Cloudflare for?
- The managed services this runs on — receiving mail, running the Worker, and storing your encrypted mail. It's a flat, low monthly cost paid directly to Cloudflare, with no per-mailbox or per-domain fee on top.
- Does Cloudflare send my outbound mail too?
- Receiving is handled on Cloudflare; reliable sending is handled by an email-sending provider. You own the inbox and the key, and lean on that provider for the final delivery hop.
- Can Cloudflare read my stored email?
- No. Storage holds only ciphertext sealed to your key, which lives on your device. The honest exception is the brief plaintext moment when a message first arrives before it's sealed.
- How many domains can one Cloudflare setup handle?
- As many as you want, all feeding one encrypted inbox. Adding a domain is a DNS change with no added fee, which is the whole reason the monthly cost stays flat.