DEV Community: zerodrop

I built a disposable email service that costs $0 to run — here's the stack and the real numbers

zerodrop — Mon, 01 Jun 2026 22:52:12 +0000

Six weeks ago I was building an auth flow and needed a throwaway inbox to test if the password reset email actually arrived. I opened a temp email site, navigated past three ad banners, got a random address, and waited.

That workflow was broken enough that I built the infrastructure myself instead.

Here's what I built, what it cost, and what happened after.

The problem in one sentence

Every developer testing email flows either mocks the email (wrong), runs a local SMTP server (overkill), or uses a throwaway email site with ads (terrible DX). None of these are good answers.

The stack — chosen for $0 idle cost

Every service in the stack was chosen with one constraint: it must cost nothing at zero traffic and scale automatically when traffic arrives.

Layer	Service	Free tier
Email interception	Cloudflare Email Routing	Unlimited
Serverless logic	Cloudflare Workers	100k req/day
AI spam filter	Cloudflare Workers AI	Generous
Database	Upstash Redis	10k commands/day
Frontend	Next.js on Vercel	Generous
Domain (routing)	zerodrop-sandbox.online	₹89/year
Domain (brand)	zerodrop.dev	₹1,500/year

Total spend to launch: ₹1,589 (~$19)

That's it. No servers, no VMs, no managed databases with minimum monthly fees. The entire thing scales to zero when nobody is using it.

The architecture in plain English

An email arrives at anything@zerodrop-sandbox.online. Cloudflare intercepts it at the MX level and triggers a Worker function. The Worker runs a Llama 3 classification — if it's spam, it gets dropped silently. If it's legitimate, it gets parsed into clean JSON and pushed to Upstash Redis with a 30-minute TTL. The Next.js dashboard polls every 3 seconds and displays it instantly.

The whole thing processes an email in under 500ms from arrival to display.

The two-domain decision

The routing domain (zerodrop-sandbox.online) and the brand domain (zerodrop.dev) are intentionally separate. Disposable email domains get blocklisted. When that happens — and it will — you replace the routing domain for ₹89 and update one DNS record. The brand domain, the dashboard, the npm package, the users' bookmarks — none of it is affected.

This was a $10 architectural decision that prevents a future crisis.

The numbers after launch

These are real, unmanipulated numbers from the first week with zero paid promotion:

338 npm installs of zerodrop-client — organic, from search
1 confirmed organic user — visible in Upstash usage data. Someone found the site, generated an inbox, received a real email, and read it. Before any marketing.
6,300+ Redis commands in the first 72 hours — and climbing
$0.00 infrastructure cost
₹1,589 total spend including domains

The 338 npm installs before any promotion is the signal that matters. Developers are actively searching for this solution and finding it through keyword discovery alone.

What's coming next

The free tier works. The next milestone is the Workspace tier — custom domain routing, team seats, API keys, webhook support for CI pipelines. The pricing is $49/month per workspace.

The waitlist is open at zerodrop.dev. When 25-30 signups come from company email addresses, that's when the Workspace tier gets built. Until then the free tier runs itself.

The honest assessment

This is not a finished product. It's a free tier with a waitlist and a hypothesis: that QA teams at companies will pay $49/month for custom domain email testing infrastructure embedded in their CI pipelines.

The hypothesis is unproven. The free tier is real, the organic usage is real, and the npm downloads are real. Everything else is still a bet.

If you're building something similar or have feedback on the architecture — I'm at the @zerodropdev handle on X.

The SDK

npm install zerodrop-client

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();
const inbox = mail.generateInbox();
const email = await mail.waitForLatest(inbox, { timeout: 10000 });

→ zerodrop.dev

Testing email flows in Playwright without a mail server

zerodrop — Mon, 01 Jun 2026 22:24:39 +0000

Every QA engineer has written a test like this at some point:

test('user receives verification email', async ({ page }) => {
  await page.goto('/signup');
  await page.fill('[name="email"]', 'test@example.com');
  await page.click('[type="submit"]');

  // 🤔 now what?
  // mock the email? skip the assertion?
  // hope it works in production?
});

The verification email step gets skipped, mocked, or marked as "manual test only." The auth flow ships without end-to-end coverage. Six months later a misconfigured SendGrid template breaks signup and nobody catches it until users complain.

This is a solved problem. Here's how to test it properly.

Why mocking email is the wrong approach

Mocking your email provider in tests gives you confidence that your code calls sendEmail() — not that the email actually arrives, renders correctly, contains the right link, or doesn't get flagged as spam.

