MailHog werkt prima lokaal.
En staging dan?
MailHog is een fantastische tool voor het opvangen van e-mails op je lokale machine. Geen setup, directe feedback. Maar wanneer je gedeelde zichtbaarheid nodig hebt over omgevingen heen—CI, staging, teamgenoten—bereiken lokale tools hun grenzen.
Sendpit is een gehoste SMTP-sandbox. Je hele team ziet dezelfde inbox, e-mails blijven bestaan tussen deploys, en CI-pipelines kunnen versturen zonder lokale configuratie.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailHog Zelfgehost open-source
- Pricing and features last verified: 2026-03-18
Wat MailHog goed doet
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.
Voor solo-ontwikkelaars die e-mailtemplates debuggen of transactionele flows testen, is MailHog een verstandige standaard. Het is gratis, open source, en vereist geen account of internetverbinding. Als je alleen op je laptop werkt, doet het precies wat je nodig hebt.
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.
De tool bestaat al jaren en heeft een trouwe aanhang. Er is een reden waarom ontwikkelaars het aanbevelen.
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 opslag
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.
Wanneer lokale tools niet meer schalen
"Waar zijn mijn e-mails gebleven?"
MailHog slaat e-mails op in het geheugen. Herstart het proces en ze zijn weg.
"Kun je die e-mail screenshotten?"
Teamgenoten kunnen je lokale inbox niet zien. Debugging wordt een spel van screenshots.
"Het werkt op mijn machine"
CI-runners en staging-servers hebben hun eigen SMTP-config nodig. Lokale tools zijn niet overdraagbaar.
"Het QA-team moet die e-mail verifiëren"
QA kan geen toegang krijgen tot de lokale MailHog van een ontwikkelaar. E-mails verstuurd vanaf staging verdwijnen in het niets.
Zodra meerdere mensen aan hetzelfde project werken—of meerdere omgevingen e-mails versturen—vereisen lokale tools workarounds. MailHog zelf hosten op een gedeelde server is mogelijk, maar dan onderhoud je infrastructuur.
Een gehoste SMTP-sandbox geeft je dezelfde vang-en-inspecteer workflow, maar met ingebouwde persistentie, teamtoegang en nul infrastructuurbeheer.
Lokaal vs. gehost
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Beide vangen e-mails. Het verschil is waar de inbox leeft en wie hem kan zien.
Zelfde workflow, gedeelde zichtbaarheid
De kernloop is dezelfde: configureer SMTP, verstuur e-mails, inspecteer wat aankomt. Het verschil is dat Sendpits inbox gehost is, dus je staging-server, CI-runner en teamgenoten zien allemaal dezelfde e-mails.
Je kunt HTML inspecteren, headers bekijken, links controleren en bijlagen downloaden. E-mails blijven bestaan op basis van je bewaringsinstellingen. Geen proces herstarts, geen verloren e-mails, geen screenshots in Slack.
Eén SMTP-config werkt over lokale dev, CI en staging. Iedereen in het team ziet wat er verstuurd wordt.
E-mails worden tijdelijk opgeslagen, versleuteld en automatisch verwijderd op basis van je bewaringsinstellingen.
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.
Functievergelijking
| Functie | MailHog | Sendpit |
|---|---|---|
| SMTP-opvang | ✓ | ✓ |
| Cloud-gehost | — | ✓ |
| Meerdere mailboxen | — | ✓ |
| Teamgebruikersaccounts | — | ✓ |
| Toegangsbeheer per mailbox | — | ✓ |
| Webhooks | — | ✓ |
| REST API | ✓ | ✓ |
| TLS-versleuteling | — | ✓ |
| Responsieve preview | — | ✓ |
| Spamscore | — | ✓ |
| Actief onderhouden | Nee (sinds 2020) | ✓ |
| Prijzen | Gratis (zelf hosten) | Gratis plan + betaald |
Choosing the right tool
MailHog is logisch als...
-
Je alleen op je lokale machine werkt.
-
Je geen e-mail persistentie tussen sessies nodig hebt.
-
Je de voorkeur geeft aan offline-first, open source tools.
-
Je workflow geen CI of gedeelde staging bevat.
-
You need Jim chaos testing to simulate SMTP failures.
-
You're comfortable using unmaintained software and can work around known bugs.
Sendpit is logisch als...
-
Je teamgenoten of QA dezelfde e-mails moet zien.
-
Je CI-pipeline of staging-server e-mails verstuurt.
-
Je wilt dat e-mails blijven bestaan en opvraagbaar zijn.
-
Je geen infrastructuur zelf wilt hosten.
-
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
Wordt MailHog nog onderhouden?
De GitHub-repository van MailHog heeft al meerdere jaren geen significante updates gehad. Het blijft functioneel voor basis-SMTP-opvang, maar er zijn geen nieuwe functies of beveiligingspatches. Als je een actief onderhouden oplossing nodig hebt, is Mailpit de moderne open-source opvolger en Sendpit een beheerd cloudalternatief.
Kan ik migreren van MailHog naar Sendpit?
Ja, en de migratie is eenvoudig. Werk je SMTP-host en poort bij van MailHog's localhost:1025 naar de SMTP-inloggegevens van Sendpit in de omgevingsconfiguratie van je applicatie. Voeg de Sendpit-gebruikersnaam en het wachtwoord toe. Geen codewijzigingen nodig — je applicatie verstuurt e-mail via SMTP op dezelfde manier.
Werkt Sendpit met Docker zoals MailHog?
MailHog draait als een Docker-container op je lokale machine. Sendpit is een clouddienst — je hebt geen Docker, containers of lokale infrastructuur nodig. Je verwijst de SMTP-configuratie van je applicatie naar de server van Sendpit en het vangt e-mails op in de cloud. Dit betekent dat je team dezelfde testmailbox kan delen zonder iets lokaal te draaien.
Hoe verhoudt Sendpit zich tot MailHog voor teamgebruik?
MailHog is ontworpen voor individuele ontwikkelaars die het lokaal draaien. Het delen van opgevangen e-mails tussen teamleden vereist het delen van dezelfde MailHog-instantie of het doorsturen van poorten. Sendpit is vanaf het begin ontworpen voor teams — maak een organisatie aan, nodig leden uit en iedereen heeft toegang tot dezelfde opgevangen e-mails via hun eigen account.
Heeft Sendpit de Jim-chaostestfunctie van MailHog?
Nee. MailHog bevat Jim, een chaos monkey die netwerkfouten, geweigerde verbindingen en vertraagde aflevering kan simuleren. Sendpit biedt geen chaostestfuncties — het richt zich op betrouwbare e-mailopvang en -inspectie. Als je afhankelijk bent van Jim voor weerbaarheidstesten, moet je MailHog voor die specifieke use case behouden.
Is Sendpit gratis zoals MailHog?
MailHog is volledig gratis en open source zonder gebruikslimieten. Sendpit heeft een permanente gratis laag met ruime limieten die de meeste kleine teams dekken. De betaalde abonnementen van Sendpit voegen meer capaciteit, API-toegang en webhooks toe. Als budget de enige factor is, kost MailHog niets om te draaien — maar je betaalt in infrastructuur- en onderhoudstijd.
Try Sendpit free
Sendpit heeft een gratis tier die de meeste kleine team behoeften dekt. Setup is hetzelfde als elke SMTP-tool—update je inloggegevens en begin met vangen.
Als je lokale tools ontgroeit, is de snelste manier om te weten of Sendpit past het uit te proberen.
Geen creditcard vereist. Gratis tier beschikbaar.