核心问题: 你的邮件体系能否完全跑在 Cloudflare 上?不可商用的源码可用许可证是否与你的使用方式兼容?
RepoDaily 采用评分
RepoDaily 将该项目的采用分评为 89/100（强）：分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。
包含 4 个来源、覆盖 4 类来源；如有 RepoDaily 独有模块，会进一步提高证据分。
检测到 7 个工作流步骤、5 个下一步动作，以及 3 个命令/安装信号。
趋势热度为 +450 stars；如内容中有 release、issue 或维护信号，会提高维护可信度。
采纳风险标记为 medium，并包含 6 条安全说明与 4 条跳过条件。
3 个机会视角、5 个替代方案，以及 5 个类型化模块支撑差异化判断。
文章中包含许可证来源或许可证表述。
文章正文和元数据中检测到 2 个 AI/Agent 相关信号。
项目概览
根据 package.json,Mailflare 当前版本为 0.2.0,是一个完全运行在 Cloudflare 上的自定义域名自托管邮箱。README 的定位是'为专业人士与团队打造的专业邮件',功能清单也确实对得上:支持带委托访问的个人与共享邮箱、带附件和富文本格式的收发信、签名与自动回复,以及搜索、自定义文件夹、星标、稍后处理、归档、垃圾箱与回收站;还有可对来信执行存储、转发、拒绝或分类的路由规则、实时收件箱更新与新邮件通知、邮件导入导出、联系人管理和屏蔽发件人,外加覆盖账号、权限、API 密钥、Webhook、审计日志与数据库备份的管理层。
架构上它是一个为 Cloudflare 编译的 Next.js 应用:package.json 的 deploy 脚本先执行 `opennextjs-cloudflare build`,再以 `OPEN_NEXT_DEPLOY=true wrangler deploy` 发布。数据层用 drizzle-orm 0.45.2 操作 Cloudflare D1,迁移通过 `wrangler d1 migrations apply DB` 应用。界面栈包含 Radix UI 组件、TanStack Query 5.x、dayjs 与 lucide-react;mimetext 3.0.28 负责构造 MIME 邮件,依赖列表中还有 bcryptjs 3.0.3。来信经 Cloudflare Email Routing 投递,发信走 Cloudflare 的邮件服务,邮件正文存进你自己的 D1 数据库,附件放在你自己的 R2 存储桶。
成本结构异常简单:应用部署后收信免费;发信需要每月 5 美元的 Paid Worker 计划,README 还建议开启它以获得'顺畅体验'。源材料中没有任何按席位收费的项目——唯一的固定开销就是这个 Worker 计划。
最大的注意点是许可证。Mailflare 采用 Mailflare Source-Available License(版权 2026,Hieu Nguyen),允许'个人或内部业务用途'下的访问、阅读、运行与修改,但明确禁止销售、转授权,禁止将其或衍生版本作为托管服务、SaaS 产品、模板或 starter kit 提供,禁止再分发或镜像副本,禁止为转售或竞争性商业用途 fork,也禁止移除版权与署名信息。一句话:自己或公司内部使用没问题,不要在它上面做产品。
为什么现在变热
- 趋势窗口内获得 450 颗星、2026-09-01 当天排名第 16——对一个 0.2.0 版本的应用来说关注度上升很快
- 功能广度接近商业邮件产品:带委托访问的共享邮箱、可存储/转发/拒绝/分类的路由规则、API 密钥、Webhook、审计日志与自动 D1 备份
- 数据所有权卖点:邮件在你自己的 D1 数据库、附件在你自己的 R2 存储桶,整个应用都跑在你的 Cloudflare 账号里
- 收信免费;每月 5 美元的 Paid Worker 计划解锁发信
- README 里的 Deploy to Cloudflare 一键部署按钮,替代了传统自建邮件服务器的 VPS、TLS 证书与 IP 信誉维护
解决什么问题
- 自定义域名邮件通常意味着按席位付费的 SaaS(如 Google Workspace、Microsoft 365、Zoho Mail),邮件数据和管理能力都掌握在厂商手里
- 用 Postfix/Dovecot 或 Mailcow 这类套件自建,需要维护服务器和证书,并为送达率守护 IP 信誉
- support@、billing@ 这类共享地址需要额外的别名配置或更多席位授权
- 权限、审计日志、备份和 API 访问在 SaaS 里通常被限制在商业版套餐
- Mailflare 把前置条件压缩成 README 里的三项:一个 Cloudflare 账号、一个托管在 Cloudflare 的域名、一个 Cloudflare API 令牌
工作原理
- 创建一个具备 Zone Read、Email Routing Edit、Email Sending Edit 和 Email Routing Rules Write 权限的 Cloudflare API 令牌,并限定到要接入的 zone(见 package.json 中 CF_TOKEN 绑定说明)。
- 点击 README 中的 Deploy to Cloudflare 按钮,Worker 即部署进你的 Cloudflare 账号。
- 打开你的 Mailflare 地址完成首次运行设置:它会检查 Cloudflare 配置、创建初始账号,并引导接入第一个域名。
- 来信由 Cloudflare Email Routing 投递给应用;CF_EMAIL_WORKER_NAME 必须与已部署的 Worker 名称一致。
- 发信走 Cloudflare 的邮件服务,需要每月 5 美元的 Paid Worker 计划。
- 邮件正文存入你自己的 D1 数据库,附件存入你自己的 R2 存储桶。
- 管理层负责账号、权限、API 密钥、Webhook、审计日志与数据库备份;自动 D1 备份依赖 CF_AID、D1_DATABASE_ID 和可选的 D1_BACKUP_TOKEN 密钥。
架构解读:跑在 Workers 上的 Next.js,加 D1 与 R2
部署链路非常具体:`npm run deploy` 先执行 `opennextjs-cloudflare build`,再执行 `deploy:worker`,即 `OPEN_NEXT_DEPLOY=true wrangler deploy`。这个 Next.js 应用通过 OpenNext for Cloudflare(@opennextjs/cloudflare ^1.19.9)编译,由 Wrangler 发布。数据层由 drizzle-orm ^0.45.2 操作 D1, schema 变更用 `drizzle-kit generate` 生成,再以 `wrangler d1 migrations apply DB` 的本地与远程两个变体应用。
前端使用 Radix UI 组件(dialog、dropdown-menu、select、tabs、toast)、Tanstack Query ^5.100.11、class-variance-authority、clsx、dayjs ^1.11.20 和 lucide-react;mimetext ^3.0.28 处理 MIME 邮件构造,依赖列表中还有 bcryptjs ^3.0.3。值得注意的是,CF_TOKEN 绑定说明确认应用本身会在接入过程中调用 Cloudflare 的 Zones 与 Email Routing API——这正是仪表盘能替你配置邮件路由的原因。
部署须知:前置条件、成本与令牌
- README 前置条件:一个 Cloudflare 账号、一个托管在 Cloudflare 的域名、一个可供应用配置邮件路由的 Cloudflare API 令牌
- 收信免费;发信需要每月 5 美元的 Paid Worker 计划,README 也建议开启以获得顺畅体验
- CF_TOKEN 需与 Cloudflare 的部署/构建令牌分开创建,且只授予 Zone Read、Email Routing Edit、Email Sending Edit 和 Email Routing Rules Write,限定到要接入的 zone
- TURNSTILE_SECRET_KEY 与 NEXT_PUBLIC_TURNSTILE_SITE_KEY 配对,用于登录与首次运行注册的人机验证
- CF_EMAIL_WORKER_NAME 必须等于已部署的 Worker 名称;改了 Worker 名就要同步改这个绑定
- docs/deployment.md 覆盖所需权限、手动部署、备份、更新与自定义 Worker 名称;docs/api.md 与 docs/troubleshooting.md 补齐文档
试用路径:四条命令跑起本地开发
- `cp .dev.vars.example .dev.vars`,再把 Cloudflare 凭据写入 `.dev.vars`
- `npm install`,然后 `npm run db:migrate:local`(实际执行 `wrangler d1 migrations apply DB --local`)
- `npm run dev`,打开 http://localhost:3000
- 可选示例数据:开发服务器运行时执行 `npm run db:seed`——该脚本就是 `curl -X POST http://localhost:3000/api/seed`
- `npm run preview` 通过 opennextjs-cloudflare 构建并预览,可在正式部署前体验接近 Cloudflare 的运行环境
维护风险:0.2.0 版本与限制性许可证
package.json 标注版本 0.2.0 且 `private: true`——对一个已经内置审计日志、API 密钥、Webhook 和自动备份的软件来说,版本号相当早期。更新由管理端的更新接口触发:它用 GITHUB_UPDATE_TOKEN 在 GitHub Actions 中触发 update.yml,这个细粒度 GitHub 令牌需要在你的安装仓库上具备 Actions: write 和 Contents: write/read 权限(GITHUB_UPDATE_REPO 指向与 Worker 关联的仓库,GITHUB_UPDATE_REF 可选分支)。也就是说,自更新要经过你自己那份仓库,并依赖一个权限不小的存储令牌。
许可证决定了其余一切。Mailflare Source-Available License 仅允许个人与内部业务使用:不得销售或转授权,不得作为托管服务、SaaS、模板或 starter kit 提供,不得再分发或镜像,不得为转售或竞争性商业用途 fork,版权与署名信息必须保留。仓库列表没有 topics 和 homepage,package.json 指向 'SEE LICENSE IN LICENSE'。请按仅限内部部署来做规划。
集成面:哪些东西会接入 Mailflare
- API 密钥与 Webhook 是一等公民管理功能,详见 docs/api.md
- 邮件导入导出与联系人管理为内置功能(见 README)
- 审计日志记录操作;D1 备份基于 CF_AID 和 D1_DATABASE_ID 运行,D1_BACKUP_TOKEN 需以密钥形式存储(缺省时备份复用 CF_TOKEN)
- 旧部署仍可用 CF_EMAIL 加 CF_API_KEY(Global API Key)认证,但 package.json 建议新部署使用 CF_TOKEN
谁适合关注
适合关注
- 想在自己域名上收发邮件、但不想维护邮件服务器的自由职业者与专业人士
- 需要带委托访问的共享邮箱(如 support@、billing@)、而不是继续增加席位授权的小团队
- 明确希望邮件数据留在自己 D1 数据库和 R2 存储桶里的 Cloudflare 用户
- 许可证明确允许的内部业务部署,包括自行修改
可以先跳过
- 打算转售、换皮、镜像或将 Mailflare(或其衍生版)作为服务托管的人——许可证全部禁止
- 无法接受 Cloudflare 锁定的团队;Email Routing、Workers、D1、R2 就是全部架构,源材料中没有其他运行时方案
- 需要独立 IP 或高级送达率工具的发信方;出站邮件走 Cloudflare 邮件服务,基于每月 5 美元的 Worker 计划
- 采购政策要求 OSI 开源许可证的组织——'SEE LICENSE IN LICENSE' 意味着源码可用,而非 OSI 许可证
风险与注意事项
对 0.2.0 版本而言管理功能面很宽,但许可证禁止商业再分发与托管化,所有数据通路都依赖同一个 Cloudflare 账号,自更新还要依赖一个具备写权限的 GitHub 令牌。
- Mailflare Source-Available License 禁止销售、转授权、SaaS 托管、再分发以及以竞争性商业用途为目的的 fork
- 版本 0.2.0 加上 `private: true`,说明成熟度尚早,尽管功能面很宽
- 技术栈仅限 Cloudflare:Email Routing、Workers、D1、R2,源材料中没有可移植的部署路径
- 发信需要每月 5 美元的 Paid Worker 计划;只有收信免费
- 自更新依赖 GITHUB_UPDATE_TOKEN,需要在安装仓库上具备 Actions: write 与 Contents: write/read 权限
- 完全运行在你自己的 Cloudflare 账号里:邮件数据在你自己的 D1、附件在你自己的 R2——作者不托管任何数据
- CF_TOKEN 指引要求创建独立令牌,只授予 Zone Read、Email Routing Edit、Email Sending Edit 和 Email Routing Rules Write,并与 Cloudflare 的部署/构建令牌分开
- 登录与首次运行注册由 Cloudflare Turnstile 把关(TURNSTILE_SECRET_KEY 与 NEXT_PUBLIC_TURNSTILE_SITE_KEY 配对)
- 依赖列表中包含 bcryptjs ^3.0.3,用于凭据处理
- 审计日志与自动 D1 备份(CF_AID、D1_DATABASE_ID、可选 D1_BACKUP_TOKEN 密钥)为 README 所列内置能力
- D1_BACKUP_TOKEN 应以密钥形式存储;缺省时备份复用 CF_TOKEN
替代方案比较
| 方案 | 适用场景 | 代价 |
|---|---|---|
Mailcow | 想要一个不依赖任何云厂商、基于 Postfix/Dovecot 并用 Docker 跑在自己 VPS 上的完整自托管邮件套件 | 免费开源;服务器费用自理 |
Stalwart | 想要一个自己运行、协议控制权完整的 Rust 一体化邮件服务器(JMAP/IMAP/SMTP) | 免费开源;服务器费用自理 |
Mailu | 想要一个基于 Docker、带 Web 界面、不依赖 Cloudflare 的自托管邮件服务器 | 免费开源;服务器费用自理 |
仅用 Cloudflare Email Routing | 只需要自定义域名地址的转发,并在现有个人邮箱里阅读 | 转发免费;发信需自行解决 |
Zoho Mail / Google Workspace | 想要按席位付费、零运维的托管商业套件 | 按用户按月订阅 |
这个趋势说明了什么
没有邮件服务器的无服务器自托管邮件
Mailflare 用 Cloudflare 原语替换了 VPS 加 Postfix 的模式:入站走 Email Routing、应用跑 Workers、邮件存 D1、附件放 R2。悬而未决的是真实发信量下的送达率与配额表现,源材料并未覆盖。
用一个测试域名部署,与 Gmail、Outlook 收件人互发邮件,连续一周观察审计日志和 D1 存储增长。
通常只属于商业版的管理面
带委托访问的共享邮箱、API 密钥、Webhook、审计日志和自动 D1 备份都在 README 功能清单里——这些能力在 SaaS 中通常打包进商业版套餐。
首次运行设置完成后,创建第二个账号、委托一个共享邮箱、签发一个 API 密钥,并导出一次 D1 备份。
内部部署是被许可的用法
许可证明确允许内部业务使用与修改、同时禁止商业化,这把 Mailflare 定位给那些想要自己的邮箱、且永远不会再分发它的公司。
在正式域名上线前,请法务对照 Mailflare Source-Available License 审阅你的使用场景。
RepoDaily 判断
Mailflare 是无服务器自托管邮件的一个可信方案:真实的收件箱、共享邮箱、路由规则和管理工具,全部跑在你自己的 Cloudflare 账号里,邮件存 D1、附件存 R2。0.2.0 的版本号、仅限 Cloudflare 的架构,以及禁止商业复用的源码可用许可证,把它牢牢限定在个人与内部部署场景——而每月 5 美元的发信成本,正是许多小团队愿意接受的交换。