Open-source email sending infrastructure, honestly reviewed. Self-hosted alternative to Resend, SendGrid, and Postmark.

TL;DR

What it is: Open-source (AGPL-3.0) email sending platform — transactional email API, marketing campaigns, SMTP relay, contact management, and analytics in one self-hostable package [1][2].
Who it’s for: Developers and technical founders who are paying Resend or SendGrid for transactional email and want to own the infrastructure, or builders who need both transactional and marketing email without paying two separate SaaS bills [2].
Cost savings: Resend’s paid plans start at $20/mo for 50K emails. useSend cloud charges $0.0004 per transactional email with a $10/mo minimum — 50K emails costs $20, but 10K costs only $10. Self-hosted brings that down to AWS SES rates (~$0.10/1,000 emails) plus a $5–10 VPS [2].
Key strength: Covers transactional email, marketing campaigns, contact management, suppression lists, SMTP relay, and a visual email editor — all in one codebase. Testimonials from teams running 30K-subscriber newsletters praise the setup simplicity [2].
Key weakness: AGPL-3.0 license (not MIT) limits commercial embedding. Still in beta. “BYO AWS credentials” for the cloud product is listed as a planned but unfinished feature. No inbound email support yet [1].

What is useSend

useSend is an open-source email sending platform that covers the infrastructure layer most SaaS products have to stitch together from two or three vendors: a transactional email API (like Resend or Postmark), a marketing email tool (like Mailchimp or Loops), and a contact database somewhere in the middle. useSend does all three [1][2].

The GitHub README describes it bluntly: “Open source alternative to Resend, Sendgrid, Postmark etc.” The website homepage goes broader — “The open source email platform for everyone” — but the README framing is more honest about what the product actually replaces [1][2].

Under the hood, useSend uses Amazon SES to send emails, same as most commercial email services [1]. The value isn’t that you bypass AWS — it’s that you get a full-featured platform on top of AWS SES rather than paying $20–50/mo for a wrapper someone else runs. On the cloud offering, useSend manages the SES account. Self-hosted, you bring your own AWS credentials and run the stack yourself.

The project is bootstrapped, funded by the cloud offering and sponsors, built by a founder (Koushik) who is personally responsive in Discord and GitHub [2]. As of this review it sits at 4,060 GitHub stars with an active Discord community.

Tech stack is modern and readable: Next.js, Prisma, Tailwind, shadcn/ui, tRPC (internal), Hono (public API), Redis for queue, NextAuth for auth [1]. If you need to modify it or debug it, the code isn’t exotic.

Why people choose it

No independent third-party review sites have covered useSend yet — it’s still in public beta and too new to have the review corpus that established tools like n8n or Activepieces have accumulated. What exists are testimonials on the website from real builders at real projects, which are worth reading as signals [2].

Marc Seitz from papermark.com: “Transitioned recently to open source email sender useSend for our 30k and growing newsletter. It’s such a great product and amazing oss experience.” A 30K-subscriber newsletter is a meaningful load test — that’s not a toy use case [2].

Andras Bacsai from coolify.io — itself a prominent self-hosted infrastructure project — thanked the team directly [2]. When the maintainer of one notable self-hosted tool endorses another, it’s a signal worth noting.

Tommerty from doras.to: “useSend was extremely easy to set up, and I love that it’s open source. Koushik has been an absolute awesome person to deal with and helps us with any issues or feedback.” [2]

The pattern across these endorsements is consistent: quick setup, open-source ethos, good founder responsiveness. These are early-adopter signals from technical builders, not enterprise procurement reviewers.

The decision to use useSend over the incumbents typically comes down to one of three things: the per-email pricing beats Resend/Postmark at volume, the SMTP relay kills vendor lock-in for legacy apps, or the combination of transactional + marketing in one bill is cleaner than paying two SaaS tools separately.

Features

Based on the README and website [1][2]:

Email sending:

Transactional email via REST API with typed SDKs in TypeScript, Python, Go, and PHP [2]
SMTP relay for any app or framework — the website specifically mentions Supabase as a use case [2]
Schedule API for delayed sends [1]
Webhook support for delivery events [1]

Marketing email:

Visual WYSIWYG email editor described as “Notion-like” — built on Tiptap, inspired by maily.to, converts to email-safe HTML via jsx-email [1]
Reusable templates with brand styles and variable personalization [2]
Contact management: lists, per-list subscription status, import/export [2]
Automatic suppression list populated from bounces and complaints [2]

Analytics and observability:

Delivery, open, click, bounce, and unsubscribe tracking in real time [2]
Searchable log, filterable by domain, status, and API key [2]
Export capability [2]

Infrastructure:

Docker container on both DockerHub and GitHub Container Registry [1]
One-click Railway deploy for the non-VPS path [1]
Redis queue for reliable delivery [1]

Still in progress (explicitly listed as unchecked in the README):

