Read it. Run it.
Leave freely.
The core is open source and runs single-tenant on your own infrastructure. Not a trimmed-down community edition — the same code our cloud runs, with nothing held back to sell you later.
git clone https://github.com/martinbusinessconsultants/outsend.git
cd outsend
cp .env.example .env # AWS credentials, sending domain, secret key base
docker compose up -d # app, SMTP relay, queue worker
# The first account to sign up becomes the owner.
# After that, a single-tenant instance stops accepting signups.
open http://localhost:3000You bring an AWS account for the actual sending. Everything else is in the repo.
Portability only counts if you can test it.
Every vendor says you can leave. Very few make leaving a documented, supported path you could actually walk down this afternoon. The difference matters most at exactly the moment you need it, which is also the moment you have the least leverage to find out.
Open-sourcing the core settles the question permanently. You can read how sending, event ingestion, reputation scoring, and suppression actually work. You can run the whole thing yourself. You can export your configuration and your data. And if we ever stop deserving your business, the exit is agit clone, not a negotiation.
This is also a constraint on us. We cannot quietly make self-hosting worse to drive cloud adoption, because the code is right there and you would see it. That constraint is the point.
Boring on purpose.
A Rails monolith, SQLite, and a small SMTP service. There is no Kubernetes here and no distributed anything. Mail infrastructure should be the least exciting part of your stack.
- your app → API · SMTP relay
- OutSend — validation, suppression, reputation, queue
- AWS SES · your verified domain, your region
- receiving provider → SNS → events
- stored event + raw payload → log, webhooks, reputation
- Application
- Ruby on Rails 8.1 · Inertia · React · shadcn/ui
- Data
- SQLite · Solid Queue · Solid Cache · Solid Cable
- Sending
- AWS SESv2, with SNS delivering events back
- SMTP relay
- Standalone TypeScript service on STARTTLS 2587
- Deploy
- Docker and Kamal, with a /up health endpoint
One instance, one owner.
A self-hosted instance accepts exactly one signup. The first account to register becomes the owner, and the instance then closes registration — so an internet-facing deployment does not quietly become someone else's relay.
Everything else still works the way it does in cloud: workspaces, teammates, scoped API keys, domains, campaigns, webhooks, and the full event history. If you genuinely want multi-tenant, it is one flag — and then it is your abuse-handling problem, which is a real job.
Same code. Different amount of your time.
The only honest reason to pay us is that running mail infrastructure is work you would rather not do. So that is the only thing we sell.
| Question | Self-hosted | Cloud |
|---|---|---|
| Who runs it | You | Us |
| Software cost | Free | From $9.99/mo |
| Sending cost | Your AWS bill | Included in the plan |
| Feature set | The whole thing | The whole thing |
| Tenancy | Single-tenant by default | Isolated sending identity |
| Upgrades | When you pull | Continuous |
| Deliverability operations | Yours to run | Ours to run |
| Support | Community, or a contract | Included |
Who pays for this.
Cloud subscriptions and support contracts fund the open core. That is the entire model — no venture capital, no acquisition clock, no quarter where the open parts get starved to make a growth number.
It is a slower way to build a company. It is also the only structure where we can credibly promise that the self-hosted path will still be there in five years, because our revenue does not depend on closing it.
Clone it before you trust us.
The self-hosting guide takes about five minutes and settles most of the questions a marketing page cannot.
Open core · never venture-backed · operated by Martin Business Consultants