OpenSend
OpenSend（opensend.cc）是「自托管的 Resend 替代品」：一个开源（Apache-2.0）的邮件 API，你跑在自己的服务器上、只付 AWS SES 费用，OpenSend 本身不收费。它提供 Resend 兼容的 REST API 与 SMTP（把现有 Resend SDK 的 base URL 指过来即可，应用代码几乎不动），以及 React 邮件模板、签名 webhooks、Contacts/Audiences/Broadcasts、作用域密钥、批量发送、幂等重试、测试模式密钥，底层基于 Next.js + 自托管 Convex + Better Auth + AWS SES（一条 Docker Compose 拉起）。你的域名、数据、账号与 SES 信誉都留在自己基础设施，并自动给出 DKIM/SPF/DMARC 配置、退信投诉自动进 suppression。Cloud 托管版处于候补（即将推出）。项目较新（GitHub 36 stars、由 Panara Studios 主导），优势是零成本自托管与近乎零改迁移，短板是早期生态单薄、需自运维、托管云尚未上线。
核心功能
- ✓ 工作流自动化
- ✓ 开源
- ✓ 本地部署
- ✓ 提供API
- ✓ 企业级安全
👍 优点
- + 零成本自托管、完全拥有技术栈：一条 Docker Compose（Next.js + 自托管 Convex + Better Auth + AWS SES）拉起，域名、数据、账号全在你的基础设施，只付 VPS 与 AWS SES，软件本身 $0 且 Apache-2.0 开源
- + 迁移几乎零改动：Resend 兼容的 REST API 与 SMTP，把现有 Resend SDK 的 base URL 指到你的实例即可，应用代码基本不动，告别按发送量计费与黑盒
- + 能力完整：作用域密钥、批量发送、幂等重试、React 邮件模板（仪表盘预览并按名发送）、签名 webhooks（送达/退信/投诉）、Contacts/Audiences/Broadcasts、测试模式密钥，覆盖事务邮件与产品播报
- + 交付与可送达性友好：自动展示 DKIM/SPF/DMARC 记录、退信投诉自动进 suppression、SES 信誉归你独享不与他人共享，比共用 IP 的托管更可控
- + 透明与可持续：开源、文档与自托管指南齐全、路线图由赞助方驱动并公开，单作者但定位清晰（做成自己想要的 Resend 替代品）
👎 缺点
- - 非常早期、生态单薄：GitHub 仅 36 stars、由 Panara Studios（Kamal Panara）单人主导，社区规模与长期维护确定性远不及 Resend/Postmark 等成熟服务
- - 自托管即自运维：你要管服务器、Convex、Better Auth、SES 配置、升级与备份；「一条命令」之后仍有运维与排障成本，对只想发邮件的团队是负担
- - 托管云版尚未上线：想「开箱即用」的人只能等 Cloud 候补（页面标注 $$ coming soon），现阶段没有官方托管的省心选项
- - 强依赖 AWS SES（或自备 SMTP）：送达率、限额、域名验证仍由你与 AWS 承担，OpenSend 不替你解决底层投递与信誉问题
- - 商业支持与 SLA 缺失：企业级保障（专属支持、合规审计、SLA）未成形， sponsors 优先修 issue 的模式对生产关键负载未必足够稳
适合人群
最适合： 想摆脱按发送量计费、不愿把邮件技术栈交给第三方黑盒的开发者与团队：已经或打算用 Resend、希望一条命令把 API 迁回自托管的；在意数据主权与成本可控、有自有服务器/VPS 与 AWS SES 账号、愿意自运维的人；做事务邮件（验证码、通知、收据）又想顺带发产品播报/简报（Broadcasts）的产品团队；喜欢开源、想读源码/自改/审计、且接受早期项目节奏的工程师；被 Resend 涨价或想独占 SES 信誉（不被邻居投诉连坐）的发送方。
不适合： 想要开箱即用、零运维的团队——OpenSend 当前需自托管（Docker Compose + SES 配置 + 升级备份），没有成熟托管的省心；只想要托管云的人——Cloud 版还在候补、未上线；没有自有服务器或 AWS SES 账号、不想碰基础设施的纯业务方；对长期维护确定性、SLA、商业支持有硬性要求的企业——项目仅 36 stars、单人主导、尚无企业级保障；发送量极大、对送达率与合规审计极度敏感、需要专业投递网络与专属支持的场景（应上 Postmark/SES 专业方案或商业托管）。
