Cloud Mail: A Cloudflare-Native Email Server with Workers, D1, and R2

What Cloud Mail Actually Solves

Cloud Mail addresses the cost and complexity of running a personal or small-scale email service. Traditional email servers require a VPS, mail transfer agent configuration, DNS records, and ongoing maintenance. Cloud Mail instead runs on Cloudflare Workers, which are serverless functions that scale to zero when idle. The README states that you only need a domain to create multiple mailboxes, similar to major email platforms. This makes it attractive for individuals or small teams who want their own email addresses without paying for dedicated server infrastructure. The target user is someone already comfortable with Cloudflare's ecosystem, not a sysadmin looking for a full-featured groupware suite. It is a webmail interface plus an API, not a replacement for Outlook or Gmail in a large organization.

Architecture: Workers, Hono, Drizzle, and the Data Layer

Cloud Mail is a monorepo with a single worker backend called mail-worker. The backend is built on Hono, a lightweight web framework for Workers, and uses Drizzle as the ORM to interact with Cloudflare D1, a serverless SQLite database. The directory structure shows a layered design: API routes, data access objects, email processing, security, and services. This separation suggests a maintainable codebase, but the README does not provide a data flow diagram. Based on the folder names, incoming email goes through the email handler, which likely parses the message, stores it in D1, saves attachments to R2, and optionally forwards to a Telegram bot or another email address. The API layer exposes endpoints for user management and mail queries, and the security module handles authentication and RBAC.

Getting It Running: Commands and Configuration

The README does not include explicit installation commands, which is a notable omission for a deployment-focused project. It links to a separate deployment document at doc.skymail.ink, which likely contains the wrangler commands. Based on the repository structure, you would need to clone the repo, install dependencies for the mail-worker directory, and configure wrangler.toml with your Cloudflare account details. You would also need to create D1, KV, and R2 resources using wrangler commands like `wrangler d1 create cloud-mail-db`, `wrangler kv namespace create`, and `wrangler r2 bucket create cloud-mail-attachments`. Then you would run migrations with Drizzle, possibly using `drizzle-kit push` to sync the schema to D1. The README mentions an init folder for database and cache initialization, so there is likely a setup script.

Limitations and Failure Modes

The most obvious limitation is the dependency on Resend for sending email. If Resend has an outage or changes its pricing, your outbound mail is affected. The README does not mention a fallback SMTP provider, so you cannot send email without Resend. This is a single point of failure. For a self-hosted service, that is a significant trade-off. You are not truly self-sufficient; you rely on a third-party API for a core function.

Alternatives: Traditional Mail Servers and Other Cloudflare Projects

The most direct alternative is a traditional self-hosted mail server like Mail-in-a-Box or Mailcow. These projects provide a full email stack with SMTP, IMAP, webmail, and administrative tools. They run on a VPS and give you complete control over sending and receiving. The key difference is that Mail-in-a-Box uses Postfix and Dovecot, which are proven open-source components, and it does not rely on third-party APIs for sending. The trade-off is higher resource usage, a static IP requirement, and more maintenance. Mail-in-a-Box also has a web-based setup wizard, which is simpler than Cloud Mail's wrangler-based deployment. If you need IMAP support or want to avoid external dependencies, Mail-in-a-Box is a better fit.

Maintenance, License, and Upgrade Considerations

The project is licensed under MIT, which is permissive and allows commercial use, modification, and redistribution. There are no copyleft restrictions, so you can integrate it into proprietary software. The README does not mention any contributor guidelines or governance structure, so maintenance is likely driven by the core team. The repository is not archived, and the last push is recent as of the provided date, indicating active development. However, the README does not include a changelog or a migration guide for upgrades. With releases v3.0.0, v3.1.0, and v3.2.0, there are likely breaking changes between major versions. You should check the release notes on GitHub before upgrading.

Editorial conclusion

Cloud Mail suits developers already invested in Cloudflare who want a low-cost, self-hosted mailbox with a web UI and API access. It is not for teams needing on-premises control or avoiding third-party email sending via Resend. Before adopting, verify your Cloudflare plan's limits for Workers, D1, R2, and KV, and confirm that Resend's service covers your sending volume. Also, review the deployment docs at doc.skymail.ink for the exact wrangler commands and bindings, as the README omits them. If you need a more traditional SMTP server or a standalone mail stack, look elsewhere; Cloud Mail is inseparable from the Cloudflare platform.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes