MailHog works great locally.
What about staging?
MailHog is a fantastic tool for catching emails on your local machine. Zero setup, instant feedback. But when you need shared visibility across environments—CI, staging, teammates—local tools hit their limits.
Sendpit is a hosted SMTP sandbox. Your whole team sees the same inbox, emails persist between deploys, and CI pipelines can send without local configuration.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailHog Self-hosted open-source
- Pricing and features last verified: 2026-03-18
What MailHog does well
MailHog is one of the simplest ways to capture emails during local development. Download a single Go binary, run it, point your app's SMTP config at localhost:1025, and you're done. Emails show up in a clean web UI at localhost:8025. No dependencies, no installation steps, no configuration files.
For solo developers debugging email templates or testing transactional flows, MailHog is a sensible default. It's free, open source, and requires no account or internet connection. If you're working alone on your laptop, it does exactly what you need.
MailHog also includes a lesser-known feature called Jim, a chaos testing middleware that randomly rejects connections, rate-limits senders, or introduces errors. It's useful for testing how your application handles SMTP failures—something most local email catchers don't offer.
The tool has basic API endpoints for retrieving and deleting messages programmatically, and it supports both an in-memory store and an optional MongoDB backend for persistence. Frameworks like Laravel historically bundled MailHog as part of their local Docker setup, which is how many developers first encountered it.
The tool has been around for years and has a loyal following. There's a reason developers recommend it.
MailHog hasn't been updated since 2020
Open issues
Last release
Since update
MailHog's last meaningful commit was in 2020. The GitHub repository shows over 200 open issues, pull requests sitting unmerged, and bug reports going unanswered. The only release ever published was v1.0.1, and there has been no indication of future development.
The maintainer moved on, which is entirely normal in open source. Maintainers are not obligated to support projects indefinitely, and MailHog served the community well during its active years. But teams building production workflows on unmaintained software should understand what that means in practice: no security patches, no bug fixes, no compatibility updates for newer Go versions or operating systems.
The Go community has largely moved to Mailpit as the spiritual successor to MailHog. Laravel Sail, DDEV, and other development frameworks have switched their defaults accordingly. If you're still using MailHog, you're running software that the ecosystem has moved past.
This doesn't mean MailHog stopped working overnight. But every month without updates increases the gap between what the tool supports and what modern development environments expect.
Known issues you're probably working around
MailHog works for basic local testing, but there are well-known limitations that teams encounter as their usage grows. Most of these have been reported as GitHub issues and remain open.
In-memory storage
Emails live in RAM by default and are lost on restart. MailHog supports a MongoDB backend, but most teams never configure it—adding another service just for email persistence is more complexity than most local setups warrant.
No full-text search
MailHog only supports basic subject and recipient filtering. You cannot search email bodies. Finding a specific email in a busy inbox means scrolling through everything manually.
No TLS support
SMTP connections to MailHog are unencrypted. That is fine on localhost, but becomes a risk if you expose it to a local network or Docker network where other containers can intercept traffic.
Attachment problems
Large attachments can cause memory spikes since everything lives in RAM. There are known bugs with certain MIME types that cause attachments to render incorrectly or fail to download.
No responsive UI
The web interface was built for desktop browsers and does not adapt to mobile or tablet screens. Checking emails from a phone during QA is impractical.
No webhooks or automation
The API is limited to basic message retrieval and deletion. You cannot trigger CI/CD workflows or external notifications when emails arrive, which limits integration with automated testing pipelines.
None of these are dealbreakers for quick local testing. But if you find yourself working around these limitations regularly, it may be worth considering whether the tool still fits your workflow.
The Docker Compose lifecycle problem
Most teams today run MailHog inside Docker Compose. It is the recommended approach for frameworks like Laravel and many others. But Docker's lifecycle creates a specific problem for in-memory email storage.
mailhog:
image: mailhog/mailhog:latest
ports:
- "8025:8025" # Web UI
- "1025:1025" # SMTPThis is the typical MailHog service definition. It looks simple, and it is. But the problem surfaces during normal development cycles. Running `docker compose down` followed by `docker compose up` wipes the inbox completely. Every restart starts fresh because MailHog's default in-memory backend does not persist data to disk.
Teams end up with workarounds: keeping the MailHog container running indefinitely even when other services are stopped, configuring the MongoDB backend which requires adding another service to docker-compose.yml, or simply accepting that emails from a previous session are always gone.
You can mount a volume, but MailHog's in-memory store does not write to disk by default. The volume approach only works with the MongoDB storage backend, which turns a simple single-service setup into a two-service dependency chain.
For quick local testing where you only care about the current session, this is fine. But it falls apart the moment you need to reference an email from yesterday, share a link to a specific message, or debug an issue that was reported after you restarted your containers.
When local tools stop scaling
"Where did my emails go?"
MailHog stores emails in memory. Restart the process and they're gone.
"Can you screenshot that email?"
Teammates can't see your local inbox. Debugging becomes a game of screenshots.
"It works on my machine"
CI runners and staging servers need their own SMTP config. Local tools don't transfer.
"The QA team needs to verify that email"
QA can't access a developer's local MailHog. Emails sent from staging vanish into the void.
The moment you have multiple people working on the same project—or multiple environments sending emails—local tools start requiring workarounds. Self-hosting MailHog on a shared server is possible, but then you're maintaining infrastructure.
A hosted SMTP sandbox gives you the same capture-and-inspect workflow, but with built-in persistence, team access, and zero infrastructure management.
Local vs. hosted
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Both capture emails. The difference is where the inbox lives and who can see it.
Same workflow, shared visibility
The core loop is the same: configure SMTP, send emails, inspect what arrives. The difference is that Sendpit's inbox is hosted, so your staging server, CI runner, and teammates all see the same emails.
You can inspect HTML, view headers, check links, and download attachments. Emails persist based on your retention settings. No process restarts, no lost emails, no screenshots in Slack.
One SMTP config works across local dev, CI, and staging. Everyone on the team sees what's being sent.
Emails are stored temporarily, encrypted, and automatically deleted based on your retention settings.
What migrating away looks like
If your team is currently using MailHog and wants to try a hosted alternative, the migration is straightforward. Here is what changes and what stays the same.
What changes
- • Update MAIL_HOST and MAIL_PORT in your .env (or equivalent config) to point at Sendpit's SMTP endpoint instead of localhost:1025
- • Add MAIL_USERNAME and MAIL_PASSWORD with your Sendpit mailbox credentials
What you can remove
- • The MailHog service from your docker-compose.yml
- • The MailHog Go binary from your system or CI image
- • Any MongoDB service you added solely for MailHog persistence
What you gain
- • Email persistence across restarts and deploys
- • Team access with user accounts and per-mailbox permissions
- • One SMTP config that works in CI, staging, and local dev
- • Search across captured emails
What you lose
- • Offline access — Sendpit requires an internet connection to reach the hosted SMTP endpoint
- • Zero cost at every scale — Sendpit has a free tier, but paid plans for larger teams and higher volumes
- • Jim chaos testing — MailHog's built-in SMTP error simulation is unique and not available in Sendpit
The migration itself takes a few minutes. The decision of whether to migrate depends on whether your team's pain points align with what a hosted solution solves.
Feature comparison
| Feature | MailHog | Sendpit |
|---|---|---|
| SMTP capture | ✓ | ✓ |
| Cloud hosted | — | ✓ |
| Multi-mailbox | — | ✓ |
| Team user accounts | — | ✓ |
| Per-mailbox access control | — | ✓ |
| Webhooks | — | ✓ |
| REST API | ✓ | ✓ |
| TLS encryption | — | ✓ |
| Responsive preview | — | ✓ |
| Spam scoring | — | ✓ |
| Actively maintained | No (since 2020) | ✓ |
| Pricing | Free (self-host) | Free tier + paid |
Choosing the right tool
MailHog makes sense if...
-
You're working alone on your local machine.
-
You don't need emails to persist between sessions.
-
You prefer offline-first, open source tools.
-
Your workflow doesn't involve CI or shared staging.
-
You need Jim chaos testing to simulate SMTP failures.
-
You're comfortable using unmaintained software and can work around known bugs.
Sendpit makes sense if...
-
You need teammates or QA to see the same emails.
-
Your CI pipeline or staging server sends emails.
-
You want emails to persist and be retrievable.
-
You don't want to self-host infrastructure.
-
You want an actively maintained tool with regular updates and security patches.
-
You need separate mailboxes for different projects or environments.
Many teams use both tools for different purposes. MailHog for quick local debugging when you are offline or want zero-latency feedback, and Sendpit for shared environments where the whole team needs visibility. They solve different problems and can coexist in the same workflow.
Comparing other tools? Sendpit vs Mailtrap · Sendpit vs Mailpit · Sendpit vs MailCatcher
Frequently asked questions
Is MailHog still maintained?
MailHog's GitHub repository has not had significant updates in several years. It remains functional for basic SMTP capture, but there are no new features or security patches. If you need an actively maintained solution, Mailpit is the modern open-source successor, and Sendpit is a managed cloud alternative.
Can I migrate from MailHog to Sendpit?
Yes, and the migration is straightforward. Update your SMTP host and port from MailHog's localhost:1025 to Sendpit's SMTP credentials in your application's environment configuration. Add the Sendpit username and password. No code changes required—your application sends email via SMTP the same way.
Does Sendpit work with Docker like MailHog?
MailHog runs as a Docker container on your local machine. Sendpit is a cloud service—you do not need Docker, containers, or any local infrastructure. You point your application's SMTP configuration at Sendpit's server and it captures emails in the cloud. This means your team can share the same test mailbox without running anything locally.
How does Sendpit compare to MailHog for team use?
MailHog is designed for individual developers running it locally. Sharing captured emails between team members requires sharing the same MailHog instance or forwarding ports. Sendpit is designed for teams from the start—create an organization, invite members, and everyone accesses the same captured emails through their own accounts.
Does Sendpit have MailHog's Jim chaos testing?
No. MailHog includes Jim, a chaos monkey that can simulate network failures, rejected connections, and throttled delivery. Sendpit does not offer chaos testing features—it focuses on reliable email capture and inspection. If you depend on Jim for resilience testing, you would need to keep MailHog for that specific use case.
Is Sendpit free like MailHog?
MailHog is completely free and open source with no usage limits. Sendpit has a permanent free tier with generous limits that covers most small team needs. Sendpit's paid plans add more capacity, API access, and webhooks. If budget is the only factor, MailHog costs nothing to run—but you pay in infrastructure and maintenance time.
Try Sendpit free
Sendpit has a free tier that covers most small team needs. Setup is the same as any SMTP tool—update your credentials and start capturing.
If you're outgrowing local tools, the fastest way to know if Sendpit fits is to try it.
No credit card required. Free tier available.