MailySend

Resend, on your Cloudflare.

The complete email platform — transactional sending, marketing broadcasts, automations, inbound mail with threading and deliverability analytics — running entirely on Cloudflare Workers, in your own account. Drop-in compatible with the Resend API. MIT licensed. Also runs on a plain Node server with no Cloudflare account at all.

Live demo → mailysend.com  ·  Docs  ·  Dashboard tour  ·  Honest comparisons  ·  Cost

Why this exists

You like Resend's API. You do not like that your sending history, your contact list and your bounce data live in someone else's account, on their retention policy, at a per-email markup over what the bytes actually cost.

MailySend is that API — reimplemented on Cloudflare's own primitives — plus everything a platform can do only when it runs where your data already is.

  import { Resend } from 'resend'
- const resend = new Resend(process.env.RESEND_API_KEY)
+ const resend = new Resend(process.env.MAILYSEND_API_KEY)
+ // RESEND_BASE_URL=https://your-deployment/v1

The resend npm package honours RESEND_BASE_URL, so that really is the whole migration — no code changes, no rewrite, no lock-in either direction. There is also a first-party mailysend SDK, and mailysend/compat exports a Resend class with the same method names if you would rather be explicit.

What you get

How it compares

MailySend vs. the hosted services

This is the same matrix the site publishes at /compare, including the last row.

Resend has grown into a genuinely capable marketing product, and this table says so — the rows the artboards originally marked "No" now read the way a prospect would actually find them. The thing Resend still cannot be is yours. And Postmark measures placement better than we do; that row says so too.

What it costs to send 100,000 emails a month

Same product either way: same API, same dashboard, same logs, same analytics, same inbound. The transport is one line of configuration and you can change it later, so the row to read is whichever backend you already have an account with.

Amazon SES on its own is about $10 at this volume, and it is worth being clear about what that buys: an SMTP wire. No dashboard, no event timeline, no segments, no broadcasts, no inbound, and CloudWatch where the analytics would be. MailySend runs on top of SES for the same $0.10 per thousand — that is the first row of this table, not a competitor to it.

Estimates for planning, not a quote — and the same formulas the site's own calculator runs, so you can move the slider at mailysend.com/pricing and check them. The dashboard also shows your real month-to-date Cloudflare spend next to your send volume, so the estimate is answerable to a number.

See it running

Everything below is the live deployment at mailysend.com — one Node process behind nginx, or one Worker, from this exact repository. Real traffic, not empty states.

The overview, on a month of sending

Sent, delivered, bounced, complained and the hourly curve — with the counts of record coming from SQL rollups, never from a sampled analytics store.

Analytics that names its own denominators

A 30-day series, delivery grouped by receiving domain and by the tags you set at send time, opens and clicks split by who actually generated them, and inbox placement per provider with the source of every figure attached.

Every message, and what happened to it The full log with filters that live in the URL, and a drawer per message: state timeline, the SMTP conversation, every webhook attempt and its response, and the raw MIME.	One message, all the way down
Domain setup that finishes Every DNS record for the active transport, copy-buttoned, with SPF/DKIM/DMARC state and the deliverability posture on one page.	Broadcasts with a real denominator Progress from the coordinator's own counters, and every engagement rate stated over the denominator it was actually computed from.
Audiences and live segments Contacts, custom properties, CSV import, and segments written in a real query DSL that compiles to parameterised SQL.	⌘K to anywhere Jump to any message, domain, template or doc page. G L for logs, G B for broadcasts. No screen in the product ends in "contact support".

The comparison page ships the rows where we lose, too. See it live →

Get running

Path 1 — Cloudflare Workers (one click)

The button forks the repo, connects it to Workers Builds, then builds and deploys. The build creates the account resources the Worker binds — see below; the button itself provisions less than its documentation implies.

The deploy form has no fields on it. There is nothing you need to know before the first boot: on its first request the instance applies its own migrations, creates the workspace, generates and stores a 32-byte signing secret, learns its own public URL from the request it is answering, and prints one bootstrap API key to the log.

That form is built from the repo's .env.example, and it is worth knowing exactly what Cloudflare does with it: it shows key names only — never the comments — it stores every answer as a secret, and it does not prefill from the values in the file. So a key with a perfectly good default renders as a blank, masked, mandatory-looking password box, indistinguishable from a credential the deployment cannot start without. That is why the file carries no keys at all. Every variable — MS_MODE, MS_LANDING, MS_DEFAULT_PROVIDER, EVENT_DETAIL, MS_OWNER_EMAIL and the MS_OIDC_* group — is listed with its default in docs/CONFIGURATION.md and set afterwards with wrangler secret put or a vars entry.