Inbound email [1]
BYO AWS credentials (for the cloud product — you’d use your own SES account instead of theirs) [1]

The SMTP relay deserves a specific callout: this is what makes useSend useful even for teams that aren’t building email-native products. If you’re running a Laravel app, a Ghost blog, a Supabase project, or any service that just needs an SMTP host for notification emails, you can point it at useSend and stop paying Mailgun or SendGrid for the privilege. That’s a genuine workflow simplification.

Pricing: SaaS vs self-hosted math

useSend Cloud:

Free: 3,000 emails/month, 100/day, 1 domain, 1 contact book, 1 team member [2]
Paid: $10/month minimum usage credit, then pay-as-you-go [2]
- Transactional: $0.0004/email
- Marketing: $0.001/email

Concrete math:

Volume	useSend Cloud	Resend*	SendGrid Essentials*	Postmark*
3K/mo	$0	$0	$0	~$15
10K/mo	$10 (minimum)	$20	$19.95	$15
50K/mo	$20	$20	$19.95	$50
100K/mo	$40	$40+	$34.95	$100
500K/mo	$200	$195+	$89.95+	~$400

*Competitor pricing from public pricing pages, transactional only, approximate.

The useSend advantage is clearest in the 10K–100K range, where you’re past the free tier of competitors but below the volume where SendGrid’s bulk discounts kick in. At 50K transactional emails, useSend runs the same as Resend. At 100K it starts to pull ahead.

Self-hosted math:

You need: an AWS account (SES runs $0.10/1,000 emails = $0.0001/email), a VPS ($5–10/mo on Hetzner or Contabo), PostgreSQL (bundled in Docker Compose), Redis (bundled), and a domain for your sending address.

100K transactional emails self-hosted: ~$10 SES + ~$8 VPS = $18/month. That’s a 55% reduction versus useSend Cloud and comparable to what you’d pay SendGrid at that volume, except you own the stack.

The catch: you’re on the hook for deliverability. Amazon SES requires a warm-up period and has its own sending limits. useSend manages this for you on the cloud offering; self-hosted, it’s your responsibility.

Deployment reality check

The README points to a detailed self-hosting guide at docs.usesend.com and a Docker README in the repo. Railway deploy is one click [1].

What you actually need for a VPS self-host:

A Linux VPS with 1–2GB RAM (the stack is Next.js + Postgres + Redis, nothing exotic)
Docker and docker-compose
An AWS account with SES configured and verified sending domain
A reverse proxy (Caddy or nginx) for HTTPS
An existing domain with DNS access (for SPF, DKIM, DMARC records on your sending domain)

Where it can get bumpy:

AWS SES starts in sandbox mode — you can only send to verified addresses until you request production access. This is an AWS process, not a useSend process, but first-timers hit it hard.
DKIM/SPF/DMARC setup is table stakes for deliverability and non-trivial the first time. The platform doesn’t automate this for you.
“BYO AWS credentials” being on the roadmap rather than shipped means if you want to use your own SES account with the cloud product (not self-hosted), you can’t yet [1].
The project is in beta. API surface can change. If you’re building something production-critical, pin your Docker image version.

For a technical founder or developer: an afternoon to a working instance, including SES setup. If you’ve never touched SES or DNS: a full day, or find someone to deploy it for you. The Railway path skips most of the infrastructure work but still requires AWS SES configuration.

Pros and cons

Pros

Transactional + marketing in one tool. You don’t need Resend for APIs and Mailchimp for newsletters. One codebase, one bill, one contact database [2].
Actual affordability at real volumes. $0.0004/email transactional is at or below what you’d pay Resend, Postmark, or SendGrid, with a lower minimum than most [2].
SMTP relay kills vendor lock-in. Any app that speaks SMTP can switch to useSend without a code change. Point, shoot, done [2].
Visual email editor included. Notion-style drag-and-drop campaigns without paying for Beehiiv or Loops [1][2].
TypeScript/Python/Go/PHP SDKs. Not just a REST API with curl examples — actual typed clients for the languages developers actually use [2].
Suppression list management. Automatic bounce/complaint handling, which is one of the less visible but genuinely important deliverability features [2].
Responsive maintainer. Multiple testimonials specifically call out Koushik by name for quick support [2]. This matters during beta when documentation has gaps.
Railway one-click deploy. For teams that don’t want to manage a VPS, it’s a fast path to self-hosted without the infrastructure overhead [1].

Cons