The things that actually break in production are never the things you mocked. They're the SendGrid template that got corrupted, the verification URL that points to staging instead of production, the email that arrives 45 seconds late and times out the user's session.

Real tests require real emails.

Why running a mail server is overkill

The traditional answer is to run a local SMTP server — Mailhog, Mailtrap, or Mailpit — in your test environment. This works but introduces real complexity:

You need the mail server running before your tests. In CI that means a Docker container, a service dependency, a health check, and a teardown step. Your test suite now has an infrastructure dependency that can fail independently of your application code.

For most teams this is more complexity than the problem warrants. You don't need a mail server. You need an inbox you can read from inside a test.

The pattern: real inboxes, real assertions

The correct abstraction is simple:

Generate a unique email address per test run
Use that address in your test flow
Wait for the email to arrive
Assert on the actual content

No SMTP server. No Docker dependency. No infrastructure to maintain.

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user receives password reset email', async ({ page }) => {
  // Generate a unique inbox for this test run
  const inbox = mail.generateInbox();

  // Use it in your app flow
  await page.goto('/forgot-password');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // Wait for the actual email to arrive
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Assert on real content
  expect(email.subject).toContain('Reset your password');
  expect(email.body).toContain('Click here to reset');

  // Extract the actual reset link and follow it
  const resetLink = email.body.match(/https?:\/\/[^\s]+reset[^\s]+/)?.[0];
  expect(resetLink).toBeTruthy();
  await page.goto(resetLink);

  // Assert you landed on the reset page
  await expect(page).toHaveURL(/reset-password/);
});

That test covers the entire flow end to end — form submission, email delivery, link extraction, and the destination page. No mocks anywhere.

The timeout error matters

Notice waitForLatest throws a ZeroDropTimeoutError if the email never arrives within the timeout. That's intentional and important.

A test that times out and throws is a test that fails loudly. Your CI pipeline goes red. Someone investigates. They find that SendGrid stopped delivering because of a misconfigured API key.

Compare that to a test that catches the timeout, returns null, and passes silently. The broken email flow ships to production.

import { ZeroDrop, ZeroDropTimeoutError } from 'zerodrop-client';

try {
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });
  expect(email.subject).toContain('Reset your password');
} catch (err) {
  if (err instanceof ZeroDropTimeoutError) {
    throw new Error(
      `Email never arrived at ${inbox} — check your email provider config`
    );
  }
  throw err;
}

Explicit failures with useful error messages are what separate a test suite from a false confidence generator.

Cypress integration

The same pattern works in Cypress:

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

describe('Email verification flow', () => {
  it('sends verification email on signup', () => {
    const inbox = mail.generateInbox();

    cy.visit('/signup');
    cy.get('[name="email"]').type(inbox);
    cy.get('[type="submit"]').click();

    cy.wrap(
      mail.waitForLatest(inbox, { timeout: 15000 })
    ).then((email) => {
      expect(email.subject).to.contain('Verify your email');
      expect(email.body).to.contain('verify');
    });
  });
});

CI/CD integration

In GitHub Actions the setup is zero — no services block, no Docker, no health checks:

- name: Run E2E tests
  run: npx playwright test
  env:
    ZERODROP_API_KEY: ${{ secrets.ZERODROP_API_KEY }}

That's the entire email testing infrastructure. One environment variable.

Compare to a Mailhog setup:

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

- name: Wait for Mailhog
  run: sleep 5

- name: Run E2E tests
  run: npx playwright test
  env:
    SMTP_HOST: localhost
    SMTP_PORT: 1025

Both work. One requires zero infrastructure.

The free tier is enough for most teams

For local development and smaller test suites, the zero-auth mode requires no API key:

// No API key — uses public sandbox
const mail = new ZeroDrop();
const inbox = mail.generateInbox();

Inboxes expire after 30 minutes and emails go through AI spam filtering. For CI pipelines that need custom domains, guaranteed delivery, and longer retention — that's what the Workspace tier is for.

npm install zerodrop-client

Try it on your next auth flow test. The first email that arrives in a real inbox inside a Playwright test is a satisfying moment.

How I built a zero-cost edge email pipeline using Cloudflare Workers

zerodrop — Mon, 01 Jun 2026 21:11:54 +0000

Every developer has hit this wall. You're building a password reset flow or an email verification step and you need a throwaway inbox to confirm the email actually arrives. Every existing tool either shows you ads, requires an account, or has an interface that looks like it was built in 2009.

