Security & trust
Tinbox runs entirely inside your own Cloudflare account — there is no Tinbox server in the path of your mail. The things worth protecting (your keys, your message bodies, your archive) live only where you control them. Every call that can leave your account is enumerated below, and each one has a switch.
The posture
Most of what follows isn’t a policy you have to trust us to uphold; it’s a consequence of where the code runs and how it’s wired — entirely inside your own account.
There is no Tinbox server between you and your inbox. Sending credentials, message bodies, and secrets live only in your Cloudflare account; nothing is cached upstream, nothing is proxied through us. There’s nothing on our side to breach, and nothing for us to be subpoenaed for.
Inbound rides Cloudflare Email Routing; outbound goes through Cloudflare Email Sending with SPF, DKIM, and DMARC on your own zone, the same authenticated path the big providers use. One-click unsubscribe and List-Unsubscribe headers ship by default, and a suppression list honors bounces and complaints.
Agents act through scoped, revocable capability tokens, never a master key. Every action, human or machine, passes the same authorize() gate. A read-only token literally cannot send: the capability isn’t there to grant. Reversible work flows freely; irreversible actions need a granted capability or a human-merged PR.
The send ledger records every dispatch before it happens, and an append-only message_audit trail tracks what each rule did. Turn on the optional git archive and every message also becomes a blameable, timestamped, grep-able file — replies and newsletters authored as files and reviewed as pull requests, so the merge log is the approval trail.
Your mail lives in your own Cloudflare account — a database and object store you control — under your terms and your jurisdiction, not in a vendor’s multi-tenant database. You are the data controller; there’s no processor sitting in the middle of your correspondence. Export the database, pull the raw attachments, or git clone the optional archive.
Nothing installs itself. Updates ship as new package versions; you npm update tinbox and re-deploy when you choose. Your mail never leaves your account, and exactly three calls can ever reach us — each one listed, each one switchable. One: a best-effort version check that reads a public version number, no identifiers; disable it with TINBOX_NO_UPDATE_CHECK=1. Two: when you report a message as spam, a copy of that message — sender, subject, headers, body, and links, with recipient addresses reduced to domains — goes to our shared classifier. That one starts on, and it is a checkbox in Settings → Security. Three: fleet diagnostics — bounded, redacted crash reports at aggregate or detailed. That one is off by default, consented on its own in Settings → Observability, and an upgrade never turns it on.
The core ships as a minified build, not a public source tree. Public repositories for anything touching email, credentials, and inboxes get scraped and scanned for exploitable patterns the moment code lands; keeping the core unpublished means an attacker works from the build, not an annotated map, raising the cost of finding and weaponizing a flaw. This is defense in depth, not security by obscurity, it sits on top of the controls above, never instead of them. License holders still receive the full source to audit, so the people running Tinbox can verify it.
Want the exact primitives and where everything lives? See the full architecture →
Questions
You’re not running a mail server on a VPS. Inbound rides Cloudflare Email Routing; outbound goes through Cloudflare Email Sending with SPF, DKIM, and DMARC set up on your own zone, the same authenticated, aligned path the major providers use. The deploy step walks you through the DNS records so alignment is correct from day one.
Your keys never do — sending credentials and secrets live only in your Cloudflare account, are never cached or proxied upstream, and no setting can send them. There is no Tinbox server in the path of your mail: we never see the messages flowing through your deployment. Two narrow exceptions involve a message, and both are switchable. First, when someone in your deployment clicks report spam, a copy of that message goes to our shared classifier (recipient addresses reduced to domains); that starts on, and it's a checkbox in Settings → Security. Second, fleet diagnostics can send us redacted crash reports — never mail content, subjects, or addresses — and that is off by default with its own consent in Settings → Observability. Separately, the optional version check reads a public version number and carries no identifiers; switch it off with TINBOX_NO_UPDATE_CHECK=1.
The CLI, the MCP endpoint, and the in-app assistant share one typed tool manifest and pass the same authorize() check as a human. Reversible work (search, draft, annotate) flows freely. Anything irreversible, like sending to many recipients or changing routing, needs a granted capability token or a human-merged PR. A read-only token can’t send because the capability simply isn’t in it.
Tinbox runs entirely in your own account, so you control the stack end to end. Please report security issues privately: open a GitHub security advisory on the repository, or if you can’t, file it through GitHub Issues and we’ll move it to a private channel. We’d rather hear about it from you than read about it elsewhere.
The whole engine, the workers, the auth, and the deploy script run on your own account, where your keys and mail stay yours. Deploy it in two commands.