MailHog

Last reviewed Aug 26, 2026 · 871 words

MailHog does one thing, does it in a 64 MB single-binary Go container, and has not needed to change to keep doing it: point your application's SMTP settings at port 1025, open port 8025 in a browser, and every message the app would have sent is sitting in a web inbox with its raw source, a JSON API and a chaos monkey called Jim. The honest caveat is that the project has been effectively unmaintained since its last tagged release in 2020, and its successor Mailpit runs on the same two ports with an HTML preview and multi-architecture images. The practical question in 2026 is not whether MailHog works, because it does, but whether to start anything new with it.

Two ports and nothing to configure

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - "1025:1025"
      - "8025:8025"

Inside the Compose network the application uses host mailhog, port 1025, no authentication and no TLS. In Django that is EMAIL_HOST = "mailhog" and EMAIL_PORT = 1025; in Laravel it is MAIL_HOST and MAIL_PORT; every framework has the equivalent. Messages are held in memory by default and vanish on restart, which is usually what you want in development. For a shared staging box set MH_STORAGE=maildir and MH_MAILDIR_PATH=/maildir with a volume, and the inbox survives. That is close to the complete list of settings, and it is why MailHog shows up in so many project READMEs: there is nothing to get wrong.

The API is the point in CI

The web UI is for humans. The reason MailHog earned 16,139 stars is that integration tests can ask it what was sent:

curl -s http://mailhog:8025/api/v2/messages | jq '.items[0].Content.Headers.Subject[0]'
curl -s "http://mailhog:8025/api/v2/search?kind=to&[email protected]" | jq '.count'
curl -s -X DELETE http://mailhog:8025/api/v1/messages

Assert the password-reset mail went to the right address with the right subject, pull the link out of the body with a regular expression, clear the inbox between tests. The v2 message format is a little awkward (headers are arrays, bodies are MIME-split), but it is stable, which is the one benefit of software that stopped changing. Tools such as smtp4dev offer the same idea with different APIs; the reason to stay on MailHog is the test code you have already written against this one.

Jim breaks things on purpose

Chaos testing is the feature people forget. Start the container with -invite-jim and MailHog begins randomly rejecting connections, refusing senders and recipients, disconnecting mid-session and throttling link speed, each with its own probability flag such as -jim-accept=0.9 or -jim-reject-recipient=0.2. Point a job queue at it and you find out in an afternoon whether your retry and dead-letter handling works, which is a question that is otherwise answered in production at 3 a.m. Mailpit has no equivalent; this is the one thing MailHog still does that its replacement does not.

Unmaintained, and what that costs here

Stalled development matters less for a tool that never touches the internet. The risk profile is a Go binary on a private Docker network receiving mail from your own application, and the old dependencies inside it are not reachable by anyone who should not already be on that network. The costs are practical rather than security-related. There is no official ARM64 image, so on Apple Silicon or a Raspberry Pi the container runs under emulation or from a community build. HTML mail is shown as source or in a bare frame rather than rendered. And nobody will fix anything, so the bug you hit is the bug you keep. Never expose it publicly; the optional MH_AUTH_FILE with bcrypt entries protects the UI, but there is no reason to test that boundary.

For actual outbound mail from a homelab the answer is a completely different tool, and the self-hosted email piece explains why development capture and production delivery should never share a container.

Mailpit is the drop-in swap

Change mailhog/mailhog to axllent/mailpit and leave the ports alone. SMTP is still 1025, the UI is still 8025, applications need no changes, and you gain rendered HTML previews, a persistent SQLite store, an SMTP relay for forwarding selected mail onward, and images for every architecture. What breaks is test code: Mailpit's API is a v1 with a different message shape, so any CI assertions written against /api/v2/messages need rewriting. That is a contained afternoon, and it is the entire cost of migrating. The rest of the email category is for people who need mail delivered rather than caught.

What I'd do

New projects start on Mailpit, same two ports, and never learn the MailHog API. Existing projects with a MailHog container and tests that query it stay put, because the software is frozen rather than broken, and get swapped the next time someone is already editing the test suite. Keep Jim in mind for the day you want to see your mail queue fail gracefully; it is worth a temporary MailHog container for that alone.