useSendUpdated May 27, 20267 min read

A Practical useSend Self-Hosted Email Stack

A stack guide for builders running useSend on their own infrastructure.

By Mailbase Team · Target keyword: useSend self-hosted email stack
Glowing server rack and cabling — A Practical useSend Self-Hosted Email Stack
Photo from Unsplash

Overview

A useSend self-hosted email stack is the full set of moving parts around useSend — not just the app, but the delivery provider beneath it, the DNS and authentication around it, the monitoring that catches problems, and the workflow layer on top. Builders often deploy useSend and stop there, then wonder why mail underperforms. This guide treats useSend as one component in a system and walks the pieces you need for a stack that actually holds up in production.

The parts of a production useSend stack

Server rack with status lights in a data centre — The parts of a production useSend stack
Photo from Unsplash

Bottom to top: Amazon SES for delivery (you connect SES credentials; useSend doesn't own IP reputation); useSend itself as the API/dashboard, plus its Postgres and Redis; your sending domain with SPF, DKIM, DMARC and a warmup plan; and bounce/complaint handling wired from SES via SNS into useSend so suppression works. Deploy the app on Docker, Coolify, or Railway — see how to deploy useSend for the steps.

Keep transactional and marketing logically separate within the stack (ideally separate domains/subdomains) so a marketing problem can't take down product email. Each layer should be swappable without disturbing the others.

  • Delivery: Amazon SES (connect credentials, exit sandbox)
  • App: useSend + Postgres + Redis on Docker/Coolify/Railway
  • Domain: SPF/DKIM/DMARC + warmup
  • Feedback: SNS bounce/complaint → useSend suppression

Operating it: monitoring, compliance, workflow

Glowing network cables converging into a switch — Operating it: monitoring, compliance, workflow
Photo from Unsplash

A stack you don't monitor degrades silently. Watch bounce rate (under ~2%), complaint rate (under ~0.3%), and SES sending limits; back up the Postgres database; keep the app updated; and use Google Postmaster Tools for reputation visibility. Compliance is part of the stack too — honored unsubscribes, a physical address, and consent records.

The piece useSend doesn't provide is the workflow layer: a shared reply inbox, AI drafts, MJML campaigns, A/B tests, scheduled sends, and analytics. Build it or point Mailbase at your useSend instance (BYO useSend at €5/mo) so delivery stays on your infrastructure while the team gets the operating layer. Budget the whole thing in self-hosted email marketing costs.

  • Monitor bounce/complaint rates, SES limits, reputation
  • Back up Postgres; keep the app updated
  • Compliance: unsubscribes, physical address, consent
  • Add a workflow layer (build, or Mailbase BYO useSend)

Common Mistakes

  • Choosing a tool before deciding who owns deliverability.
  • Treating DNS authentication as a one-time checkbox instead of an operating baseline.
  • Mixing product-critical transactional email with experimental marketing sends, with no clear boundary.
  • Trusting headline metrics (like open rate) that privacy proxies now inflate.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on usesend self-hosted email stack and the surrounding usesend workflow:

FAQ

What's in a useSend self-hosted email stack?

Amazon SES for delivery, useSend (with Postgres and Redis) as the API and dashboard, your sending domain authenticated with SPF/DKIM/DMARC, SNS-wired bounce/complaint handling feeding suppression, and a workflow layer on top. Deploy useSend on Docker, Coolify, or Railway.

What do I need to monitor when self-hosting useSend?

Bounce rate (under ~2%), complaint rate (under ~0.3%), your SES sending limits and reputation (via Google Postmaster Tools), plus the basics — database backups and app updates. A self-hosted stack degrades silently if you don't watch these.

Does useSend handle deliverability and compliance for me?

Partly. It relays through SES and can record bounces/complaints if you wire up SNS, but SPF/DKIM/DMARC, domain warmup, suppression enforcement, and compliance (unsubscribes, physical address, consent) are still your responsibility as part of the stack.

What's missing from a bare useSend deployment?

The workflow layer above sending — a shared reply inbox, AI drafts, MJML campaigns, A/B tests, scheduled sends, and analytics. Either build it or connect Mailbase to your useSend instance (BYO at €5/mo) so the team gets that layer on delivery you control.