useSend: a self-hosted Amazon SES front end for transactional and marketing email

The gap useSend fills between Amazon SES and a sending product

Amazon SES is cheap and reliable, and its own console is not built around the job most senders actually have: see which messages were delivered, opened, clicked or bounced, manage a contact list, and fire a newsletter without writing a queue. useSend puts that layer on top. The README is direct about the dependency: "As most of email products out there, useSend also uses Amazon SES under the hood to send emails." The project positions itself as an open alternative to Resend, SendGrid and Postmark, with the sending infrastructure running on your own machines.

The audience is narrower than the tagline suggests. You need an AWS account with SES configured, a Postgres database, a Redis instance, and a host that can run a Next.js application plus a separate SMTP server process. Teams already paying for one of the hosted APIs are not the target. Teams that have outgrown hand-rolled scripts around the SES API, or that cannot send customer data through a third-party processor, are.

The README states the project is in beta and that the team is "working on opening useSend for public beta." Treat that as the operating assumption. The commit history is live (the last push was on 2026-09-08, and v1.9.8 landed on 2026-08-30), so work is ongoing, but the project itself does not claim production readiness.

How the pieces fit: Next.js, Prisma, Redis and a separate SMTP server

The repository is a pnpm and Turborepo monorepo. The README lists the stack plainly: Next.js for the framework, Prisma as the ORM, Tailwind and shadcn/ui for the interface, NextAuth.js for authentication, tRPC for internal API calls, hono for the public API, and Redis for the queue. The top-level package.json confirms the shape with scripts that filter by workspace: build:web, build:marketing, build:smtp, and a test:infra:up script that brings up docker/testing/compose.yml before integration tests run.

Two API surfaces exist and they are not the same thing. tRPC serves the dashboard, which is why the dashboard and the public API can evolve separately. hono serves the public REST API that your application calls to send mail. The SMTP server is a third entry point, built by its own filter, so a legacy application that only knows how to talk SMTP can point at useSend instead of rewriting.

Redis is not optional infrastructure in this design. It backs the queue, which is what makes the schedule API and bulk marketing sends work: a request to send later is enqueued rather than held in the web process. Delivery events come back the other way. The .env.example file carries AWS_SNS_ENDPOINT alongside AWS_SES_ENDPOINT, which tells you the design expects Amazon SNS to push bounce and complaint notifications back into the application, where they land in the dashboard and drive subscription handling. The README says of contacts and bulk mail: "We will take care of the subscriptions."

The email editor is a separate package, packages/email-editor, and the README credits jsx-email for converting editor content to HTML, tiptap as the editor core, and maily.to as the inspiration. That is a real architectural boundary: the editor can be built and tested on its own through build:editor.

Installing useSend with Docker and sending a first email

The README does not put install commands inline. It points at three places: a local development guide at docs.usesend.com/get-started/local, a self-hosting overview at docs.usesend.com/self-hosting/overview, and a Docker README inside the docker directory of the repository. The Docker image is published on DockerHub as usesend/usesend and on GitHub Container Registry as ghcr.io/usesend/usesend. The README warns that "you will need to provide environment variables for connecting to the database, redis, aws and so forth."

Start from the example environment file, which is the only configuration reference in the repository. Copy it and fill in real values:

cp .env.example .env

The database and queue URLs in the sample point at local services, and the AWS endpoints point at a local mock, which is what the test infrastructure expects:

DATABASE_URL="postgresql://usesend:password@localhost:54320/usesend"
REDIS_URL="redis://localhost:6379"
AWS_DEFAULT_REGION="us-east-1"
AWS_SES_ENDPOINT="http://localhost:3003/api/ses"
AWS_SNS_ENDPOINT="http://localhost:3003/api/sns"

For a real deployment you would replace AWS_SES_ENDPOINT and AWS_SNS_ENDPOINT with the actual Amazon endpoints, and set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, NEXTAUTH_URL, NEXTAUTH_SECRET and FROM_EMAIL. The file also sets API_RATE_LIMIT=2 and AUTH_EMAIL_RATE_LIMIT=5, and notes an optional REDIS_KEY_PREFIX for sharing a Redis instance. That prefix is worth setting if you are not running Redis exclusively for useSend.

The Docker README is where the actual run command lives; the top-level README does not include one. If you prefer a hosted path, the README offers a Railway deploy button and links to a Railway self-hosting guide, which it calls "the quickest way to spin up useSend." Once the app is up, the workflow is the one the feature list describes: add a domain, then send transactional mail through the REST API or the SMTP server, and watch delivered, opened, clicked and bounced events in the dashboard.

