Four Cloudflare services replace a conventional mail stack
Mailflare runs the inbox as a Cloudflare application. Email Routing delivers inbound messages, D1 stores mail records, R2 holds attachments, and a Durable Object pushes live updates to connected users. The dashboard adds personal and shared mailboxes, delegated access, folders, search, snoozing, automatic replies, contacts, webhooks, audit logs, and backups. For a domain already on Cloudflare, that is an attractive amount of mail infrastructure behind one deployment button.
The design also fixes the hosting choice. Mailflare expects the domain to be a Cloudflare zone and uses a runtime token to create routing and sending resources. Its complete Worker handles inbound email, queues, workflows, and the live-update hub. Moving the app to another edge platform would mean replacing those pieces, not changing a deployment adapter. Buyers should read it as a Cloudflare mail product whose source is visible, rather than a portable Next.js inbox.
Receiving can be free, while sending needs a $5 Worker plan
The README says Mailflare can be set up to receive email for free. Outgoing mail requires Cloudflare's Paid Worker plan, listed at $5 per month. That split is important for a trial: inbound routing and the interface may be cheap to explore, but a working business mailbox usually needs replies. Pricing can change outside the repository, so confirm the current Cloudflare plan before promising a cost to a team.
Sending is available through the dashboard and POST /api/v1/send. The documented API accepts text plus Base64 attachments, with up to 10 files, a 10 MB limit per file, and a 20 MB combined limit in the composer. Attachment metadata stays in D1 while file contents live in R2. Downloads follow mailbox permissions, and shared users receive live events for mailboxes they can access.
What happened when we ran it
Our unprivileged Debian sandbox installed commit d600403 in 30 seconds. Npm added 982 packages and the dependency tree occupied 1,083 MB, which is substantial for a web inbox before any user mail or attachments exist. The checkout itself contained 525 files, roughly 38,643 lines of source, and 39.8 MB. We found 1 CI workflow file, no Dockerfile, and no tests directory.
The build failed with exit code 1 after 12 seconds. next build started Next.js 16.2.6, then tried to establish a remote connection through Wrangler. It stopped with the message that remote mode requires a login and suggested either logging in or using wrangler dev --local. The log establishes an authentication requirement for that build path. It does not show a TypeScript, Next.js, or application-code compilation failure.
No test command or target exists in the package scripts, so our sandbox skipped testing. Npm audit reported 17 known vulnerabilities: 11 high severity, 4 moderate, 2 low, and 0 critical. An open pull request proposes dependency updates for those findings, but it was not part of commit d600403. The published review therefore uses the audit result from our own install, not the proposed branch's claimed outcome.
The source license blocks normal open-source reuse
Mailflare's LICENSE allows review, evaluation, modification, and personal or internal business deployment. It prohibits selling, sublicensing, commercializing, redistributing, publishing modified copies, and offering a similar hosted service without written permission. GitHub consequently reports no standard license identifier. A contributor even opened issue 12 to request permission for a public fork because the usual pull-request flow conflicted with clause 3.
This matters well before procurement. A company can deploy the application internally under the text as written, but a consultant cannot assume they may publish a maintained fork or turn a customized copy into a service. The deployment guide also mentions paid Pro or Team branding keys that activate through Paymug. Anyone planning white-label use, resale, or public redistribution should get written terms from the author first.
Three matching Worker names and several tokens sit behind one-click deploy
The deployment button provisions the Worker bindings, builds the OpenNext package, applies D1 migrations, and deploys the app. Runtime still needs CF_TOKEN with Zone Read plus email-routing and sending permissions. Backup support adds CF_AID, D1_DATABASE_ID, and an export-capable token. Turnstile keys, a Worker name, and optional GitHub update credentials appear in the package's Cloudflare binding declarations.
Renaming the Worker requires the same value in 3 places: the top-level Wrangler name, the self-reference service binding, and CF_EMAIL_WORKER_NAME. The first-run /setup route initializes an empty database but never applies later migrations to an existing one. Updates therefore need the remote migration command before deployment. Those are ordinary Cloudflare tasks for an experienced operator, yet they are more than a click and a domain name.
August activity is strong, while release and test discipline lag
GitHub recorded 2,123 stars, 228 forks, and 6 combined issues and pull requests. The last push was August 31, 2026, on the same day as our measured commit. Current discussion includes onboarding instructions, routing changes, webhook retries, dependency updates, and push notifications. That is active development and user interest. It also means behavior is moving quickly around a mail system that stores sensitive records.
There is no GitHub release marked latest, even though package.json identifies version 0.2.0. More concerning, the repository offers no automated test script for the 38,643-line codebase. Mailflare deserves a trial if the Cloudflare fit is exact and the license works for the organization. A production decision should wait for a repeatable authenticated build, a clean dependency audit, and tests around account permissions, routing, migrations, attachments, and message delivery.