When it finishes, open the deployment's URL. It lands on /setup, where you claim the instance with a passkey — no email, no DNS and no identity provider needed, because a freshly deployed Worker has none of those.

The first person to reach /setup takes the deployment, so claim it now rather than later. Setting MS_OWNER_EMAIL narrows the claim to one address — it does not create an owner, it restricts who may become one. For a URL that is public before you get to it, MS_REQUIRE_CLAIM_CODE=1 makes first boot print a claim code to the deploy log (wrangler tail, or the Worker's Logs tab) that /setup then demands, so whoever finds the deployment first cannot claim it without reading its log. Everything else can wait until you are inside.

The build creates what the button does not. wrangler deploy validates every binding before it uploads, so a missing queue or namespace is a failed deploy rather than a degraded Worker — a clean account used to fail one resource at a time. build:cf therefore ends by running scripts/ensure-resources.mjs, which creates the twelve queues, the R2 bucket, the D1 database and the two KV namespaces, then writes the generated D1 and KV ids into the config wrangler deploys. It matches by name and creates only what is missing, so every build after the first is a no-op — which matters, because re-creating SUPPRESSIONS rather than reusing it would silently empty it. It acts only inside Workers Builds (WORKERS_CI=1) or under MS_ENSURE_RESOURCES=1, so building locally never touches your account. Analytics Engine datasets need nothing; they are created on first write.

To do it yourself instead, from your own machine:

export CLOUDFLARE_ACCOUNT_ID=... CLOUDFLARE_API_TOKEN=...
npx mailysend provision

That token needs Queues:Edit, plus Workers Scripts:Edit, D1:Edit, Workers KV:Edit and Workers R2:Edit if you also deploy with it rather than from the button. .github/workflows/deploy.yml runs both steps on workflow_dispatch if you would rather it happened in CI.

The commands Cloudflare guesses now work. They did not always: it proposes pnpm deploy, which never runs the script of that name because deploy is one of pnpm's own subcommands and the built-in always wins, and then a bare npx wrangler deploy from the repo root, where wrangler cannot tell which workspace package is the Worker. So no script here is called deploy any more, and build:cf ends by writing a root wrangler.json — a copy of the config Vite generates next to the bundle, with its paths rewritten, regenerated on every build and gitignored.

To set them explicitly instead, under Workers → your Worker → Settings → Builds:

The -c matters: the Worker is built by Vite, and the wrangler config it deploys from is the one Vite generates next to the bundle, not the apps/app/wrangler.jsonc you edit.

Path 2 — a Node server (no Cloudflare account)

node:sqlite backs the database, the filesystem backs blobs, and in-process actors back the Durable Objects. Same code, different driver.

pnpm install
pnpm build:node
PORT=8917 node apps/app/node-server.mjs

That is the whole command — there is no required environment variable on this path either. First boot migrates the database, creates the workspace, generates and stores the signing secret, and prints one API key. The key is printed exactly once, because only its SHA-256 hash is ever stored. Then open http://localhost:8917/, which sends you to /setup to claim the instance with a passkey.

The first person to reach /setup claims it. Set MS_OWNER_EMAIL=you@your-domain.com to narrow the claim to a single address, MS_REQUIRE_CLAIM_CODE=1 to have first boot print a claim code that /setup then asks for — the log is the one place it exists, and reading the log is the proof — and MS_SECRET to a 32-byte hex string if you would rather keep the signing key out of the database and be able to rotate it. All optional. The full list is in docs/CONFIGURATION.md.

The guides, once it is up:

pnpm build:node
pm2 start ecosystem.config.cjs
pm2 save && pm2 startup

map $http_x_forwarded_proto $ms_forwarded_proto {
    ""      $scheme;
    default $http_x_forwarded_proto;
}

server {
    listen 80;
    server_name your-domain.com;
    client_max_body_size 200M;

    location / {
        proxy_pass http://localhost:8917;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $ms_forwarded_proto;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_cache_bypass $http_upgrade;
    }
}

Then send something

curl https://your-deployment/v1/emails \
  -H "Authorization: Bearer ms_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "from": "you@your-domain.com",
    "to": ["someone@example.com"],
    "subject": "Hello",
    "html": "<p>It works.</p>"
  }'