Where useSend stops: inbound mail, BYO credentials and the beta label

The feature checklist is honest about what is missing. Inbound email is unchecked, so a useSend deployment is outbound only. If you need reply handling, threading, or a support inbox, this is not the tool and the README does not pretend otherwise. BYO AWS credentials is also unchecked, which means the AWS account is wired in at the deployment level rather than per user or per tenant. A single self-hosted instance is effectively bound to one set of SES credentials, and multi-tenant hosting is not a described use case.

SMS, push notification and WhatsApp appear only as future plans: "we plan to expand to other sending protocols." Nothing in the repository suggests those exist today.

The beta label carries concrete consequences. The README asks readers to "fix or create issues, that are needed for the first production release," which is a statement that the first production release has not happened. There is no documented upgrade or rollback procedure anywhere in the README, and no stated migration path between releases. The Prisma scripts in package.json (db:migrate-dev, db:migrate-deploy, db:migrate-reset) show that schema changes are managed through migrations, but the README does not describe how a running self-hosted instance should apply them or what happens if a migration fails. Budget for reading the release notes before each upgrade rather than assuming a drop-in image swap.

One more practical constraint sits in the environment file: API_RATE_LIMIT defaults to 2. That is a development default, not a production one, and anyone copying .env.example into a live deployment without revisiting it will throttle their own sending.

useSend compared with Listmonk and with staying on a hosted API

Listmonk is the closest self-hosted neighbour and the difference is the sending path. Listmonk is built around its own SMTP configuration and a subscriber list; it is a newsletter and mailing-list application first. useSend is built around Amazon SES specifically, and its feature list puts transactional mail and the REST API alongside marketing email. If your workload is mostly one-to-one transactional messages triggered by application events, useSend's API and SMTP server matter more than Listmonk's list management. If your workload is a newsletter with complex subscriber segmentation, Listmonk's focus is the better fit and useSend's marketing feature is younger.

Against staying on Resend, SendGrid or Postmark, the trade is operational. The hosted services give you deliverability tooling, support and no servers; useSend gives you the data path and the bill. Because SES does the actual sending in all cases, the deliverability difference is mostly about how well each layer handles bounces and complaints. useSend's answer is the SNS endpoint feeding events into the dashboard and the subscription handling the README mentions. That is a real mechanism, but it depends on your SNS configuration being correct, and the README does not walk through it.

A middle option exists in the same ecosystem: FreeResend and FreeSend appear in related searches as free Resend-style alternatives. Nothing in the repository describes those projects, so no comparison can be made beyond noting that the search interest exists.

Licence, upgrade cost and what a self-hosted instance commits you to

useSend is licensed AGPL-3.0, as the README badge and the LICENSE file both state. The practical consequence for most teams is that running it as internal infrastructure is unremarkable, while offering a modified version to third parties over a network triggers source disclosure obligations. That is a well-known characteristic of the AGPL and not unique to this project. If you intend to build a commercial sending product on top of a modified useSend, read the licence text itself rather than relying on a summary; this article is not legal advice.

The upgrade cost is the part that is easy to underestimate. You are running a Next.js app, a Postgres database, Redis, an SMTP server process, and a set of AWS resources. Each release may include Prisma migrations, and the repository provides db:migrate-deploy for applying them, but the README does not document a rollback path. The gap between v1.9.6 on 2026-07-23 and v1.9.7 on 2026-08-23 shows releases can arrive roughly monthly, which means upgrades are a recurring task rather than a one-off. Pin a specific image tag rather than tracking latest, and read the release notes for the version you are moving to.

The AWS side is a cost you already carry if you use SES, and the README's pitch is that this route is "reliably and cheaply" priced. What changes is who owns the failure: SES quota increases, SNS topic configuration and bounce handling all become your responsibility instead of a vendor's.

Editorial conclusion

Adopt useSend if you already hold Amazon SES production access, you are comfortable running Postgres and Redis, and you want a sending dashboard you control rather than a per-seat SaaS bill. Do not adopt it if you need inbound email or want to bring your own AWS credentials, because the README marks both as unchecked. Before deploying, open .env.selfhost.example and confirm you can supply every value it asks for, especially AWS_SES_ENDPOINT and AWS_SNS_ENDPOINT, which in the sample point at a local mock rather than at Amazon.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. usesend/useSend on GitHub