Your team needs an SMTP testing server. You have two paths: spin up MailHog OSS (or Mailpit, or MailCatcher) on your own infrastructure, or use a hosted service. This post gives you a fair comparison so you can make the right call for your team.
Full disclosure: We build MailHog.site, a hosted email testing service. We have a commercial interest in this comparison. We're going to be honest anyway — because the right answer depends on your team, and pretending otherwise would waste your time.
When Self-Hosting Wins
Self-hosting is the right choice for specific situations:
- Air-gapped environments. If your dev/staging environment can't reach the internet (defense, healthcare, finance compliance), a local SMTP server is your only option.
- Data residency requirements. If regulations prohibit sending test data — even captured email — to a third-party service, self-hosting keeps everything in your infrastructure.
- Single-developer projects. If you're the only engineer, running
docker run -p 1025:1025 -p 8025:8025 mailhog/mailhogis genuinely the fastest path. No signup, no credentials, done. - Strong DevOps muscle. If your team already runs complex infrastructure and adding another Docker container is trivial, the ops burden is low.
When Hosted Wins
Hosted services solve problems that self-hosting creates:
- Shared environments. When 15 developers need to inspect captured emails from staging, a hosted dashboard with auth and multi-user access beats "SSH into the box and check the UI."
- Branch-per-environment workflows. If your CI creates ephemeral environments per PR, each needs SMTP credentials. A hosted service with multiple inboxes handles this natively.
- Zero ops. No Docker to maintain, no storage to monitor, no port conflicts, no "the MailHog container died and nobody noticed for three days."
- Built-in analysis. Self-hosted MailHog OSS captures email and shows it. That's it. No spam scoring, no HTML compatibility checks, no API for CI assertions.
Cost Comparison
| Self-Hosted | Hosted (MailHog.site) | |
|---|---|---|
| Infrastructure | $5–20/mo (VPS or extra container resources) | $0 (Free tier) to $29/mo |
| Engineer time | 2–4 hrs/month at fully-loaded cost | 0 hrs/month |
| On-call risk | Another service to monitor | None — provider's SLA |
| Setup time | 30 min to 2 hrs (DNS, Docker, firewall) | 2 minutes (signup + config change) |
| Spam analysis | Not included — need rspamd separately | Built-in |
| HTML checks | Not included | Built-in |
| REST API | Basic (MailHog OSS v2 API) | Full — CI assertions, webhook triggers |
The Migration Path
Switching between self-hosted and hosted is a config change — literally two environment variables:
# Before: self-hosted MailHog OSS
-SMTP_HOST=localhost
-SMTP_PORT=1025
# After: MailHog.site hosted
+SMTP_HOST=smtp.mailhog.site
+SMTP_PORT=2525
+SMTP_USER=your_inbox_username
+SMTP_PASS=your_inbox_passwordThe only addition is authentication — hosted services require SMTP auth, while local MailHog OSS typically runs without credentials.
For a detailed comparison of MailHog OSS vs MailHog.site specifically, see our dedicated comparison page.
Our Honest Take
If you're a solo developer working on a side project, self-hosting is the right answer. Run it locally, don't pay for anything, move fast.
If you're on a team of 3+ engineers sharing a staging environment, the ops burden of self-hosting typically costs more in engineer time than a hosted subscription saves. The analysis features (spam scoring, HTML checks) are a bonus, but the real value is zero maintenance.
Check our pricing and our security posture if you're evaluating.
FAQ
Is MailHog.site the same as MailHog OSS?
No. MailHog OSS is an open-source project (github.com/mailhog/MailHog) that provides a local SMTP testing server. MailHog.site is a separate hosted service with additional features like spam scoring, HTML compatibility checks, and multi-user access. They share a name but are different products.
Can I migrate from MailHog OSS to MailHog.site without changing my app code?
Almost. You change two environment variables (SMTP host and port) and add two more (username and password for SMTP auth). No code changes are needed if your mailer library supports those config options — which all major libraries do.
What if I need both — local testing and hosted staging?
This is common. Use MailHog OSS (or Mailpit) locally for fast iteration, and MailHog.site for shared staging and CI environments. Your app reads SMTP config from environment variables, so each environment just points to the right server.