The id comes back before any provider is contacted. That is deliberate: the id is ours, minted at accept time, so it survives a failover, a provider migration, and a provider that loses its own id. provider_message_id is recorded later and is queryable, but it is never the identity of a message.

And then receive something

Sending and receiving are two independent setups on the same domain, and the second one is configured in two different places — which is the whole reason the first test message usually bounces.

1. Cloudflare dashboard → Email → Email Routing. Enable it (Cloudflare publishes the MX records itself), then add a catch-all rule whose action is Send to a Worker, pointed at this instance's script. That is what delivers the domain's mail to MailySend.
2. In MailySend, under the domain's Receiving tab, create a mailbox — and turn on Catch-all on it if you want every address on the domain to land there rather than only the one you named.

Step 1 alone is not enough. Mail for an address with no mailbox and no catch-all is refused at the door with a legible 550 5.1.1 No such mailbox, which is the honest answer to a typo and tells a spammer nothing — but it is also exactly what "I bound the catch-all and nothing arrived" looks like. Check receiving on the domain resolves its MX and says which of the two halves is missing, and both outcomes are written to the event timeline rather than only to wrangler tail.

Getting into the dashboard

The API takes a key; the dashboard takes a session. A brand-new deployment has no verified sending domain, no identity provider and nobody to email, so the first session cannot come from any of those. It comes from claiming the instance.

1 — Claim it at /setup. The first person to open it registers a passkey and becomes the owner. The claim is a single conditional insert, so two people opening /setup at the same moment produce exactly one owner — the other is told the instance is already claimed. Then it offers, both skippable, adding a sending domain and minting your first API key with a live test send.

2 — Save the recovery codes. Ten of them, shown once, single-use. They are the way back in if the passkey is gone, and the reason removing your last passkey is allowed at all.

3 — Sign in afterwards with the passkey alone. No email typed: the credential is discoverable, so the browser offers it and /sign-in trades the assertion for a session.

Three other doors exist, and the sign-in page renders each one only when it is actually open — an offered door that answers 501 is worse than no door:

Until a domain is verified, POST /v1/auth/otp answers 202 {"status":"unavailable"} and the page says so, instead of pointing you at an inbox that will never receive anything.

Locked out? npx mailysend claim --url https://your-instance is the break-glass path, and it keeps working after the instance is claimed. It proves control of the deployment rather than of an inbox: it writes a one-time nonce into the instance's own database — through the Cloudflare D1 API when CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN are in your environment, otherwise by printing the exact wrangler d1 execute command for you to run — and then proves it knows that nonce. Only somebody who can write that database can produce it. You get a session and a fresh API key.

On the CLI, npx mailysend login uses a device code: it prints an eight-character code and a URL, you approve it at Settings → Access in a browser that is already signed in, and the CLI receives a full-access key named after the client — revocable from the same screen as any other key.

Moving to your own domain is done from Settings → Access. This matters more than it looks: a passkey is bound to a hostname, so changing the host invalidates every passkey registered on the old one. The instance stores the hostname each credential was registered for, shows you which are still usable, and tells you plainly that you need a recovery code and a re-registration on the new host. mailysend claim remains the guaranteed way in, which is what makes offering the move as a button safe at all.

There is no password store. A self-hosted email platform that invents one is adding the single credential most likely to be reused and leaked.

What we are honest about

A deliverability product that overstates what it measures loses credibility permanently. These appear in the docs, in the UI, and here.

