Skip to content
Tinbox
Sign in

announcements

Introducing Tinbox: your whole email stack on your own Cloudflare account

June 18, 2026

#tinbox#cloudflare#self-hosting#email#launch
Introducing Tinbox: your whole email stack on your own Cloudflare account
Visual: Desk Cartography on okslop

Your email lives in three different SaaS dashboards, none of which you control. Tinbox puts the whole thing (sending, newsletters, and your human inbox) on infrastructure you actually own.

Here's a pattern you've probably lived through. You start a project. You wire up Resend for transactional email because the DX is genuinely great. You add Mailchimp (or Loops, or Customer.io) for the newsletter. And your team reads support mail in Gmail, because where else would it go?

Three vendors. Three billing relationships. Three copies of your customer list, sitting in three databases you don't control, each metered on a different axis: per email, per contact, per seat. None of them talk to each other. And the moment you cross a volume threshold, the line items start to hurt. (We counted up exactly which subscriptions one owned stack swallows in the SaaS tools you can replace with one email stack.)

Tinbox is a bet that this is backwards. Your email is some of the most sensitive, most valuable data your company has. It shouldn't live in someone else's database. And in 2026, with Cloudflare's edge primitives mature and cheap, it doesn't have to.

What Tinbox is

Tinbox is a self-contained email stack that deploys onto your own Cloudflare account. One command:

npx tinbox init yourdomain.com

That scaffolds a Worker-based application, provisions the Cloudflare resources it needs, and hands you a running email system bound to your domain. No Tinbox-hosted control plane sits in the middle. There's no "Tinbox account" holding your data hostage. The data plane is yours. We never see your mail.

Under the hood it's Cloudflare-native all the way down:

  • D1 (SQLite) stores messages, contacts, and metadata. Your inbox is a SQLite database you can query.
  • R2 holds attachments and raw MIME blobs: object storage with zero egress fees.
  • Queues drive async work: delivery retries, importer batches, interpreter runs.
  • Workers are the compute. Receiving, sending, the API, the inbox UI: all of it runs at the edge, in your account.

If you already run on Cloudflare, Tinbox slots into infrastructure you're already paying for (often within the free tier). If you don't, it's the cheapest reason you'll find to start.

What's in the box

Tinbox isn't a thin wrapper around one feature. It's three products that historically lived in three companies, fused into one stack because they share the same data.

A transactional sender (your Resend replacement)

Send email from your Worker in a few lines. Tinbox handles the part that bites everyone who tries to deliver mail directly from Cloudflare: Workers cannot open outbound port 25 to recipient MX servers. Tinbox uses the native binding or an HTTPS delivery path, with authorization, DKIM signing, SPF alignment, and bounce handling built in.

import { tinbox } from "tinbox/cf";

export default {
  async fetch(req, env) {
    await tinbox(env).send({
      to: "user@example.com",
      from: "hello@yourdomain.com",
      subject: "Welcome aboard",
      html: "<p>Thanks for signing up.</p>",
    });
    return new Response("sent");
  },
};

We go deep on the SMTP problem (and why this matters) in cloudflare-workers-send-email.

A newsletter & marketing tool (your Mailchimp replacement)

The same contact list that receives your transactional mail powers your broadcasts. Segments, campaigns, open/click tracking, unsubscribe handling, all without exporting your audience to a second vendor or paying per-contact pricing that punishes you for growing your list.

A human inbox (your Gmail replacement)

This is the part people don't expect. Tinbox includes a real webmail client, a threaded inbox your team reads support and sales mail in. Inbound mail lands in your D1 database, gets indexed, and shows up in a UI you host on your own domain. It's the same data your sender and newsletter use, so a customer's transactional history, marketing engagement, and support conversation are finally in one place.

An AI agent over your inbox

Because the inbox is yours and queryable, Tinbox ships a chat agent (built on the Vercel AI SDK) that can read, search, summarize, and triage your mail conversationally. "Summarize this thread." "Who hasn't replied to the invoice?" "Draft a response to the last complaint." It runs against your data, with the model provider of your choice.

An MCP server

Tinbox exposes your inbox as a Model Context Protocol server, so AI assistants like Claude can connect to your mail directly, either via OAuth for one-click setup or a static bearer token for headless/CLI use. Your assistant reads, triages, and sends real mail with your permission. We walk through the whole flow in mcp-email-server.

Email interpreters

Inbound mail runs through interpreters, rules that classify and react to messages. Some are algorithmic (regex/heuristics for OTP codes, receipts, calendar invites); some are LLM-backed (detect a complaint, a churn risk, an urgent escalation). Each ships with its own eval suite so you can trust the classifications. Interpreters are how your inbox stops being a dumb log and starts being reactive.

Importers

