Skip to content

Mailpit and MailHog: local tools vs Mailexam for teams

MailHog and Mailpit are popular local tools for catching outbound mail in development. They run on your machine or in Docker, accept SMTP on localhost, and show messages in a web UI. For a solo developer on a laptop, that is convenient and free.

Mailexam solves the same core problem — a test SMTP inbox instead of real recipients — but as a cloud service built for collaboration: a shared inbox for the team, access from CI/CD and staging without tunnels, and an API for automated tests. It fits distributed teams, including international ones, when developers, QA, and DevOps work from different offices and time zones.

At a glance

MailHog Mailpit Mailexam
Model Local process / container Local process / container Cloud SaaS
Audience One developer on one machine One developer on one machine Team, CI/CD, QA
Shared inbox No — inbox lives on that host No — inbox lives on that host Yes — one project, shared access
Access from CI/CD Only if the runner is on the same machine Same Yes — SMTP and API from any runner
Access for teammates SSH, screen share, port forwarding Same Browser and API with credentials
Accounts and roles No No Account, projects, API tokens
History after restart Lost (by default) Configurable locally Stored in the cloud
API for automated tests Limited (MailHog) / yes (Mailpit) REST API REST API

Not «worse» or «better»

Mailpit and MailHog are a great fit for personal debugging on a laptop. Mailexam is for when several people or remote systems (CI, staging, a colleague in another city) need to see the same messages without networking workarounds.

Who Mailpit and MailHog are for

Local catchers work well in the «just me, writing code, checking mail nearby» scenario:

  • quick start via docker run or a binary, no signup;
  • full control over data on your own disk;
  • no dependency on an external service;
  • enough to verify a template, layout, or SMTP integration on your machine.

In practice they are single-user tools: the inbox lives wherever the process runs. Someone else cannot open your Mailpit unless you forward a port, set up VPN access, and explain which host to use.

Where local tools hit a ceiling

Once a team is involved, common pain points look like this:

1. «The message is on my laptop, QA cannot see it»

A developer sends a test email — it lands in local Mailpit. A tester in another office (or on another continent) cannot open the same inbox: they have a different machine, a different localhost. Screenshots, calls, and «paste the link from the email in Slack» become the workflow.

2. CI/CD and shared runners

In a pipeline, mail goes to 127.0.0.1:1025. On a shared CI runner (GitLab, GitHub Actions, Jenkins) there is no Mailpit next to your app — or it belongs to another job and is wiped after the build. To assert on email in CI you end up running Mailpit in the same job, parsing its API, or mocking delivery — all of which complicate the pipeline.

3. Staging and multiple environments

Staging, preview, and local dev are three different hosts and three different local inboxes (if configured at all). There is no single place where QA reviews «all test mail for the project». Comparing behavior across environments is harder.

4. International and distributed teams

When the team spans Moscow, Berlin, and Singapore, «use VPN to my localhost» does not scale: time zones, corporate firewalls, security policies. You need a shared address and shared history reachable from a browser without port-forwarding to a developer laptop.

5. Onboarding and consistent setup

Every new developer runs Mailpit their own way: a different port in docker-compose, a different image tag, a service missing from the README. With Mailexam, one set of SMTP credentials from the welcome email is enough — copy them into .env and CI secrets; everyone shares one inbox.

6. No access separation

A local catcher has no concept of «QA only» or «CI token only». Either someone can reach the machine/container or they cannot. Product teams often need separate projects (feature, staging, demo) and API tokens for automated tests — without root on a server.

How Mailexam is built for collaboration

Mailexam is a cloud test SMTP inbox with a dashboard and API. Messages are not delivered to real recipients; they land in a project in your account.

What that gives a team:

Task Mailexam approach
Shared inbox One project, one SMTP credential set; everyone with access sees the same messages in the dashboard
CI/CD The runner sends to {login}.mailexam.io — the message is available in the pipeline (via API) and in the browser
Staging / preview Same credentials on the server — QA checks mail without server access
Automated tests REST API: list messages, body, attachments — one workflow for the whole team
Multiple environments Separate projects or inboxes within a project (see API)
Distributed team HTTPS dashboard from anywhere; no VPN to a developer laptop

Typical workflow:

  1. A lead or DevOps creates a project (or uses the project from signup).
  2. SMTP login, password, and host are shared with the team and added to CI secrets.
  3. Developers, QA, and pipelines send mail to one sandbox.
  4. QA opens messages in the dashboard; CI asserts content via the API.

See Integration examples for connection guides.

When to use what

Situation Recommendation
Solo developer, offline, everything on a laptop Mailpit / MailHog or Mailexam (if you have internet)
Team of 2+, shared QA Mailexam
Email assertions in CI on shared runners Mailexam
Staging + dev + CI — one source of truth for mail Mailexam
Remote or international team Mailexam
Strict requirement: everything on-prem, no cloud Mailpit / MailHog (or a self-hosted equivalent)

Moving from Mailpit or MailHog

You do not need to change sending code — only SMTP settings in .env, docker-compose, and CI/CD.

Before (local)

MAIL_HOST=127.0.0.1
MAIL_PORT=1025
MAIL_USERNAME=
MAIL_PASSWORD=
MAIL_ENCRYPTION=null

The port may be 1025 (MailHog) or 1025 / 587 (Mailpit). Auth is often disabled.

After (Mailexam)

MAIL_HOST=YOUR_LOGIN.mailexam.io
MAIL_PORT=587
MAIL_USERNAME=YOUR_LOGIN
MAIL_PASSWORD=YOUR_PASSWORD
MAIL_ENCRYPTION=tls

Credentials are in the welcome email after signup or in the dashboard.

Docker Compose

You can remove the mailpit service from the dev docker-compose.yml for the team — the app talks directly to Mailexam. Keep local Mailpit only for developers who deliberately work fully offline.

Automated tests

If tests called the Mailpit API (/api/v1/messages, etc.), switch them to the Mailexam API — typical flow: send via SMTP → wait 1–5 s → GET /api/v1/email filtered by subject or recipient.

More

Need help setting this up for your team? Contact support@mailexam.io.