EmailFlare

EmailFlare is two Workers. The emailflare-api Worker sends mail for applications through Cloudflare Email Sending and has an admin panel. The emailflare-inbox Worker receives mail through Email Routing into a shared dashboard where a team replies and manages contacts.

The sending half is a Hono API with a React admin panel bundled into one Worker. The panel manages sending domains, templates, scoped API keys and suppressions, and shows send logs and stats. Applications send mail by calling POST /v1/send. Audience lists add RFC 8058 one-click unsubscribe headers; a recipient who unsubscribes is suppressed for every later send. On the receiving side, mail arrives through Cloudflare Email Routing at an email handler on the inbox Worker, gets threaded into conversations, and several users reply from a shared dashboard. Contacts, lists and outbound sequences cover the CRM part. Attachments go to R2. Every five minutes a cron trigger finds due sequence steps, and a Queue consumer sends them. A Durable Object pushes real-time notifications to the dashboard. Both Workers keep their data in D1. They rate-limit logins with a KV namespace and API calls with the Workers Rate Limiting binding. Separate just recipes set up each Worker by creating the Cloudflare resources, applying migrations, setting secrets and deploying, and a GitHub Actions workflow can deploy later updates. Each product also runs as a single Docker container with embedded SQLite for VPS hosting; in that mode the inbox also needs Redis.

Built for: Developers and small teams who want a self-hosted sending API and shared team inbox in their own Cloudflare account

What you can use it for

• Send transactional email from an app through a REST API with scoped keys
• Share one inbox on a custom domain across a team, with threaded replies
• Run outbound email sequences with one-click unsubscribe
• Manage templates, suppressions and send logs from one admin panel

Deploy

• CLI

  Branch trunk, requires Workers Paid

  Fill in scripts/config.toml before running setup. After the first deploy, set admin_origin and public_url to the Worker URL and run setup again. The inbox Worker deploys with just emailflare-inbox-deploy and also needs VAPID keys in the config.

  just install
  just emailflare-api-worker-login
  cp scripts/config.example.toml scripts/config.toml
  just emailflare-api-worker-setup

  Copy
  Docs

There is no Deploy to Cloudflare button: you install Node.js 18+, pnpm and just, fill a config file with secrets and a Cloudflare API token, run the setup recipe twice, and connect a domain for sending and for Email Routing.

What it needs to run

• D1 databasesemailflare
• Durable ObjectsNotificationsHub
• KV namespacesRATE_LIMIT_KV
• Queues (consumer)emailflare-inbox-sequences
• Queues (producer)emailflare-inbox-sequences
• R2 bucketsemailflare-inbox-attachments

Good to know

Receiving needs Email Routing enabled on a domain in the Cloudflare account. The runtime Cloudflare API token needs Zone, DNS and Email Routing permissions. The GitHub Actions workflow only updates Workers that the local setup already created.

Cost on Cloudflare

Where this comes from

• Repositoryhttps://github.com/0xdps/emailflare
• App websitehttps://emailflare.dev
• Documentationhttps://github.com/0xdps/emailflare/blob/trunk/docs/CLOUDFLARE.md

An alternative to Amazon SES, Brevo, Mailchimp Transactional Email, MailerSend, Mailgun, Mailjet, Mailtrap, Postmark, Resend, SendGrid.