Workers
Request and message processing
Serve authenticated APIs, process inbound mail, enforce token scope, schedule cleanup, and dispatch events.
Built for Cloudflare developers
Build agent email with the Cloudflare primitives you already operate.
Keep the API at the edge, metadata in D1, raw mail in R2, and inbound delivery on Email Routing while retaining a portable agent-facing interface.
Direct answer
Cloudflare developers can deploy mails0 as a Worker-backed email API using D1, R2, and Email Routing. The project supplies mailbox, authentication, search, extraction, webhook, and agent-tool behavior, while the operator supplies the account, domain, secrets, sender provider, quotas, and production runbooks.
Decision map
Each Cloudflare service has one clear responsibility
- 01Request and message processing
Serve authenticated APIs, process inbound mail, enforce token scope, schedule cleanup, and dispatch events.
- 02Queryable application state
Store mailbox identities, token status, message metadata, labels, thread references, quotas, and event records.
- 03Raw and binary payloads
Keep raw MIME and attachments outside the relational index so retrieval can be explicit and storage policy can differ.
Primitive mapping
Each Cloudflare service has one clear responsibility
D1
Queryable application state
Store mailbox identities, token status, message metadata, labels, thread references, quotas, and event records.
R2
Raw and binary payloads
Keep raw MIME and attachments outside the relational index so retrieval can be explicit and storage policy can differ.
Deployment
Build a production path in controlled stages
-
01
Run the Worker locally
Inspect routes, bindings, and environment variables before connecting real email or production resources.
-
02
Provision and migrate state
Create D1 and R2, apply schema compatibility checks, and verify the expected tables and columns.
-
03
Attach inbound routing
Use a dedicated subdomain and route messages to the deployed Worker without replacing unrelated MX records.
-
04
Configure outbound separately
Verify a sender domain with the selected provider and keep its API key in Cloudflare secrets.
-
05
Observe and constrain
Set quotas, fail-closed authentication behavior, cleanup schedules, alerts, and redacted operational metrics.
Operational detail
The hard parts are state transitions and provider boundaries
A successful Worker deploy does not prove that DNS routes inbound mail, that the sender provider accepts outbound mail, or that a webhook reaches its consumer. Test and report each layer separately.
D1 migrations also need compatibility checks because production schemas can lag source. Retention jobs should remove expired provisional credentials and short-lived claim data without deleting durable mailbox history unexpectedly.
- Verify Worker health before sending real mail.
- Test inbound routing from an external sender.
- Track provider acceptance and final delivery as different states.
- Run read-only schema checks before applying migrations.
- Keep raw message data out of generic request logs.
Architecture fit
When the Cloudflare architecture is a good match
| Requirement | Fit | Reason |
|---|---|---|
| Edge API and low-ops serverless runtime | Strong fit | Workers provide global request handling and scheduled tasks. |
| Queryable mailbox metadata | Strong fit | D1 supports relational state close to the Worker. |
| Raw MIME and attachment retention | Strong fit | R2 separates large objects from metadata. |
| Existing root-domain mail provider | Use a subdomain | Dedicated MX avoids disrupting human email. |
| Fully managed deliverability and support | Managed vendor may fit better | Self-hosting leaves provider and operational ownership with the team. |
Implementation judgment
Deploy the smallest production-shaped path first
Use a dedicated subdomain, one inbound route, one mailbox, and an external test message before enabling broader address creation or outbound mail. This sequence verifies the real DNS and storage path while keeping rollback simple. Add quotas, retention, sender configuration, and monitoring as explicit stages with owners.
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
- Cloudflare Email Service docsInbound email routing and Email Workers
- mails0 self-hosting guideRepository-specific deployment path
Questions and answers
Questions that come up in practice
Does mails0 require Cloudflare?
The maintained self-hosting architecture is designed for Cloudflare Workers, D1, R2, and Email Routing. Forking to another stack is possible under MIT but is not the documented deployment path.
Can Email Routing deliver directly to a Worker?
Yes. Cloudflare Email Routing supports routing matching inbound messages to an Email Worker for processing.
Where should outbound provider secrets live?
Store them as Cloudflare Worker secrets and keep them out of wrangler configuration files, source control, build output, and logs.
Should I point my root-domain MX at mails0?
Usually not when the domain already serves human mail. Use a dedicated subdomain unless you deliberately intend to replace the existing mail path.
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.