So I built the infrastructure myself. Here's the architecture — and why each decision was made.

The core insight: email is just HTTP at the edge

Modern serverless platforms have made it possible to intercept inbound email the same way you'd intercept an HTTP request — with a lightweight function that runs at the edge, costs nothing at idle, and scales automatically.

Cloudflare Email Routing is the entry point. You configure a catch-all rule on a domain and every email sent to that domain — regardless of prefix — triggers a Worker function. anything@yourdomain.com, test-abc@yourdomain.com, qa-pipeline-7@yourdomain.com — all caught, zero per-address configuration.

The three-layer architecture

The system has three components that each do exactly one thing.

The routing domain. A cheap disposable domain — not your brand domain — that exists solely to catch email. The separation matters: if this domain ends up on a spam blocklist (and with disposable email services, it will eventually), you replace it for $10 without your main product going offline.

The Worker. When an email arrives, the Worker receives a message object containing the sender, recipient, headers, and the full raw MIME body as a readable stream. The Worker's job is simple: parse the relevant fields into a clean JSON structure and decide whether to store or drop it.

Upstash Redis. Emails are stored in a list keyed by inbox name — so test-abc@yourdomain.com maps to the Redis key inbox:test-abc. A TTL is set on every write. After 30 minutes the key expires automatically. No cleanup job, no stale data, no accumulating storage costs.

The decision that makes it economically viable: edge AI filtering

Without filtering, a routing domain gets discovered by bot farms within weeks of launch. They send thousands of automated emails — account farming scripts, scrapers, newsletter blasts. Each one costs a Redis write. At scale that burns through your free tier quota fast.

The fix is running a lightweight classification step inside the Worker before any database write happens. Using Cloudflare Workers AI with Llama 3, you can classify each email's sender and subject line in milliseconds. If the model flags it as automated spam, the Worker returns early — the email is silently dropped and never touches Redis.

The economics are stark. Cloudflare Workers AI inference at this scale costs fractions of a cent. A Redis write that gets skipped costs nothing. The filter pays for itself immediately.

The key architectural detail is the fallback: if the AI call fails for any reason, the email is allowed through. You never drop a legitimate developer test email because of an infrastructure error. Fidelity always wins over filtering.

What the free tier actually costs

Service	Free tier	First cost appears at
Cloudflare Email Routing	Unlimited	Never
Cloudflare Workers	100k req/day	~$5/month
Cloudflare Workers AI	Generous free tier	High volume
Upstash Redis	10k commands/day	$0.2/100k commands
Vercel	Generous free tier	$20/month

At zero traffic the monthly bill is zero. The first real cost appears when you're processing tens of thousands of emails daily — at which point you have a real product with real revenue to cover it.

The two-domain strategy

One architectural detail worth highlighting separately: never use your brand domain for email routing.

The routing domain exists to be burned. When it gets blocklisted — and it will — you update one DNS record and replace it with a fresh domain. Your brand domain, your dashboard, your users' bookmarks — none of it is affected.

The brand domain is precious. The routing domain is disposable. Treat them accordingly.

The SDK problem

Once the pipeline works, the natural next step is making it usable in CI. A REST API is a specification. What QA engineers actually need is an abstraction that hides the polling loop, handles timeouts gracefully, and throws a meaningful error when an expected email never arrives.

The difference between a tool and infrastructure is that abstraction layer. A three-line integration that works in Playwright and Cypress without the developer understanding what's happening underneath — that's what makes something get embedded in codebases and never removed.

The specific design decision that matters: a timeout should throw a named error class, not return null. CI pipelines need explicit failures. A test that silently passes because waitForEmail() returned null and the assertion was never reached is worse than no test at all.

What I built with this architecture

After proving the pipeline worked I packaged it properly. The result is ZeroDrop — a free, ad-free temporary email sandbox at zerodrop.dev.

The npm package zerodrop-client wraps the polling logic for CI pipelines:

npm install zerodrop-client

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();
const inbox = mail.generateInbox();

// Use inbox in your test...

const email = await mail.waitForLatest(inbox, { timeout: 10000 });
expect(email.subject).toContain('Reset your password');

The free tier uses a shared routing domain with AI filtering enabled. For teams who need custom domains, private storage, and unfiltered delivery — Workspaces are in private beta at zerodrop.dev.

The architecture in one sentence

Edge email interception → AI classification at the Worker level → Redis storage with TTL → polling API → SDK abstraction. Each layer does one thing and costs nothing until you have real scale.