“Mailtrap alternative” is searched by three different people. One hit the free plan's message limit in the middle of a release. One has test payloads that must not sit on a vendor's servers. One cannot reach a commercial sandbox from their network at all. The right answer is different for each of them, so this page compares the real options — the tools you run yourself and the sandboxes you use as a service — and ends with a migration checklist you can finish in ten minutes.
If self-hosting is a hard requirement, the short answer is Mailpit: free, open source, one container, actively developed, and the closest thing to a drop-in successor of MailHog. If you would rather not maintain anything at all, keep reading — that is what this instance is for.
Why people look for an alternative
- Metering. Free tiers of commercial sandboxes are metered per message, per inbox or per user, and a test suite that runs on every push burns through them. Here nothing is metered: the only limits are message size and the retention window.
- Where the test messages live. Every message you send to a hosted sandbox is stored on someone else's servers — including headers, links and attachments, and including the message where someone copied real-looking data from a production template.
- Reachability. IP-based blocks, regional restrictions and account reviews happen. A private instance has no such policy layer in front of it.
- SMTP and webhooks in one place. Half of the debugging work is not email at all: it is the callback your provider sends you. A catcher that speaks both saves one account, one dashboard and one set of credentials.
The options, compared
| Option | How it runs | Cost | Where the messages live | Best for |
|---|---|---|---|---|
| Mailpit | self-hosted: single binary or Docker image | free (MIT) | your own host/volume | teams that want to run and own it; the modern successor of MailHog |
| smtp4dev | self-hosted: .NET binary or Docker image | free | your own host | Windows-first teams |
| MailHog | self-hosted, no longer maintained | free | your own host | only if it already runs in your setup — otherwise migrate |
| Mailcatcher (Ruby) / MailDev (Node) | self-hosted | free | your own host | Ruby and Node shops that want the catcher inside their own toolchain |
| Commercial sandboxes (Mailtrap and friends) | vendor-hosted | free tier, then per message / per inbox / per user | vendor servers | teams that want SSO, shared inboxes, support and an SLA |
| This instance | hosted by its operator, private to its users | free, not metered | one private host | projects that want SMTP + webhooks without maintaining anything |
Two facts worth checking before you decide. First, MailHog — the tool most people used for this — has been left behind: Mailpit's own README states that MailHog “is no longer maintained and hasn't seen active development or security updates for a few years now”. Second, Mailpit is actively developed and captures over SMTP with a REST API, HTML, spam and link checks, an optional POP3 server and automatic pruning (by default it keeps the most recent 500 messages). Vendors change their pricing pages often, so we do not quote numbers here: read the page of the vendor you are considering on the day you decide.
Pick by requirement, not by hype
| Your requirement | The fit |
|---|---|
| “Test data must never leave our infrastructure” | Mailpit or smtp4dev on your own host |
| “Nobody on the team wants to maintain a mail server” | this instance, or a commercial sandbox |
| “Per-developer inboxes, share links and webhooks in one place” | this instance |
| “CI must assert on the real MIME message” | any of them — it is just SMTP host and port |
| “Windows-only development laptops” | smtp4dev, or Mailpit's Docker image |
| “We need SSO, audit logs and a support contract” | a commercial sandbox |
What this instance gives you
- One private host, no third-party copy. Messages and webhook payloads are stored in this instance's own database on its own server. No analytics service, no mail vendor and no external queue is in the loop.
- No metering. There are no per-message or per-user plans. The only limits are disk space and the retention window, which is a single setting.
- noindex everywhere. Share links, webhook captures and every application page answer
noindex, nofollow, noarchive, so a crawler cannot pick up a test email that happens to contain a real-looking address. - One address for SMTP and webhooks. Point your application and your providers at the same host; it works for local development and CI as well as for staging.
- Machine-readable output. A read-only share link also answers as JSON, so scripts and AI assistants can review captured mail without screenshots (see the AI guide).
What you trade
- It is one host. There is no vendor SLA, no multi-region failover and no support desk: if the host is down, the instance is down for everyone who uses it.
- The operator is your support. Updates, backups and certificates are handled by whoever runs the instance. That is usually an advantage (nothing to maintain on your side) and occasionally a limit (no 24/7 response, no audit log, no SSO).
- No self-hosting option. The code of this instance is not distributed, so you cannot run your own copy of it. If self-hosting is a hard requirement for your process, this is not the right tool — see the section below.
- Shared fate by design. Everyone who uses the instance shares its storage, its retention window and its uptime.
Side by side
| Commercial sandbox | Self-hosted (Mailpit, smtp4dev) | This private instance | |
|---|---|---|---|
| Price | Free tier, then per message/user | Free, your own servers | Free, not metered |
| Where the data lives | Vendor servers | Your servers | One private host |
| Third-party analytics | Usually yes | None | None |
| Retention | Vendor policy | Storage/pruning settings | A setting (DATA_RETENTION_DAYS) |
| Share links | Yes | You build them | Yes, with expiry and revoke |
| Indexing of test data | Varies | Not applicable (local) | Explicit noindex everywhere |
| Machine-readable export | Usually an API key | REST API | Share token answers as JSON |
| Team features | SSO, roles, audit (paid) | None | Basic: accounts, admin role, share links |
| Who maintains it | Vendor | You | The operator |
| Works without opening ports | Yes | Yes | Yes |
Free vs paid: what “free” actually costs
Nothing here is metered, and that is the whole difference. A commercial free tier is a volume allowance that a busy test suite will exhaust; a self-hosted catcher is free but takes a container, a volume, an upgrade path and somebody who notices when it stops; this instance sits in between — no metering, no maintenance on your side, in exchange for sharing one host with everyone else who uses it.
Switching from a commercial sandbox in ten minutes
- Create an inbox here and copy the host, port, username and password into your staging environment. Keep the old values commented out for a day.
- Send one message from your application and confirm it appears in the dashboard — with headers, HTML body and attachments.
- Repeat for the test environment: the same inbox, or a separate one per environment.
- For webhooks: create a URL here, register it with the provider (Stripe, GitHub, Telegram), trigger one event, and remove the old endpoint after the first successful delivery.
Nothing in your application code changes: it is still SMTP on a host and a port. Moving to a self-hosted tool instead follows the same four steps — only the host and the port change.
If self-hosting is a hard requirement
Then run Mailpit: a Docker image or a single static binary, the UI on port 8025, SMTP on 1025, a REST API for automated tests, and a project that is actively maintained. smtp4dev is the equivalent choice if your team is .NET/Windows-centric. Budget the real cost honestly, because it is not zero: updates, backups, disk space, certificate renewal and monitoring become yours, and so does the 2 a.m. page. Those tools are good — this page just should not pretend to be one of them.
Next steps
- How to test email sending without sending anything — the four-step setup that works with any of the tools above.
- How to test webhooks locally without ngrok — when the problem is the callback, not the email.
- Limits of this instance — message size, attachment size, retention and quotas in one table.
- Privacy and your data — what is stored, for how long and how to delete it.