AGPL-3.0, not MIT. This is a meaningful constraint. If you embed or modify useSend and run it as a network service, you must release your modifications as open source. For internal use, fine. For building a commercial email-sending product on top of useSend, talk to a lawyer first [1].
Still in beta. APIs can change, documentation is incomplete in places, features on the roadmap aren’t shipped yet. Not a reason to avoid it, but a reason to pin versions and test before relying on it for critical flows [1].
No inbound email. If your use case requires receiving and processing email (support inbox, lead forms via email, etc.), useSend can’t do that yet [1].
Depends on Amazon SES. Self-hosted or cloud, delivery goes through SES. You’re not running a fully independent MTA. For most teams that’s fine — SES is reliable. But if you want true independence from AWS, you’d need to build that layer yourself.
BYO AWS credentials on cloud not yet available. If you want useSend’s dashboard but your own SES account (for sending reputation control, or cost optimization at high volume), you’re waiting for a feature that’s on the roadmap but not shipped [1].
No third-party review data yet. The tool is new enough that there are no independent benchmarks, Trustpilot reviews, or comparative analyses from neutral sources. You’re going in somewhat on faith and the GitHub star count [1][2].
Small team, bootstrapped. One founder, community contributors. Faster to ship than a VC-backed team, but also higher bus-factor risk. Contrast with SendGrid (Twilio) or Postmark (Wildbit/ActiveCampaign), which have organizational backing.

Who should use this / who shouldn’t

Use useSend if:

You’re paying $20–100/mo for transactional email (Resend, Postmark, SendGrid) and your volumes are in the 10K–500K/month range where the per-email math works out better.
You need both transactional and marketing email and want one tool instead of two SaaS subscriptions.
You have an app using SMTP for notification emails and want to switch providers without a code change — point it at useSend’s SMTP relay.
You’re comfortable with Docker + AWS SES setup, or willing to pay someone once to deploy it.
You’re building internal tooling or a personal product where AGPL doesn’t create commercial complications.

Skip it if:

You need something battle-tested for mission-critical sends today. Wait for post-beta, or use Postmark which has a 15-year track record.
You’re building a commercial product you’d want to embed email infrastructure in — AGPL requires open-sourcing your modifications. Resend’s SDK is MIT; useSend’s server is not.
You need inbound email processing.
You need BYO AWS credentials on the cloud product — that feature isn’t ready yet.
You have zero tolerance for debugging self-hosted infrastructure. Stick with Resend’s managed service.

Consider it but verify if:

You’re running a newsletter over 30K subscribers — Marc Seitz from papermark.com reports positive results at that scale, but no independent benchmarks exist yet [2].

Alternatives worth considering

Resend — The developer-friendly transactional email API that useSend explicitly benchmarks against. Cleaner DX, bigger ecosystem, MIT-licensed SDK, no self-hosted option. Starts at $0, scales to $20/mo for 50K emails. Pick this if you want managed email without infrastructure.
Postmark — The reliability standard for transactional email. $15/mo for 10K, expensive at volume, but 15 years of deliverability reputation and a separate inbound email processing feature useSend lacks. Pick this if uptime and deliverability track record matter more than cost.
SendGrid — Twilio’s platform, covers transactional and marketing in one product (like useSend does). Better deliverability tools and analytics at scale, meaningfully more expensive, fully closed source.
Listmonk — Open-source (AGPL) newsletter and mailing list manager. Only covers bulk/marketing email, not transactional API. More mature than useSend for the newsletter use case specifically, larger community.
Postal — Open-source (MIT) mail server that includes an actual MTA, not just an SES wrapper. More complex to run but true email independence. For teams who specifically want to avoid AWS.
Amazon SES directly — $0.10/1,000 emails with no SaaS layer. Worth considering if you have engineering capacity to manage deliverability and don’t want a dashboard. useSend is essentially “SES with a dashboard and better DX.”

The realistic shortlist for a developer or technical founder: useSend vs Resend. Pick useSend if self-hosted control and combined transactional + marketing matter. Pick Resend if you want managed infrastructure with zero ops overhead and a larger integration ecosystem.

Bottom line

useSend is a genuinely useful piece of infrastructure for technical founders who are tired of paying two SaaS subscriptions for email — one for transactional, one for marketing — when a self-hostable open-source alternative can do both for the cost of an AWS SES account and a small VPS. The pricing math is competitive, the SMTP relay is a real convenience feature, and the early traction (4,060 GitHub stars, endorsed by the coolify.io and papermark.com teams) is a positive signal for a beta product.

The honest caveats: AGPL-3.0 limits commercial embedding, the project is bootstrapped and in beta so rougher edges exist, and you won’t find the independent review data that more established tools have. If you need a production-critical email system today, Postmark or a pinned version of Resend is the safer bet. If you’re willing to run beta software and want to cut your email bill and own the stack, useSend is worth the afternoon it takes to deploy.

Sources

useSend GitHub Repository — README, feature list, tech stack, license (AGPL-3.0), Docker instructions. https://github.com/usesend/usesend (4,060 stars)
useSend Official Website — Homepage, pricing page, feature descriptions, customer testimonials, SDK documentation. https://usesend.com
useSend Self-Hosting Guide — Docker setup, environment variable requirements, Railway deploy instructions. https://docs.usesend.com/self-hosting/overview
useSend Docker Hub — Container registry, pull statistics, deployment options. https://hub.docker.com/r/usesend/usesend