I Built a Disposable Email Service on Cloudflare Workers + Upstash Redis. Here's the Architecture.
I run VanishInbox, a free disposable email service. No signup, no backend server in the traditional sense, no database in the traditional sense either. Just Cloudflare and Redis doing the work. Here's how it's put together.
The problem
Disposable email sounds trivial until you sit down to build it. You need an address that receives real mail from real mail servers, stores it somewhere, and then deletes itself without anyone lifting a finger. Three requirements pull in different directions: you need to accept SMTP traffic, you need fast reads for the inbox UI, and you need guaranteed deletion without running a cron job that might fail silently at 3am and leave stale data sitting around.
Most tutorials on "build a temp mail service" skip straight to a database schema. That's the wrong starting point. The interesting part is the deletion.
Why Redis TTL instead of a cleanup job
I store every inbound email in Upstash Redis with a native TTL of 10 minutes. When the TTL expires, Redis removes the key itself. No worker scanning for expired rows, no scheduled job, no risk of a cron trigger getting skipped and leaving orphaned data behind.
This was a deliberate tradeoff. A cron-based approach gives you more control (you can log deletions, run analytics before purging, batch things up), but it adds a moving part that can fail. With TTL, the expiry is a property of the data itself. The email can't outlive its own storage layer even if every other part of the stack goes down.
The downside is you lose the ability to do anything clever at deletion time. I decided that's fine. The entire value proposition is that the data is gone. Building tooling to intercept its own disappearance would work against the point.
Receiving mail without running a mail server
This is the part people usually assume needs a dedicated SMTP server sitting somewhere. It doesn't.
Cloudflare Email Routing sits in front of the domain and catches inbound mail at the DNS/MX level. Instead of forwarding it to a real inbox, I route it to a Cloudflare Worker. The Worker receives the raw message, parses the MIME content (headers, plaintext body, HTML body, attachments), and writes the parsed result into Redis under a key derived from the generated inbox address.
The frontend polls that same key. When a message lands, it shows up in the inbox UI within a couple of seconds. There's no queue, no message broker, no server process that has to stay alive between requests. The Worker only runs when mail actually arrives.
This is the architecture I'd point to if someone asked what "edge computing" actually buys you in practice. You get a mail-receiving service with zero idle compute cost and zero server to patch or maintain.
Why 10 minutes specifically
The number isn't arbitrary. It needs to be long enough to receive a signup confirmation or verification code without the user racing a countdown, and short enough that the address doesn't become a semi-permanent throwaway account that ends up on spam lists or gets scraped and indexed somewhere. 10 minutes covers almost every real verification flow while keeping the inbox's useful life short enough that abuse has a low ceiling.
The problem nobody warns you about: bot traffic
Once the service was live, the biggest engineering problem wasn't email parsing. It was bots hammering the inbox API to generate addresses at scale for their own automation.
Core Web Vitals data doesn't help here. A headless browser running Playwright generates the same paint and interaction metrics a real user does, so you can't use performance telemetry to separate bots from people. I ended up deploying a Cloudflare Turnstile invisible check across the tool pages, a signed short-lived cookie proving a real verification pass, and a rate limit on the inbox API endpoint (20 requests per 10 seconds triggers a managed challenge). A couple of high-volume IPs still got blocked directly because they ignored all of it and kept hitting the API in a loop.
None of that shows up in an architecture diagram, but it's most of the ongoing maintenance work.
What I'd do differently
I'd build the rate limiting and bot detection at the same time as the core service, not months after launch. Ephemeral, free, no-signup tools are exactly the kind of target automation goes after first, since there's no account to ban and no friction to slow it down.
If you want to see the whole thing running, the tool itself is live at vanishinbox.com/10-minute-email.
Top comments (0)