You're not starting from zero. Tinbox imports from Gmail, IMAP, mbox, and Mailchimp, so you can migrate years of mail and an existing audience. The CLI does the heavy fetching locally and the Worker bulk-inserts, so there's no multi-hour serverless job timing out halfway through.

Why now

A few things had to be true for this to make sense, and in 2026 they finally are.

Cloudflare's primitives grew up. D1 is a real, production SQLite database with read replication. R2 has no egress fees. Queues handle the async fan-out that email delivery demands. Five years ago you couldn't build this on the edge. Now you can, and it's cheap.

Per-email and per-contact pricing stopped scaling with you. The SaaS email model is wonderful at small volume and brutal at large volume. When you're sending a million transactional emails a month and paying per-thousand on top of storing the same contact in three vendors, the math turns ugly fast. We did that math in transactional-email-cost, and the gap is bigger than most teams realize.

AI made owning your inbox a superpower, not a chore. An inbox you can't query is just a list you scroll. An inbox that's a database, with an MCP server in front of it, is a substrate your AI tools can actually work on. The vendors that hold your mail won't give you that; their moat is your lock-in.

Vendor independence stopped being paranoia. Pricing changes overnight. Acquisitions kill products. Terms of service shift under you. When the entire stack runs in your own account, none of that is your problem. The full case, beyond cost, is in the reasons to own your email stack instead of renting one.

Where Tinbox isn't (yet) the answer

We're engineers writing for engineers, so: this isn't magic. If you send one welcome email a week, Resend's free tier is simpler and you should use it. If you have a non-technical marketing team that lives in a drag-and-drop campaign builder, Mailchimp's polish is real and Tinbox is rawer. Deliverability is a discipline, not a checkbox. You still own your domain reputation, your warmup, and your list hygiene. Tinbox gives you the controls; it doesn't absolve you of email being hard.

We concede all of that cheerfully. The pitch isn't "these tools are bad." It's: when you outgrow renting your email stack, you should be able to own it without rebuilding from scratch.

How to start

# Scaffold and deploy onto your own Cloudflare account
npx tinbox init yourdomain.com

# Follow the prompts to bind your domain, provision D1/R2/Queues,
# and set DNS (SPF, DKIM, DMARC) records.

From there you have a sender, a newsletter tool, a webmail inbox, an AI agent, and an MCP endpoint, all on your own account, all running as one stack you deploy and control.

If you want to go deeper before you commit:

You self-host it on your own Cloudflare account, so your data and mail stay yours.

Frequently asked questions

What does Tinbox actually replace?

Three things at once: a transactional sender (like Resend), a newsletter/marketing tool (like Mailchimp), and a human inbox/webmail (like Gmail), all running on infrastructure you own.

Where does Tinbox run?

On your own Cloudflare account. It uses D1 (SQLite) for data, R2 for object storage, Queues for async work, and Workers for compute. You install it with a single command and you hold the keys.

Is Tinbox self-hosted?

Yes. You deploy it onto your own Cloudflare account, so your data and keys never leave it, and the license is a one-time lifetime key, not a per-seat or per-email subscription. The free build runs in production at any scale, and lifetime-license holders also get the readable source.

← Back to all articles
On this page

You might also like

Generate and rotate DKIM keys for sending on Cloudflare
tutorialsSep 2, 2026

Generate and rotate DKIM keys for sending on Cloudflare

DKIM (DomainKeys Identified Mail) lets a receiver confirm that mail claiming to be from your domain was signed by someone holding your private key, and that the signed parts were not altered in transit. It is half of what DMARC needs to pass (SPF being the other half), and on a new sending domain it is non-negotiable: Gmail and Yahoo bulk sender rules treat missing DKIM as a reason to throttle or reject. It is one box on the Gmail and Yahoo bulk sender checklist you have to clear before a first campaign.

Email to task automation: turn inbound mail into actions
tutorialsAug 31, 2026

Email to task automation: turn inbound mail into actions

Email to task automation is the practice of reading each inbound message, deciding whether it implies an action, extracting the fields that action needs, and creating the task (or firing the webhook) without a human retyping anything. The mail is structured data wearing a text costume. The job is to undress it once, reliably, and route it.

Email for AI agents: give your agent its own address and inbox
tutorialsAug 28, 2026

Email for AI agents: give your agent its own address and inbox

To give an AI agent its own email, you provision a real address ( agent@yourdomain.com ), route inbound mail to a handler that stores it, and expose both reading and sending as scoped tools the agent can call. The agent becomes the principal: it owns the mailbox, reads through typed tools instead of a screen, and sends from its own address over an HTTPS API. This guide builds the whole thing the hard way first (MX routing, MIME parsing, a message store, an HTTPS send path, and a scoped tool layer), then shows the one-command version at the end.

View all →