• Delivery semantics. Exactly-once for API acceptance and for state and event accounting. At-least-once for wire delivery, webhook delivery and analytics datapoints. Anyone claiming exactly-once SMTP delivery is lying.
• One duplicate source is not fully defensible: the provider accepted the message and the worker died before the database write. No provider offers an idempotency key for this. It is minimised (provider_message_id written first, a 120-second lease) and it is measured and alerted on rather than claimed away.
• Inbox placement is not observable from delivery events. SMTP 250 means accepted, not inboxed. Every placement figure carries source (seed / postmaster / snds / estimate) and a confidence, and estimates are visibly labelled as estimates.
• Open rates are approximate. Apple Mail Privacy Protection prefetches every pixel. Nothing is discarded — each hit is classified human / mpp / proxy_prefetch / scanner / bot — charts default to human, and the privacy-adjusted rate excludes MPP from both sides of the ratio.
• Cloudflare Email Service is in beta, Workers Paid only, with a daily quota that ramps with reputation and is not published. MailySend learns that ceiling (halve on rejection, raise at most 2× after a clean day), so a first large send slows itself down instead of generating thousands of errors and a reputation hit.
• Attachment limits are per transport. Cloudflare caps a message at 5 MiB (25 MiB only to verified destinations); SES at 40 MB. The API returns a typed error naming the active provider's limit rather than failing at the wire.
• SMTP ingress cannot run on Workers. connect() is egress-only and there is no inbound TCP listener. apps/smtp-shim is a container image. Self-hosters who will not run one can point at Cloudflare's own smtp.mx.cloudflare.net:465 — but those sends will not appear in MailySend's logs, analytics or webhooks, and the docs say so.
• Automations have a real ceiling. Workflows V2 caps 50,000 concurrent instances. Instance mode (exact per-contact timing) is capped at 40,000 active enrollments and refuses beyond it. Cohort mode is the default at audience scale — one instance per hourly cohort of ≤25,000, which puts 500,000 contacts over a month at roughly 720 instances, at the cost of timing quantised to the cohort clock.
• Analytics Engine keeps three months and samples under load. It is the hot query layer for charts. The count of record is rollups_daily in SQL; the archive is NDJSON in R2.
• alerts and alert_incidents are schema, not a feature. The tables exist and nothing reads or writes them; there is no alerting in the product. They are named here rather than left to be discovered in a schema dump.
• One SDK is first-party. mailysend for Node is written and published. The other languages are generated from /v1/openapi.json with openapi-generator — we ship the spec rather than claim nine hand-maintained SDKs.

Architecture

apps/
  app/          TanStack Start SSR + Hono /v1 + /mcp + every Durable Object
                + the email() handler + every queue consumer + cron
  track/        the tracking Worker — /o/*, /c/*, /u/* only, no database binding
  smtp-shim/    SMTP ingress as a container (Workers cannot listen on a TCP port)

packages/
  design-tokens/  colour, type and shape — CSS custom properties + Tailwind theme + TS
  ui/             shadcn primitives rethemed, plus this design's own vocabulary
  contracts/      Zod schemas → validation, OpenAPI, SDKs and dashboard types
  core/           ids, the tenancy seams, every durable key, crypto
  db/             Drizzle schema and one migration set for D1 *and* node:sqlite
  platform/       the runtime seam: Sql, Kv, Blob, Queue, Actor, Analytics
  providers/      cloudflare | ses | resend | smtp adapters, routing and failover
  events/         one normalized schema, deterministic ids, the state ladder
  durable/        every actor class
  segments/       the DSL parser and its parameterised SQL compiler
  templates/      Handlebars, MJML, a restricted JSX AST, and HTML post-processing
  workflows/      the automation step interpreter, on Workflows or the scheduler
  mcp/            the nine-tool MCP server
  sdk-node/       the `mailysend` npm package + `mailysend/compat`
cli/              npx mailysend

Configuration

Nothing here is required. The table is what you may want to override, not a checklist to work through before the first boot — see docs/CONFIGURATION.md for the long form.

Provider credentials set in the dashboard are stored as AES-GCM ciphertext and are never returned by the API. Environment variables are the fallback, which is what lets a fresh deployment send on its very first request.

Development

pnpm install
pnpm dev            # vite dev on :8917
pnpm typecheck
pnpm test           # 764 tests
pnpm lint
pnpm --filter @mailysend/app preview   # wrangler dev, on Miniflare

The dev cache (.vite-dev) and the build outputs (.output for Node, .output-cf for Cloudflare) are separate directories, so a running dev server and a production build never contend for the same files.

The check that matters most is scripts/contract-check.mts. It boots the server, seeds a row of every kind, then reads all 23 dashboard endpoints back through the dashboard's own Zod schemas — so schema drift surfaces as a failed check rather than as an error card in production. Its first version passed while the domains screen was broken, because there was no domain to disagree about; seeding first is the fix.

node apps/app/node-server.mjs &
KEY=ms_live_... pnpm exec tsx scripts/contract-check.mts

Licence

MIT — see LICENSE. Do what you like with it, including running it as your own hosted service.