How to Deploy useSend (Self-Hosting Options)

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, and analytics 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 and 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: