MailHog fonctionne très bien localement.
Et le staging ?
MailHog est un outil fantastique pour capturer des emails sur votre machine locale. Aucune configuration, retour instantané. Mais quand vous avez besoin de visibilité partagée entre environnements—CI, staging, coéquipiers—les outils locaux atteignent leurs limites.
Sendpit est un sandbox SMTP hébergé. Toute votre équipe voit la même boîte de réception, les emails persistent entre les déploiements, et les pipelines CI peuvent envoyer sans configuration locale.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailHog Open-source auto-hébergé
- Pricing and features last verified: 2026-03-18
Ce que MailHog fait bien
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.
Pour les développeurs solitaires déboguant des templates d'email ou testant des flux transactionnels, MailHog est un choix sensé par défaut. C'est gratuit, open source, et ne nécessite ni compte ni connexion internet. Si vous travaillez seul sur votre laptop, il fait exactement ce dont vous avez besoin.
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.
L'outil existe depuis des années et a une base fidèle d'utilisateurs. Il y a une raison pour laquelle les développeurs le recommandent.
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.
Stockage en mémoire
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.
Quand les outils locaux ne scalent plus
"Où sont passés mes emails ?"
MailHog stocke les emails en mémoire. Redémarrez le processus et ils disparaissent.
"Tu peux faire une capture de cet email ?"
Les coéquipiers ne peuvent pas voir votre boîte locale. Le débogage devient un jeu de captures d'écran.
"Ça marche sur ma machine"
Les runners CI et serveurs staging ont besoin de leur propre config SMTP. Les outils locaux ne se transfèrent pas.
"L'équipe QA doit vérifier cet email"
La QA ne peut pas accéder au MailHog local d'un développeur. Les emails envoyés depuis staging disparaissent dans le vide.
Dès que plusieurs personnes travaillent sur le même projet—ou plusieurs environnements envoient des emails—les outils locaux commencent à nécessiter des contournements. Auto-héberger MailHog sur un serveur partagé est possible, mais vous maintenez alors de l'infrastructure.
Un sandbox SMTP hébergé vous donne le même workflow de capture et inspection, mais avec persistance intégrée, accès équipe et zéro gestion d'infrastructure.
Local vs. hébergé
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Les deux capturent les emails. La différence est où vit la boîte et qui peut la voir.
Même workflow, visibilité partagée
La boucle centrale est la même : configurer SMTP, envoyer des emails, inspecter ce qui arrive. La différence est que la boîte de Sendpit est hébergée, donc votre serveur staging, runner CI et coéquipiers voient tous les mêmes emails.
Vous pouvez inspecter le HTML, voir les en-têtes, vérifier les liens et télécharger les pièces jointes. Les emails persistent selon vos paramètres de rétention. Pas de redémarrages de processus, pas d'emails perdus, pas de captures d'écran dans Slack.
Une config SMTP fonctionne à travers le dev local, CI et staging. Tout le monde dans l'équipe voit ce qui est envoyé.
Les emails sont stockés temporairement, chiffrés et automatiquement supprimés selon vos paramètres de rétention.
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.
Comparaison des fonctionnalités
| Fonctionnalité | MailHog | Sendpit |
|---|---|---|
| Capture SMTP | ✓ | ✓ |
| Hébergé dans le cloud | — | ✓ |
| Multi-boîtes mail | — | ✓ |
| Comptes d'équipe | — | ✓ |
| Contrôle d'accès par boîte mail | — | ✓ |
| Webhooks | — | ✓ |
| REST API | ✓ | ✓ |
| Chiffrement TLS | — | ✓ |
| Aperçu responsive | — | ✓ |
| Score de spam | — | ✓ |
| Activement maintenu | Non (depuis 2020) | ✓ |
| Tarifs | Gratuit (auto-hébergé) | Plan gratuit + payant |
Choosing the right tool
MailHog a du sens si...
-
Vous travaillez seul sur votre machine locale.
-
Vous n'avez pas besoin que les emails persistent entre les sessions.
-
Vous préférez les outils offline-first, open source.
-
Votre workflow n'implique pas de CI ou staging partagé.
-
You need Jim chaos testing to simulate SMTP failures.
-
You're comfortable using unmaintained software and can work around known bugs.
Sendpit a du sens si...
-
Vous avez besoin que les coéquipiers ou la QA voient les mêmes emails.
-
Votre pipeline CI ou serveur staging envoie des emails.
-
Vous voulez que les emails persistent et soient récupérables.
-
Vous ne voulez pas auto-héberger d'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
MailHog est-il encore maintenu ?
Le dépôt GitHub de MailHog n'a pas reçu de mises à jour significatives depuis plusieurs années. Il reste fonctionnel pour la capture SMTP basique, mais il n'y a ni nouvelles fonctionnalités ni correctifs de sécurité. Si vous avez besoin d'une solution activement maintenue, Mailpit est le successeur open source moderne, et Sendpit est une alternative cloud gérée.
Puis-je migrer de MailHog vers Sendpit ?
Oui, et la migration est simple. Mettez à jour l'hôte et le port SMTP depuis le localhost:1025 de MailHog vers les identifiants SMTP de Sendpit dans la configuration d'environnement de votre application. Ajoutez le nom d'utilisateur et le mot de passe Sendpit. Aucune modification de code requise — votre application envoie les e-mails via SMTP de la même manière.
Sendpit fonctionne-t-il avec Docker comme MailHog ?
MailHog tourne dans un conteneur Docker sur votre machine locale. Sendpit est un service cloud — vous n'avez pas besoin de Docker, de conteneurs ni d'infrastructure locale. Vous pointez la configuration SMTP de votre application vers le serveur de Sendpit et celui-ci capture les e-mails dans le cloud. Cela signifie que votre équipe peut partager la même boîte aux lettres de test sans rien installer localement.
Comment Sendpit se compare-t-il à MailHog pour l'utilisation en équipe ?
MailHog est conçu pour les développeurs individuels qui l'utilisent localement. Partager les e-mails capturés entre les membres d'une équipe nécessite de partager la même instance MailHog ou de rediriger les ports. Sendpit est conçu pour les équipes dès le départ — créez une organisation, invitez des membres et chacun accède aux mêmes e-mails capturés via son propre compte.
Sendpit dispose-t-il du test de chaos Jim de MailHog ?
Non. MailHog inclut Jim, un chaos monkey qui peut simuler des pannes réseau, des connexions rejetées et des livraisons ralenties. Sendpit ne propose pas de fonctionnalités de test de chaos — il se concentre sur la capture et l'inspection fiables des e-mails. Si vous dépendez de Jim pour les tests de résilience, vous devrez conserver MailHog pour ce cas d'usage spécifique.
Sendpit est-il gratuit comme MailHog ?
MailHog est entièrement gratuit et open source sans aucune limite d'utilisation. Sendpit dispose d'un forfait gratuit permanent avec des limites généreuses qui couvrent les besoins de la plupart des petites équipes. Les forfaits payants de Sendpit ajoutent plus de capacité, l'accès API et les webhooks. Si le budget est le seul facteur, MailHog ne coûte rien — mais vous payez en temps d'infrastructure et de maintenance.
Try Sendpit free
Sendpit a un niveau gratuit qui couvre la plupart des besoins des petites équipes. La configuration est la même que tout outil SMTP—mettez à jour vos identifiants et commencez à capturer.
Si vous dépassez les outils locaux, le moyen le plus rapide de savoir si Sendpit convient est de l'essayer.
Pas de carte de crédit requise. Niveau gratuit disponible.