# Migrate from Mailpit

> Mailpit stays excellent on a developer’s machine. Why teams migrate once the tests move to continuous integration, and how to do it with no SDK to translate.
> https://facteur.eu/en/alternatives/mailpit

Migrate from Mailpit

## Migrate from Mailpit

Mailpit is free and excellent on a developer’s machine. This page is not trying to talk you out of it: it describes what happens when the same tests have to run in continuous integration, across a team, and receive mail from outside.

- Nothing to operate: no server, no monitoring, no upgrades
- Public addresses, reachable from outside
- Accounts, roles, SSO and quotas shared across pipelines

## What makes a team move

- **The mail comes from somewhere other than your code** : An identity provider, an SMS gateway, a partner: as soon as a message leaves a machine you do not control, it needs a public address. A Mailpit on the CI network does not give it one without work.
- **Several pipelines, the same inboxes** : Each run starts its container, receives its messages and takes them away when it stops. Sharing an inbox between two pipelines, or reading back what arrived yesterday, means building a service: the one you were avoiding.
- **Nobody wants to operate one more server** : Free is not the same as costless: the machine, its monitoring, its upgrades, and the person fetched the day it falls over while the pipeline waits.
- **SMS arrive in the same tool** : One-time-code journeys often go by SMS. Mailpit only does email; here the text message lands in the same inbox and is read with the same call.

## What switching changes

There is no SDK to translate here: Mailpit is installed and queried over HTTP. What changes is not the shape of the call: there is no longer a service to run beside your tests, and no code left to extract from the body.

## The migration, step by step

There is no SDK to translate: the switch removes a service from the pipeline rather than rewriting tests.

- **Create an account and an inbox** : The inbox is hosted and its addresses are public: it receives mail from anywhere, including services you do not control: an identity provider, an SMS gateway.
- **Remove the service from the compose file** : The container, its ports and its readiness wait leave the pipeline. There is nothing left to start before the tests, and nothing to watch during them.
- **Replace the HTTP call** : Reading /api/v1/messages and sorting the array become messages.waitFor(), which blocks until the right message arrives and hands back the code already extracted.
- **Keep Mailpit locally, if you like it** : Many teams keep Mailpit on the development machine and migrate only continuous integration: the two uses take nothing from each other.

The switch, at a glance

- Software cost
- Subscription
- Free, MIT licence

- To operate
- Nothing, a hosted service
- A server, its monitoring, its upgrades

- Sharing across pipelines
- Yes, shared and partitioned inboxes
- Build it yourself

- Receiving from outside
- Yes, public addresses
- Local network only, unless exposed by hand

- Retention and history
- 3 to 60 days by plan
- Whatever you configure, on your disk

- Accounts, roles, SSO
- Yes
- No

- SMS
- Yes
- No, email only

The real cost

Mailpit costs nothing to install. What it costs is elsewhere: the machine that runs it, its monitoring, its upgrades, and the time of whoever looks after it the day it falls over while the pipeline waits.

Where this comes from

Frequently asked