Skip to content

Email for indie hackers with many projects

Ten side projects should not mean ten email accounts, ten DNS setups and ten bills. Mailbay groups everything by project so each product keeps its own domain, inboxes and keys.

Updated 2 min read

On this page (5)

One account, many projects

If you ship small products, each one ends up needing the same email: support@ that someone reads, and noreply@ that sends password resets and receipts. Set up per product, that is a mail provider account, a sending service account, a DNS session and a bill each, times the number of projects you keep alive.

Mailbay has one workspace for you, with a project per product. Each project has its own domains, inboxes, senders, API keys, webhooks and logs; the plan and its limits are shared across all of them.

Workspace  (you, your plan, pooled limits)
├─ Superchat        superchat.com, mail.superchat.com
│   ├─ inboxes      support@, billing@
│   ├─ senders      noreply@superchat.com
│   └─ keys         superchat-prod (sending), support-bot (inbox)
├─ Invoicely        invoicely.app
│   ├─ inboxes      hello@
│   ├─ senders      receipts@invoicely.app
│   └─ keys         invoicely-prod (sending)
└─ Playground       k7m3qz.mailbay.email, the Catch-all for tests and agents
A workspace with two products and the Playground. Keys belong to one project and can never reach another.

Add a project

Choose New project, name it, and paste the domain. Mailbay detects the DNS host and any existing mail, suggests support@, hello@, billing@ and noreply@, and shows the records with SPF merged into what you already have. On Vercel or Cloudflare it writes them for you. The details are in support@ on your own domain.

If the domain already gets mail elsewhere and you receive on mail.yourproduct.com, the root and its mail. subdomain count as one domain against your plan.

A key per app

Give each deployed app a sending key for its own project, optionally limited to one domain. It can send from that domain and read its own send log, and nothing else, so a leaked key from one side project cannot read another project's support mail.

curl https://api.mailbay.dev/v1/keys \
  -H "Authorization: Bearer $SUPERCHAT_FULL_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "superchat-prod", "permissions": "sending", "domain_id": "superchat.com"}'

Then send over the API or SMTP from whatever stack each product uses; the sending guide covers Supabase, Next.js, Nodemailer and the Resend SDK.

Work per project from the terminal

An API key always acts in its own project, so the simplest setup is one key per project in each repository's environment. The mailbay CLI reads MAILBAY_API_KEY before its config file:

# in ~/code/superchat/.envrc (or your shell of choice)
export MAILBAY_API_KEY=mb_live_superchat_full_key

mailbay projects                 # the projects you can see
mailbay inbox list               # this project's inboxes
mailbay domain verify superchat.com
mailbay wait ibx_01m4x47frjph8segqg79gqpz2t --subject "invoice" --timeout 2m

The dashboard has a project switcher at the top, and the support Inbox shows conversations from every project at once, with a filter per project.

What it costs

Nothing during the beta. After it, the planned plans are per workspace, not per project:

  • Free: 3 inboxes, 3,000 emails a month, 3 custom domains. The Catch-all does not count as an inbox.
  • Pro, $9 a month: 25 inboxes, 50,000 emails a month, 10 custom domains, shared by every project.
  • Scale, $99 a month: 250 inboxes, 250,000 emails a month, unlimited domains.

Ten projects with support@ and noreply@ each fit in Pro. The pricing page has an estimator for your own numbers.

Join the beta

Mailbay is in private beta and free while the beta runs: inboxes, sending, your own domains and MCP. We invite people in small batches and read every note on the form.