MailHog funciona muy bien localmente.
¿Y qué hay del staging?
MailHog es una herramienta fantástica para capturar emails en tu máquina local. Sin configuración, retroalimentación instantánea. Pero cuando necesitas visibilidad compartida entre entornos—CI, staging, compañeros de equipo—las herramientas locales alcanzan sus límites.
Sendpit es un sandbox SMTP alojado. Todo tu equipo ve la misma bandeja de entrada, los emails persisten entre despliegues, y los pipelines de CI pueden enviar sin configuración local.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailHog Código abierto autoalojado
- Pricing and features last verified: 2026-03-18
Lo que MailHog hace 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.
Para desarrolladores en solitario depurando plantillas de email o probando flujos transaccionales, MailHog es una opción sensata por defecto. Es gratis, código abierto, y no requiere cuenta ni conexión a internet. Si trabajas solo en tu laptop, hace exactamente lo que necesitas.
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.
La herramienta ha existido por años y tiene seguidores leales. Hay una razón por la que los desarrolladores la recomiendan.
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.
Almacenamiento en memoria
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.
Cuando las herramientas locales dejan de escalar
"¿Dónde están mis emails?"
MailHog almacena emails en memoria. Reinicia el proceso y desaparecen.
"¿Puedes capturar ese email?"
Los compañeros no pueden ver tu bandeja local. La depuración se convierte en un juego de capturas de pantalla.
"Funciona en mi máquina"
Los runners de CI y servidores de staging necesitan su propia configuración SMTP. Las herramientas locales no se transfieren.
"El equipo de QA necesita verificar ese email"
QA no puede acceder al MailHog local de un desarrollador. Los emails enviados desde staging desaparecen en el vacío.
En el momento en que tienes múltiples personas trabajando en el mismo proyecto—o múltiples entornos enviando emails—las herramientas locales empiezan a requerir soluciones alternativas. Auto-alojar MailHog en un servidor compartido es posible, pero entonces estás manteniendo infraestructura.
Un sandbox SMTP alojado te da el mismo flujo de captura e inspección, pero con persistencia incorporada, acceso de equipo y cero gestión de infraestructura.
Local vs. alojado
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Ambos capturan emails. La diferencia es dónde vive la bandeja y quién puede verla.
Mismo flujo, visibilidad compartida
El bucle central es el mismo: configurar SMTP, enviar emails, inspeccionar lo que llega. La diferencia es que la bandeja de Sendpit está alojada, así que tu servidor de staging, runner de CI y compañeros de equipo ven los mismos emails.
Puedes inspeccionar HTML, ver cabeceras, verificar enlaces y descargar adjuntos. Los emails persisten según tu configuración de retención. Sin reinicios de procesos, sin emails perdidos, sin capturas en Slack.
Una configuración SMTP funciona en desarrollo local, CI y staging. Todos en el equipo ven lo que se está enviando.
Los emails se almacenan temporalmente, cifrados, y se eliminan automáticamente según tu configuración de retención.
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.
Comparación de funcionalidades
| Función | MailHog | Sendpit |
|---|---|---|
| Captura SMTP | ✓ | ✓ |
| Alojado en la nube | — | ✓ |
| Múltiples buzones | — | ✓ |
| Cuentas de equipo | — | ✓ |
| Control de acceso por buzón | — | ✓ |
| Webhooks | — | ✓ |
| REST API | ✓ | ✓ |
| Cifrado TLS | — | ✓ |
| Vista previa responsiva | — | ✓ |
| Puntuación de spam | — | ✓ |
| Mantenimiento activo | No (desde 2020) | ✓ |
| Precios | Gratis (autoalojado) | Plan gratuito + pago |
Choosing the right tool
MailHog tiene sentido si...
-
Trabajas solo en tu máquina local.
-
No necesitas que los emails persistan entre sesiones.
-
Prefieres herramientas offline-first, de código abierto.
-
Tu flujo de trabajo no involucra CI o staging compartido.
-
You need Jim chaos testing to simulate SMTP failures.
-
You're comfortable using unmaintained software and can work around known bugs.
Sendpit tiene sentido si...
-
Necesitas que compañeros o QA vean los mismos emails.
-
Tu pipeline de CI o servidor de staging envía emails.
-
Quieres que los emails persistan y sean recuperables.
-
No quieres auto-alojar infraestructura.
-
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 todavía se mantiene?
El repositorio de GitHub de MailHog no ha tenido actualizaciones significativas en varios años. Sigue funcionando para captura SMTP básica, pero no hay nuevas funciones ni parches de seguridad. Si necesitas una solución mantenida activamente, Mailpit es el sucesor moderno de código abierto, y Sendpit es una alternativa gestionada en la nube.
¿Puedo migrar de MailHog a Sendpit?
Sí, y la migración es sencilla. Actualiza el host y puerto SMTP de localhost:1025 de MailHog a las credenciales SMTP de Sendpit en la configuración de entorno de tu aplicación. Añade el usuario y contraseña de Sendpit. No se requieren cambios de código: tu aplicación envía correo por SMTP de la misma manera.
¿Sendpit funciona con Docker como MailHog?
MailHog se ejecuta como un contenedor Docker en tu máquina local. Sendpit es un servicio en la nube: no necesitas Docker, contenedores ni ninguna infraestructura local. Apuntas la configuración SMTP de tu aplicación al servidor de Sendpit y captura correos en la nube. Esto significa que tu equipo puede compartir el mismo buzón de prueba sin ejecutar nada localmente.
¿Cómo se compara Sendpit con MailHog para uso en equipo?
MailHog está diseñado para desarrolladores individuales que lo ejecutan localmente. Compartir correos capturados entre miembros del equipo requiere compartir la misma instancia de MailHog o redirigir puertos. Sendpit está diseñado para equipos desde el inicio: crea una organización, invita miembros y todos acceden a los mismos correos capturados a través de sus propias cuentas.
¿Sendpit tiene las pruebas de caos Jim de MailHog?
No. MailHog incluye Jim, un mono de caos que puede simular fallos de red, conexiones rechazadas y entrega limitada. Sendpit no ofrece funciones de pruebas de caos; se enfoca en la captura e inspección confiable de correos. Si dependes de Jim para pruebas de resiliencia, necesitarías mantener MailHog para ese caso de uso específico.
¿Sendpit es gratis como MailHog?
MailHog es completamente gratis y de código abierto sin límites de uso. Sendpit tiene un plan gratuito permanente con límites generosos que cubren la mayoría de las necesidades de equipos pequeños. Los planes de pago de Sendpit añaden más capacidad, acceso API y webhooks. Si el presupuesto es el único factor, MailHog no cuesta nada de ejecutar, pero pagas en tiempo de infraestructura y mantenimiento.
Try Sendpit free
Sendpit tiene un nivel gratuito que cubre la mayoría de las necesidades de equipos pequeños. La configuración es la misma que cualquier herramienta SMTP—actualiza tus credenciales y empieza a capturar.
Si estás superando las herramientas locales, la forma más rápida de saber si Sendpit encaja es probarlo.
No se requiere tarjeta de crédito. Nivel gratuito disponible.