Shared inboxes that know who replied.
Mailda turns an email address into governed work. Who is answering, whether anybody has, what a rule held back and why. It runs in your own Cloudflare account, so you own the domain, the messages, the keys and the bill. There is no Mailda service to depend on, no licence server, no telemetry. Disconnect us and nothing stops working.
For the owner Workers Paid is the one thing it needs: $5 a month, 3,000 emails included, then $0.35 per thousand. A twenty-person team sending ten thousand a month pays about $7.45. Inbound mail is unlimited. Not for newsletters; not for Outlook. Open source, Apache-2.0.
On-screen text. No voice; music only.
- Got a domain on Cloudflare?
- Mailda turns it into your own mail system.
- Mail to your domain arrives… and is kept in your own Cloudflare account… where your team reads and answers it together.
- From anyone → your Cloudflare account (Email Routing receives it, a Worker runs Mailda, D1 and R2 store it) → your team: read · assign · reply.
- Shared inboxes: assign mail, see who replied, and never answer the same message twice.
- Yours, even without us: your domain, messages and keys stay in your account. No Mailda account, no telemetry.
- One command to install: runs on Cloudflare’s Workers Paid plan, from $5 a month, paid to Cloudflare.
- This is the real app. Reply claims it, so nobody answers it twice. Every draft is saved on your Node.
- Install it in your own Cloudflare account: curl -fsSL https://mailda.site/install.sh | bash
- mailda.site · Functional alpha · open source, Apache-2.0
mailda doctor functional alpha what is built, what is thin, and the page that holds each claim to account
- ok install One command into your own Cloudflare account: it signs you in, deploys, claims the Node in the same terminal, and with that one sign-in sets up receiving, sending and delivery outcomes, so the Node receives when it ends. No dashboard, no API token, no OAuth client. Drilled on a clean account; a second Node in the same account is a name, and updating is one command too. deploy-drill-live-account.md
- ok receiving Shared inboxes with a queue: claim, hand over, close, a first-response clock per mailbox. Threads, labels, read state, archive and trash (restorable), search over subjects, senders and bodies. application-shell.md
- ok mail_security The receiving server's SPF/DKIM/DMARC verdict on every message; attachments judged by name and magic bytes; links judged against what they say and your own domains; quarantine and suppression, both per mailbox. No model. mail-security.md
- ok sending Every send is sealed to a manifest first, then held for fifteen seconds, then dispatched. Policies, approvals with two people, domain pauses, rate breakers, a suppression list the provider's own bounces build. send-breakers.md
- ok butlers Programs that act on mail: deterministic, refused at publication if they cannot afford to run, paused if they loop, released by a person before anything leaves. The llm.* node types are declared and refused. butler-engine.md
- ok your_ai A contract-generated SDK, an agent Skill and an MCP server, every one derived from the same route registry. Agents hold a pinned ceiling of capabilities and an org.admin can never be minted. machine-surfaces.md
- ok governance An audit trail nothing trims, matters, legal holds two people lift, supervised reads that leave a record, e-discovery exports approved before they run. supervised-access.md
- ok custody Evidence sealed under keys only your Node holds, escrowed to ten recovery codes; a backup you can verify offline; a restore drilled three times, once through to receiving mail. disaster-recovery.md
- warn a_restore_has A restore has worked three times, and once through to receiving mail. Three drills (#92): cross-account, then a real backup, then a same-account restore that took a domain, wrote its own routing, and accepted a message from outside. The catalog imports at about a thousand rows a second. README
- warn deployment_promotes_on Deployment promotes on its own, measured twice. mailda deploy does expand/contract with a canary and refuses to promote a version whose doctor is worse than the incumbent's (#98). The canary is reached by a version override on the production hostname, because preview URLs do not exist for a Worker with Durable Objects. README
- warn mail_security_is Mail security is thin. The receiving server's SPF, DKIM and DMARC verdict is stored; a DMARC failure is shown on the message and its row in the list, and the full verdict is one click away in the message's details. Attachments are judged by name and magic bytes, links by where they really go, and a mailbox can hold back… README
- warn english_and_simplified English and Simplified Chinese. The interface's words are a typed catalog per locale (ADR 46): a missing translation does not compile, and a check with the TypeScript checker counts every string not yet in the catalog, file by file, down to zero, which it is. Simplified Chinese (简体中文, the mark 淼达) is offered beside English since… README
- report receipts Every limit, cost and timing in the product has a receipt saying how it was measured and when it goes stale. The build refuses a constant without one. docs/receipts/
The warn rows are the README's own words. A vendor's page would leave them off. Read the whole status before you rely on any of this.
One command, one afternoon
curl -fsSL https://mailda.site/install.sh | bash It signs you in to Cloudflare, deploys into your account, claims the Node in the same terminal, asks which domain it should receive at, and with that same sign-in enables routing, onboards sending and subscribes delivery outcomes, reading each back and refusing if a record is not there. The Node receives when the command ends. No dashboard, no API token, no OAuth client. Open the Node: until it has an address and mail routed to it, it shows the next step and the command that does it, and only then the inbox. A hostname of your own is one more question, attached by the deploy. A credential of the Node's own, one API token pasted on Setup, is optional and only for changing that setup from the browser later. If you would rather arrange the account by hand, the dashboard path is written down too. Every setting it needs, in one page.
Later, in the same directory, curl -fsSL https://mailda.site/update.sh | bash pulls the release, backs the Node up, says what its schema will do, and redeploys through the canary. No git command is yours to type, including for a Node the deploy button made.
See it work
On-screen text. No voice; music only.
- Two people answer the same customer. Nobody can say whether invoices@ got a reply.
- Mailda: shared inboxes that know who replied. In your own Cloudflare account.
- One queue per mailbox. Who holds each conversation, and for how long. A first-response clock. Overdue says so.
- Somebody already answering it? Mailda names who, before you write a word. Take it anyway, and they’re told.
- Hand a conversation to a colleague. In their queue now, and the trail names you both.
- Reply from the shared address. Every send waits 15 seconds, so you can stop it.
- Who can read, send and decide, at a glance.
- Install it in your own Cloudflare account: curl -fsSL https://mailda.site/install.sh | bash
- mailda.site · Functional alpha · open source, Apache-2.0
On-screen text. No voice; music only.
- Butlers are small programs that act on your mail. They run on your Node, when mail arrives. No AI inside: the same mail gets the same result.
- How you set one up: write it, in the editor · save: it is checked · publish: version 1, frozen · give it a mailbox · mail arrives: it runs.
- 1 · Write it in the editor, in YAML or JSON. Make a mistake… 2 · Saving checks it: the step, the reason, the fix. 3 · Publish freezes it as version 1. 4 · Give it a mailbox. It never borrows your access.
- 5 · An invoice email arrives. It is stored before anything else happens. Filed, then one run starts. Never twice for one message. Each step checks the Butler’s own access. Every effect is recorded, and audited.
- The invoice is with Chen. The run says what it did, and what it was refused.
- A Butler can propose a reply. It waits, sealed, until a person releases it. A machine never sends on its own.
- Whose resources does it use? Yours: your Cloudflare account, your Workers plan. Each step has a ceiling price, in subrequests. A run may spend up to 10,000. A Butler that can’t afford a run is refused when you save it. No AI model is called, so no AI tokens.
- A loop pauses it: three runs it caused itself, within an hour. An administrator resumes it, and has to say why. Every version is frozen; every run is on the record.
- Install it in your own Cloudflare account: curl -fsSL https://mailda.site/install.sh | bash
- mailda.site · Functional alpha · open source, Apache-2.0
On-screen text. No voice; music only.
- Your app in your AI. Never AI in your app.
- How your software reaches it: an agent, your AI with a ceiling · the SDK, typed, from the contract · Skill and MCP, for AI tools · the CLI: run it, and use it.
- 1 · Mint an agent: who it acts for, what it may do. 2 · Which mailboxes. Never beyond the person it acts for. 3 · Its token is shown once. Keep it like a password.
- Your AI does the thinking, on your AI provider’s bill. It calls your Node with its token. Every call is checked against its ceiling and its sponsor, live. It can draft. Sealing a send is withheld from every machine. Every act is audited: the agent, and the person it acts for.
- The SDK: typed, generated from the contract. Every route is a method. A refusal is a MaildaError with its code. @mailda/sdk ships in the repository. It is not on npm yet.
- An Agent Skill, generated from the contract: what an agent may call, and why the rest is withheld. An MCP server on your Node, at /mcp. The same agent token, and only the tools it may use.
- The CLI runs the Node. Install, upgrade, check it, back it up, verify the backup. And uses it: every route, by the SDK’s names, with an agent token.
- Install it in your own Cloudflare account: curl -fsSL https://mailda.site/install.sh | bash
- mailda.site · Functional alpha · open source, Apache-2.0
On-screen text. No voice; music only.
- No Mailda service to depend on. No licence server. No telemetry. Disconnect us and nothing stops working.
- mailda install: one command, in your own account. Nothing changes before the deploy step. It receives mail when it ends.
- mailda upgrade: every step numbered. Keeps your own domain. Backs up only when a table changes.
- Doctor: problems first. What needs you leads. The long detail of what passed folds away.
- What it costs: $5 a month. Workers Paid: 3,000 emails included, then $0.35 per thousand. A twenty-person team sending ten thousand a month pays about $7.45. Inbound mail is unlimited. The bill is yours, paid to Cloudflare.
- Your keys, your backups: evidence sealed under keys only your Node holds. Escrowed to ten recovery codes. A backup you can verify offline. A restore drilled three times, once through to receiving mail.
- Install it in your own Cloudflare account: curl -fsSL https://mailda.site/install.sh | bash
- mailda.site · Functional alpha · open source, Apache-2.0
On-screen text. No voice; music only.
- Functional alpha · looking for design partners. Who approved that send? Who read that mailbox, and why? Mailda keeps the answer.
- A rule: outside mail from Support needs two sign-offs. The approver reads exactly what would leave. One approves. It still waits for the second.
- An audit trail nothing trims.
- Matters, and legal holds it takes two people to lift.
- Also in the box: supervised reads that leave a record. E-discovery exports approved before they run.
- Install it in your own Cloudflare account: curl -fsSL https://mailda.site/install.sh | bash
- mailda.site · Functional alpha · open source, Apache-2.0
- Intelligent. Your app in your AI, never AI in your app.
- Reliable. Every assertion can fail. Every number has a receipt.
- Flowing. Mail arrives, gets filed, gets answered, and leaves a record.
- Helpful. A refusal names the problem, the reason and the remedy.