One web inbox for every address already living inside your Cloudflare Worker.

Receive catch-all inbound mail, forward it into a personal inbox, and keep the full message trail in R2 without adding a separate auth or back office stack.

Operator loop

The workflow stays small because the boundaries are clear.

1. Receive routed support mail inside the Worker.
2. Partition it by the real receiving address in R2.
3. Forward a reply-enabled copy to the owner's personal inbox.
4. Open `/app`, review the thread, and reply from the web UI.
5. Protect access with email sign-in links and an HTTP-only cookie.

Cloudflare-native mail flow

Inbound mail lands through Email Routing, outbound replies go through Email Service, and the inbox stays in one Worker deploy.

R2-backed message history

Raw source, normalized payloads, and attachments stay in object storage so the current app can remain simple.

Email-based web access

Magic links sent to the configured forwarding address unlock the inbox with a short-lived sign-in flow and HTTP-only cookie.

Plain routes, clear responsibility

The product surface is intentionally small: public explanation, sign-in, private inbox, and a docs section that ships in the same app.

Public landing, locked app

`/` explains the product, `/login` handles email sign-in, and `/app` keeps the mailbox workflow behind the session.

No extra auth service

Configure magic-link auth in the Worker environment and keep the access model simple.

Existing inbox preserved

The current reply flow stays intact and still runs on the bindings already wired into the Worker.

Same deploy, same docs

Fumadocs and the operator UI now share the same neutral shadcn token layer, so the surfaces no longer fight.

Ready to test the inbox

Open the protected app or review the integration notes first.