Quickinbox: a self-hosted webmail client that runs entirely on Cloudflare Workers

The problem Quickinbox solves: mail on a domain you own, without running a mail server

Running mail for a personal domain normally means a VPS, Postfix or similar, TLS certificates, spam handling, and a webmail front end bolted on top. Quickinbox removes that stack. The README describes it as "Self-hosted email for your own domain, running on Cloudflare Workers", and the deployment target is a Worker rather than a machine you patch. Storage splits across two Cloudflare services: D1 holds the schema and mail records, and R2 holds inbound and outbound attachments.

The audience is narrow and specific. You need a domain you control, a Cloudflare account, and either a Resend account or the domain on Cloudflare DNS plus a Workers paid plan. That is not a hobbyist-with-nothing setup, but it is far less than a mail server. The payoff is a real address at your own domain with a full web client, plus a REST API, a CLI and an MCP server so scripts and AI agents can send and read mail. The README states the provider delivers straight into the Worker, so nothing is polled.

How mail actually flows through the Worker

The provider is chosen per deploy through the EMAIL_PROVIDER variable, with resend as the default and cloudflare as the alternative. The two tracks differ in where mail enters and leaves the system.

On the Resend track, outbound goes through the Resend API and inbound arrives as a webhook posted to /api/webhooks/resend. The Worker exposes that route, verifies the signing secret, and writes the message into D1, with any attached files going to R2. Delivery events such as delivered, bounced and complained come back over the same webhook channel, which is why the README lists email.received, email.sent, email.delivered, email.bounced, email.complained, email.delivery_delayed and email.failed as the events to subscribe to.

On the Cloudflare track, outbound uses env.EMAIL.send() and inbound is handled by the Worker's email() handler. That handler only runs on a deployed Worker or under bun run preview; the README is explicit that vite dev never runs it, so inbound testing during local development is not possible. Cloudflare accepts a send and records it as sent, so the finer delivery states that Resend reports are not available on that track. One provider is active per deploy, and the README warns against pointing the same domain's apex MX at both.

Installing Quickinbox and creating the first admin account

The README offers a Deploy to Cloudflare button or a local wizard. The wizard creates the D1 database and R2 bucket, writes config, and onboards your domain. The README budgets about 30 minutes, most of it waiting on DNS.

bun run setup
# if bun isn't installed yet:
bash scripts/setup.sh

If you deploy manually instead, install dependencies and authenticate Wrangler first. Cloudflare Email Sending requires Wrangler 4.123 or newer according to the README, because older versions hit a removed API path and return 404.

bun install          # or: npm install
bunx wrangler login

Then create the two backing resources and run the migrations. Copy the printed database_id into wrangler.jsonc in place of REPLACE_WITH_YOUR_D1_DATABASE_ID before migrating.

bunx wrangler d1 create quickmail
bunx wrangler r2 bucket create quickmail-attachments
bun run db:migrate:remote

On the Resend track, set the API key as a Worker secret, deploy, then create the webhook in the Resend dashboard pointing at https://<your-worker-url>/api/webhooks/resend. The signing secret is shown once, so save it and redeploy.

bunx wrangler secret put RESEND_API_KEY
bun run deploy
bunx wrangler secret put RESEND_WEBHOOK_SECRET
bun run deploy

On the Cloudflare track, enable sending and routing for the domain, then set the provider in wrangler.jsonc and deploy. The catch-all that routes inbound mail to the Worker is dashboard-only; the README states the CLI cannot set a Worker as the catch-all action.

"vars": {
  "EMAIL_PROVIDER": "cloudflare",
  "CLOUDFLARE_MAIL_DOMAINS": "yourdomain.com" // comma-separate multiple domains
}

First run is three steps: open the deployed URL, visit /setup, and pick a domain and create the admin account. That address is both the inbox and the login.

Where Quickinbox is the wrong tool

The strongest constraint is that the deployment is not portable. Quickinbox is a Worker with D1 and R2 behind it. Moving it means moving off Cloudflare, and the README's provider table makes the trade explicit: Resend works with any DNS host, while Cloudflare Email Service requires Cloudflare DNS. If your zone lives elsewhere and you will not move it, you are on the Resend track whether you like it or not.

The second constraint is that this is not a throwaway address service. Quickinbox is built for a permanent address on a domain you own, with per-user addresses, an admin catch-all and an unrouted-mail view. Someone looking for a disposable inbox that expires is solving a different problem, and the setup cost of roughly 30 minutes plus DNS propagation is disproportionate for that use.

The third is operational. The deploy script runs remote D1 migrations before every wrangler deploy, so a schema change ships with the code. The README documents one recovery path for a specific failure, an older deploy that left no such table: users, fixed by running npx wrangler d1 migrations apply DB --remote against that Worker. It does not document rollback, so treat migrations as forward-only in practice. There is also a known upgrade wrinkle: pulling updates changes the product name in the UI and docs but does not rename your Worker, D1 database or R2 bucket. The README says to leave those as they are, notes that existing qm_live_ API keys keep working, and that quickmail remains a CLI alias.

Quickinbox compared with running your own mail server

The obvious alternative is a conventional self-hosted stack: a VPS running a mail transfer agent, an IMAP server, and a separate webmail client, with DNS and certificates you manage yourself. The difference is where the operational burden sits. That stack gives you full control of the storage layer and the ability to move the whole thing to another host by copying data. Quickinbox gives up that portability in exchange for not running any of it: no server to patch, no TLS to renew, no IMAP to configure.

The second alternative is a managed mailbox provider. You get a working address in minutes and someone else handles deliverability, but you do not get the REST API, CLI and MCP surface, and you do not own the data path. Quickinbox's answer to that is the API and MCP server: the README describes pasting https://your-instance/mcp into Claude, Cursor or ChatGPT, approving access in the browser, and disconnecting apps from Settings. If agent access to your own mail is the point, a plain managed mailbox does not offer the same shape.

Licence, updates and what maintenance actually costs

Quickinbox is MIT licensed, and package.json carries "license": "MIT" with LICENSE.md at the repository root. That is permissive: you can use, modify and redistribute it, including in closed products, provided the licence text and copyright notice travel with it. It says nothing about the services the project depends on, and those carry their own terms. A Workers paid plan is required for the Cloudflare Email Service track, and the Resend track runs on the Resend free tier plus Cloudflare according to the README's table. Read both providers' terms before you point a business domain at either. None of this is legal advice.

The repository was last pushed on 2026-09-15, two days before writing, and it is not archived. The only release listed is v1.0.0 from 2026-07-29. Upgrading an existing install is the cheap part: pulling changes alters the product name in the UI and docs only, and the README states existing qm_live_ API keys keep working and quickmail remains a CLI alias. The expensive part is schema drift. Because deploy applies remote D1 migrations automatically, the practical upgrade question is not whether the code changes but whether a migration is safe to run against your live database. The README documents a fix for the no such table: users case and nothing about reversing a migration.

Editorial conclusion

Adopt Quickinbox if you control a domain, are comfortable with Wrangler and either Resend or Cloudflare Email Service, and want a web client plus API and CLI on the same Worker. Do not adopt it if you need a mail server you can move between hosts, if you cannot use Cloudflare DNS, or if you want a disposable address rather than a permanent one on your own domain. Before committing, verify that Wrangler is at 4.123 or newer, that your D1 database_id is in wrangler.jsonc, and that the apex MX record is in place, because the README states mail never arrives without it.

Frequently asked questions

Official sources

1. DivinPrince/quickinbox on GitHub
2. License: MIT
3. Project website
4. README
5. Releases