MailHog funktioniert lokal großartig.
Was ist mit Staging?
MailHog ist ein fantastisches Werkzeug zum Erfassen von E-Mails auf deinem lokalen Rechner. Keine Einrichtung, sofortiges Feedback. Aber wenn du gemeinsame Sichtbarkeit über Umgebungen hinweg brauchst—CI, Staging, Teammitglieder—stoßen lokale Tools an ihre Grenzen.
Sendpit ist eine gehostete SMTP-Sandbox. Dein ganzes Team sieht denselben Posteingang, E-Mails bleiben zwischen Deployments erhalten, und CI-Pipelines können ohne lokale Konfiguration senden.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailHog Selbstgehostet Open-Source
- Pricing and features last verified: 2026-03-18
Was MailHog gut macht
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.
Für Solo-Entwickler, die E-Mail-Templates debuggen oder transaktionale Flows testen, ist MailHog eine sinnvolle Standardwahl. Es ist kostenlos, Open Source und erfordert weder ein Konto noch eine Internetverbindung. Wenn du allein auf deinem Laptop arbeitest, macht es genau das, was du brauchst.
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.
Das Tool existiert seit Jahren und hat eine treue Anhängerschaft. Es gibt einen Grund, warum Entwickler es empfehlen.
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-Speicher
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.
Wenn lokale Tools nicht mehr skalieren
"Wo sind meine E-Mails hin?"
MailHog speichert E-Mails im Arbeitsspeicher. Starte den Prozess neu und sie sind weg.
"Kannst du diese E-Mail screenshotten?"
Teammitglieder können deinen lokalen Posteingang nicht sehen. Debugging wird zu einem Screenshot-Spiel.
"Bei mir funktioniert's"
CI-Runner und Staging-Server brauchen ihre eigene SMTP-Konfiguration. Lokale Tools lassen sich nicht übertragen.
"Das QA-Team muss diese E-Mail überprüfen"
QA kann nicht auf das lokale MailHog eines Entwicklers zugreifen. E-Mails von Staging verschwinden im Nichts.
Sobald mehrere Leute am selben Projekt arbeiten—oder mehrere Umgebungen E-Mails senden—erfordern lokale Tools Workarounds. MailHog selbst auf einem gemeinsamen Server zu hosten ist möglich, aber dann wartest du Infrastruktur.
Eine gehostete SMTP-Sandbox bietet dir denselben Erfassen-und-Prüfen-Workflow, aber mit eingebauter Persistenz, Teamzugriff und null Infrastruktur-Management.
Lokal vs. gehostet
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Beide erfassen E-Mails. Der Unterschied ist, wo der Posteingang lebt und wer ihn sehen kann.
Gleicher Workflow, gemeinsame Sichtbarkeit
Der Kernablauf ist derselbe: SMTP konfigurieren, E-Mails senden, prüfen was ankommt. Der Unterschied ist, dass Sendpits Posteingang gehostet ist, so dass dein Staging-Server, CI-Runner und Teammitglieder alle dieselben E-Mails sehen.
Du kannst HTML prüfen, Header ansehen, Links überprüfen und Anhänge herunterladen. E-Mails bleiben gemäß deinen Aufbewahrungseinstellungen erhalten. Keine Prozess-Neustarts, keine verlorenen E-Mails, keine Screenshots in Slack.
Eine SMTP-Konfiguration funktioniert über lokale Entwicklung, CI und Staging hinweg. Jeder im Team sieht, was gesendet wird.
E-Mails werden temporär gespeichert, verschlüsselt und automatisch gemäß deinen Aufbewahrungseinstellungen gelöscht.
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.
Funktionsvergleich
| Funktion | MailHog | Sendpit |
|---|---|---|
| SMTP-Erfassung | ✓ | ✓ |
| Cloud-gehostet | — | ✓ |
| Multi-Postfach | — | ✓ |
| Team-Benutzerkonten | — | ✓ |
| Zugriffskontrolle pro Postfach | — | ✓ |
| Webhooks | — | ✓ |
| REST API | ✓ | ✓ |
| TLS-Verschlüsselung | — | ✓ |
| Responsive Vorschau | — | ✓ |
| Spam-Bewertung | — | ✓ |
| Aktiv gepflegt | Nein (seit 2020) | ✓ |
| Preise | Kostenlos (selbst gehostet) | Kostenloser Plan + bezahlt |
Choosing the right tool
MailHog macht Sinn, wenn...
-
Du allein auf deinem lokalen Rechner arbeitest.
-
Du keine E-Mail-Persistenz zwischen Sitzungen brauchst.
-
Du Offline-First, Open-Source-Tools bevorzugst.
-
Dein Workflow kein CI oder gemeinsames Staging beinhaltet.
-
You need Jim chaos testing to simulate SMTP failures.
-
You're comfortable using unmaintained software and can work around known bugs.
Sendpit macht Sinn, wenn...
-
Teammitglieder oder QA dieselben E-Mails sehen müssen.
-
Deine CI-Pipeline oder dein Staging-Server E-Mails sendet.
-
Du möchtest, dass E-Mails persistent und abrufbar sind.
-
Du keine Infrastruktur selbst hosten willst.
-
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
Wird MailHog noch gepflegt?
Das GitHub-Repository von MailHog hat seit mehreren Jahren keine wesentlichen Updates erhalten. Es bleibt für einfaches SMTP-Auffangen funktionsfähig, aber es gibt keine neuen Funktionen oder Sicherheitspatches. Wenn du eine aktiv gepflegte Lösung brauchst, ist Mailpit der moderne Open-Source-Nachfolger und Sendpit eine verwaltete Cloud-Alternative.
Kann ich von MailHog zu Sendpit wechseln?
Ja, und die Migration ist unkompliziert. Aktualisiere deinen SMTP-Host und Port von MailHogs localhost:1025 auf die SMTP-Zugangsdaten von Sendpit in der Umgebungskonfiguration deiner Anwendung. Füge den Sendpit-Benutzernamen und das Passwort hinzu. Keine Codeänderungen nötig – deine Anwendung versendet E-Mails über SMTP wie gewohnt.
Funktioniert Sendpit mit Docker wie MailHog?
MailHog läuft als Docker-Container auf deinem lokalen Rechner. Sendpit ist ein Cloud-Dienst – du brauchst kein Docker, keine Container und keine lokale Infrastruktur. Du verweist die SMTP-Konfiguration deiner Anwendung auf den Server von Sendpit und es erfasst E-Mails in der Cloud. Das bedeutet, dein Team kann dasselbe Test-Postfach teilen, ohne lokal etwas einzurichten.
Wie schneidet Sendpit im Vergleich zu MailHog für Teams ab?
MailHog ist für einzelne Entwickler gedacht, die es lokal betreiben. Das Teilen erfasster E-Mails zwischen Teammitgliedern erfordert die gemeinsame Nutzung derselben MailHog-Instanz oder Portweiterleitung. Sendpit ist von Anfang an für Teams konzipiert – erstelle eine Organisation, lade Mitglieder ein, und alle greifen über ihre eigenen Konten auf dieselben erfassten E-Mails zu.
Hat Sendpit das Jim-Chaos-Testing von MailHog?
Nein. MailHog enthält Jim, einen Chaos Monkey, der Netzwerkausfälle, abgelehnte Verbindungen und gedrosselte Zustellung simulieren kann. Sendpit bietet keine Chaos-Testing-Funktionen – es konzentriert sich auf zuverlässiges E-Mail-Auffangen und Prüfen. Wenn du auf Jim für Resilienztests angewiesen bist, müsstest du MailHog für diesen speziellen Anwendungsfall behalten.
Ist Sendpit kostenlos wie MailHog?
MailHog ist vollständig kostenlos und Open Source ohne Nutzungslimits. Sendpit hat einen dauerhaft kostenlosen Tarif mit großzügigen Limits, der die meisten Bedürfnisse kleiner Teams abdeckt. Die Bezahltarife von Sendpit bieten mehr Kapazität, API-Zugang und Webhooks. Wenn das Budget der einzige Faktor ist, kostet MailHog nichts im Betrieb – aber du bezahlst mit Infrastruktur- und Wartungsaufwand.
Try Sendpit free
Sendpit hat eine kostenlose Stufe, die die meisten Bedürfnisse kleiner Teams abdeckt. Die Einrichtung ist wie bei jedem SMTP-Tool—aktualisiere deine Zugangsdaten und fang an zu erfassen.
Wenn du lokale Tools entwächst, ist der schnellste Weg zu wissen, ob Sendpit passt, es auszuprobieren.
Keine Kreditkarte erforderlich. Kostenlose Stufe verfügbar.