Workers
API and processing
Authenticate mailbox calls, enforce scopes and quotas, parse inbound events, serve search and thread operations, and dispatch webhooks.
Infrastructure feature
Own the domain, mailbox data, and operating controls.
Deploy the mails0 API to your Cloudflare account when the hosted sandbox is no longer the right boundary for production work.
Direct answer
mails0 can be self-hosted with Cloudflare Workers for the API and processing, D1 for mailbox and message metadata, R2 for raw messages and attachments, and Email Routing for inbound delivery. You configure your own domain, secrets, outbound sender provider, quotas, retention, monitoring, and abuse controls.
Decision map
Separate compute, metadata, and raw message storage
- 01API and processing
Authenticate mailbox calls, enforce scopes and quotas, parse inbound events, serve search and thread operations, and dispatch webhooks.
- 02Mailbox metadata
Store identities, token state, message indexes, labels, thread references, delivery state, and bounded operational records.
- 03Raw messages and inbound delivery
Route mail from your domain into the Worker and preserve raw content or attachments outside general application telemetry.
Architecture
Separate compute, metadata, and raw message storage
The deployment uses Cloudflare primitives for distinct responsibilities so operators can inspect, scale, and retain each data class deliberately.
D1
Mailbox metadata
Store identities, token state, message indexes, labels, thread references, delivery state, and bounded operational records.
R2 + Routing
Raw messages and inbound delivery
Route mail from your domain into the Worker and preserve raw content or attachments outside general application telemetry.
Deployment sequence
Move from repository to a working inbound address
-
01
Create Cloudflare resources
Provision D1 and R2, configure the Worker bindings, and apply the current schema and migrations.
-
02
Configure secrets and sender
Store authentication, hashing, webhook, and outbound provider secrets with the platform rather than in source files.
-
03
Attach the domain
Configure Email Routing and DNS for the inbound subdomain, then verify the outbound domain with the selected sender provider.
-
04
Run a real inbound smoke test
Create a mailbox, send one message from an external service, confirm storage and retrieval, then exercise webhook or code extraction if required.
-
05
Set operational limits
Choose retention, send and claim quotas, alerting, abuse review, and credential rotation before onboarding production workflows.
Tradeoff
Self-hosting exchanges vendor convenience for control
Source access does not remove operational work. The team becomes responsible for DNS, domain reputation, outbound provider configuration, Cloudflare limits, migrations, observability, incident response, and user support.
That trade is valuable when mailbox data must remain in an owned account, an agent needs a company domain, or the team must inspect and change the infrastructure. It is unnecessary when a managed vendor already satisfies the workflow and ownership is not a requirement.
- Use a dedicated inbound subdomain to avoid disrupting existing human mail.
- Keep operator credentials separate from mailbox-scoped credentials.
- Test retries, duplicate webhooks, expired tokens, and provider outages.
- Document backup, migration, retention, and deletion procedures before production use.
Decision
Hosted sandbox or self-hosted deployment
| Decision point | Hosted sandbox | Self-hosted |
|---|---|---|
| First workflow proof | Fast temporary mailbox with abuse controls. | More setup than a first experiment needs. |
| Domain identity | Uses the hosted product domain. | Uses a domain or subdomain you control. |
| Data and retention | Operated under the hosted service boundary. | Defined in your Cloudflare resources and policies. |
| Outbound delivery | Subject to hosted capability and limits. | Configured with your verified sender provider. |
| Operations | Maintained by the hosted service. | Owned by your team, including incidents and upgrades. |
Evidence
Sources and product scope
Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.
- mails0 source repositoryImplementation, license, and deployment source
- mails0 self-hosting guideDeployment and resource setup
- Cloudflare Email Service documentationOfficial inbound routing documentation
Questions and answers
Questions about Cloudflare self-hosting
Can mails0 run entirely on the Cloudflare free tier?
Small workloads can fit within Cloudflare free-tier allowances, but actual cost depends on traffic, storage, email volume, sender provider, and current Cloudflare pricing. Verify current limits before production planning.
Does Cloudflare Email Routing send outbound mail?
No. Email Routing handles inbound routing. Configure an outbound sender provider and verify the sending domain for outbound delivery.
Can I use a subdomain instead of my root domain?
Yes, and a dedicated subdomain is usually safer because it avoids changing MX behavior for an existing human email system.
What does the team own after self-hosting?
The team owns deployment, secrets, migrations, DNS, sender configuration, data retention, monitoring, abuse response, backups, and upgrades.
Start with a bounded inbox
Give the agent an inbox, then prove the workflow.
Start with a receive-only temporary mailbox. Move to a permanent identity or self-hosted deployment only after the workflow reaches a real email value event.