How to Deploy useSend (Self-Hosting Options)
A practical overview of deploying useSend on your own infrastructure — hosting paths, SES, DNS — and where a workflow layer fits on top.
Overview
useSend is an open-source, API-first email sending platform you can run yourself, and deploying it is well within reach for anyone comfortable with a server. The application is the easy part — the parts that actually determine success are the upstream provider (commonly AWS SES), DNS and domain authentication, and the workflow layer you add on top. This is a practical overview; always follow the official useSend docs for exact, current steps.
Where to deploy useSend
Pick the hosting path that matches how you already work. Coolify and Railway both offer near one-click deployment and are popular for fast setup; a plain Docker (or Docker Compose) deployment on any VPS gives you maximum control. useSend needs a Postgres database and Redis alongside the app, so the managed-PaaS routes are easiest because they provision those for you. In every case you provision the app, set the required environment configuration, and connect an upstream provider for delivery — most commonly AWS SES.
The official useSend documentation is the source of truth for exact steps and required env vars (they change over time), but the shape is consistent across hosts: app container + Postgres + Redis + your SES credentials. See our useSend self-hosted stack and Coolify email stack guides for host-specific context.
- Coolify or Railway for near one-click deploys (provision Postgres/Redis for you)
- Docker / Compose on a VPS for full control
- Components: app + Postgres + Redis + SES credentials
- Official useSend docs are the source of truth for env vars
Wiring up AWS SES (the part teams underestimate)
useSend handles the API, dashboard, and domain/contact management, but it relays through an upstream provider for actual delivery and IP reputation — almost always AWS SES. Three SES steps trip people up: 1) verify your sending domain and add its DKIM records; 2) request production access to exit the SES sandbox (until you do, SES only sends to verified addresses); 3) wire up SNS notifications for bounces and complaints so useSend can record them and suppress dead addresses.
That third step is the one people skip and regret — without bounce/complaint feedback, your suppression breaks and your reputation erodes silently. Budget a little time for the sandbox-exit request (AWS asks how you handle bounces and unsubscribes), and plug in your SES access key and region during useSend setup.
- Verify the domain + add DKIM records in SES
- Request production access to exit the SES sandbox
- Wire SNS bounce/complaint notifications into useSend
- Skipping SNS quietly breaks suppression and reputation
DNS, deliverability, and the workflow layer
Deploying the app doesn't change deliverability fundamentals: configure SPF, DKIM, and DMARC on your sending domain, warm it up, handle bounces and complaints, and maintain suppression. This is exactly the part that bites teams who assume "self-hosted" means plug-and-play — you self-host the application, not the IP reputation.
useSend gives you the sending layer, not a team workflow — no shared reply inbox, campaign tooling, or AI drafts. That's where Mailbase fits: on the bring-your-own useSend plan you point Mailbase at the instance you deployed, so delivery stays on your infrastructure while the team gets the inbox, campaigns, analytics, and MCP tooling on top. See connect useSend to Mailbase.
- SPF, DKIM, DMARC on the sending domain + warmup
- Bounce/complaint handling and suppression are still yours
- useSend is sending only — no team workflow
- Point Mailbase (BYO useSend) at your instance for the workflow
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 how to deploy usesend and the surrounding usesend workflow:
FAQ
How do I deploy useSend?
Choose a hosting path — Coolify or Railway for near one-click deploys, or Docker on a VPS for full control — provision the app along with Postgres and Redis per the official docs, connect AWS SES for delivery, and configure SPF/DKIM/DMARC on your sending domain. The managed-PaaS routes are easiest because they set up the database and cache for you.
What do I need to run useSend?
The useSend app container plus a Postgres database and Redis, an upstream delivery provider (almost always AWS SES), and a sending domain you authenticate with SPF, DKIM, and DMARC. Hosting it on Coolify or Railway provisions the database and Redis for you.
Do I need AWS SES to run useSend?
Usually yes. useSend provides the API, dashboard, and domain/contact management, but relays through an upstream provider — most commonly AWS SES — for actual delivery and IP reputation. You'll verify your domain, exit the SES sandbox, and wire up SNS bounce/complaint notifications. You self-host the app, not the mail-server reputation.
Does deploying useSend give me campaigns and a reply inbox?
No — useSend is the sending layer (API, dashboard, domains), not a team workflow. For a shared reply inbox, campaigns, AI drafts, and analytics, add a workflow layer like Mailbase, which connects to your self-hosted useSend instance on the bring-your-own plan.