First-party email provider for Cloudflare Workers (Email Sending / send_email binding)

[swissky]

Problem: Production deployments on Cloudflare Workers — the platform @emdash-cms/cloudflare targets — have no email provider. The only built-in email:deliver hook is the dev console stub, so magic-link login returns 503 EMAIL_NOT_CONFIGURED, invites are copy-link-only, and notifications are skipped. Full analysis with code pointers in issue #1431.

Proposal: A cloudflareEmail() plugin factory in @emdash-cms/cloudflare/plugins (same style as vectorizeSearch):

import { cloudflareEmail } from "@emdash-cms/cloudflare/plugins";

emdash({
  plugins: [
    cloudflareEmail({
      from: { email: "cms@mails.example.com", name: "My Site CMS" },
      replyTo: "hello@example.com",   // optional
      binding: "EMAIL",               // optional, default "EMAIL"
    }),
  ],
})

• registers email:deliver as an exclusive hook (capability hooks.email-transport:register), selectable under Settings → Email — exactly the flow the EmailNotConfiguredError message describes ("Install and activate an email provider plugin, then select it in Settings > Email"),
• delivers through the native send_email Worker binding (Cloudflare Email Sending) — no API keys, no external service,
• resolves the binding via cloudflare:workers env, since hooks run without request context (avoids the cached-env workaround that vectorizeSearch needs),
• validates the sender eagerly (Email Sending rejects unverified senders) and fails with wrangler-ready error messages.

Implementation: PR ready (TDD'd: 8 unit tests with injectable env loader, changeset) — submitted in parallel; happy to adjust based on feedback. Out of scope by intent: BCC/attachments (the pipeline's EmailMessage doesn't model them yet) and auto-selection as provider (selection stays an explicit admin action).

Use case: lifespan.solutions went to production on Workers this week; the magic-link login needed to bootstrap a passkey on the new domain failed with the 503. We bridged it with a site plugin — but every Cloudflare deployment hits this wall.

[marcusbellamyshaw-cell]

This is exactly what the Cloudflare adapter has been missing. Running into that 503 error on magic-link logins in production is a massive headache, and I was just looking into having to wire up a custom site plugin to get auth working reliably for my own project.

Leveraging the native send_email binding is absolutely the right move here. Keeping it zero-dependency without needing to juggle third-party API keys (like Resend or Postmark) just to get basic platform notifications and invites out the door is a huge win for the developer experience. Also, relying on the cloudflare:workers env module to cleanly bypass the out-of-bounds execution context issues is a great architectural catch.

Really looking forward to seeing the PR land.