Перейти к содержанию

Mailpit и MailHog: локально или Mailexam® для команд

MailHog и Mailpit — популярные локальные инструменты для перехвата исходящей почты в разработке. Они запускаются на вашей машине или в Docker, принимают SMTP на localhost и показывают письма в веб-интерфейсе. Для одного разработчика на ноутбуке это удобно и бесплатно.

Mailexam® решает ту же базовую задачу — тестовый SMTP-ящик вместо реальных получателей — но как облачный сервис для совместной работы: общие Входящие для команды, доступ из CI/CD и staging без туннелей, API для автотестов. Подходит и для распределённых команд вплоть до международных, когда разработчики, QA и DevOps работают из разных офисов и часовых поясов.

Коротко

MailHog Mailpit Mailexam®
Модель Локальный процесс / контейнер Локальный процесс / контейнер Облачный SaaS
Аудитория Один разработчик на машине Один разработчик на машине Команда, CI/CD, QA
Общие Входящие Нет — ящик на конкретном хосте Нет — ящик на конкретном хосте Да — один проект, общий доступ
Доступ из CI/CD Только если runner на той же машине То же Да — SMTP и API из любого runner'а
Доступ для коллег SSH, screen share, проброс порта То же Браузер и API по учётным данным
Учётные записи и роли Нет Нет Аккаунт, проекты, API-токены
История при перезапуске Теряется (по умолчанию) Настраивается локально Хранится в облаке
API для автотестов Ограничен (MailHog) / есть (Mailpit) REST API REST API

Не «хуже» и «лучше»

Mailpit и MailHog — отличный выбор для личной отладки на ноутбуке. Mailexam® нужен, когда письма должны видеть несколько людей или удалённые системы (CI, staging, коллега в другом городе) без возни с сетью.

Для кого подходят Mailpit и MailHog

Локальные перехватчики хорошо закрывают сценарий «я один, пишу код, смотрю письмо рядом»:

  • быстрый старт через docker run или бинарник без регистрации;
  • полный контроль над данными на своём диске;
  • нет зависимости от внешнего сервиса;
  • достаточно для проверки шаблона, вёрстки или SMTP-интеграции на своей машине.

По сути это однопользовательские решения: Входящие живут там, где запущен процесс. Другой человек не откроет ваш Mailpit, пока вы не пробросите порт, не поднимете VPN и не объясните, на каком хосте смотреть.

Где локальные инструменты упираются в потолок

Когда в проекте появляется команда, типичные боли выглядят так:

1. «Письмо у меня на ноутбуке, а QA его не видит»

Разработчик отправил тестовое письмо — оно попало в локальный Mailpit. Тестировщик в другом офисе (или на другом континенте) не может открыть те же Входящие: у него другая машина, другой localhost. Остаются скриншоты, созвоны и «скинь ссылку из письма в Slack».

2. CI/CD и общие runner'ы

В pipeline письмо уходит на 127.0.0.1:1025. На общем CI-runner'е (GitLab, GitHub Actions, Jenkins) рядом с вашим приложением нет вашего Mailpit — или он принадлежит другому job'у и очищается после сборки. Чтобы проверить письмо в CI, приходится поднимать Mailpit в том же job'е, парсить API или мокать отправку — это усложняет pipeline.

3. Staging и несколько сред

Staging-сервер, preview-окружение и локальная разработка — три разных хоста, три разных локальных ящика (если вообще настроены). Нет единого места, где QA смотрит «все тестовые письма проекта». Сравнить поведение между средами сложнее.

4. Международные и распределённые команды

Когда команда в Москве, Берлине и Сингапуре, «зайди на мой localhost через VPN» не масштабируется: часовые пояса, корпоративные firewall'ы, политики безопасности. Нужен общий адрес и общая история, доступная из браузера без проброса портов на ноутбук разработчика.

5. Онбординг и единые настройки

Каждый новый разработчик поднимает Mailpit по-своему: другой порт в docker-compose, другая версия образа, забытый сервис в README. В Mailexam® достаточно одних SMTP-параметров из приветственного письма — их копируют в .env и CI-секреты; Входящие одни для всех.

6. Нет разделения доступа

Локальный перехватчик не знает про «только QA» или «только CI-токен». Либо у человека есть доступ к машине/контейнеру, либо нет. Для продуктовой команды часто нужны отдельные проекты (feature, staging, demo) и API-токены для автотестов — без root на сервере.

Как Mailexam® устроен для коллективной работы

Mailexam® — облачный тестовый SMTP-ящик с личным кабинетом и API. Письма не уходят реальным получателям; они попадают в проект в вашем аккаунте.

Что это даёт команде:

Задача Решение в Mailexam®
Общие Входящие Один проект — одни SMTP-учётные данные; все, у кого есть доступ, видят те же письма в кабинете
CI/CD Runner отправляет на {логин}.mailexam.ru — письмо доступно и в pipeline (через API), и человеку в браузере
Staging / preview Те же credentials на сервере — QA проверяет письма без доступа к серверу
Автотесты REST API: список писем, тело, вложения — один сценарий для всей команды
Несколько сред Отдельные проекты или почтовые ящики внутри проекта (см. API)
Распределённая команда HTTPS-кабинет из любой точки мира; не нужен VPN на ноутбук разработчика

Типичный рабочий процесс:

  1. Тимлид или DevOps создаёт проект (или использует проект из регистрации).
  2. SMTP-логин, пароль и хост рассылаются команде и добавляются в CI-секреты.
  3. Разработчик, QA и pipeline шлют почту в один sandbox.
  4. QA открывает письмо в кабинете; CI проверяет содержимое через API.

Подробнее о подключении — в примерах интеграции.

Когда что выбирать

Ситуация Рекомендация
Один разработчик, офлайн, всё на ноутбуке Mailpit / MailHog или Mailexam® (если есть интернет)
Команда от 2 человек, общий QA Mailexam®
Автотесты писем в CI на shared runner'ах Mailexam®
Staging + dev + CI — одна «правда» о письмах Mailexam®
Удалённая или международная команда Mailexam®
Жёсткое требование «всё только on-prem, без облака» Mailpit / MailHog (или self-hosted аналог)

Переход с Mailpit или MailHog

Код отправки менять не нужно — только SMTP-параметры в .env, docker-compose и CI/CD.

Было (локально)

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

Порт может быть 1025 (MailHog) или 1025 / 587 (Mailpit). Авторизация часто отключена.

Стало (Mailexam®)

MAIL_HOST=ВАШ_ЛОГИН.mailexam.ru
MAIL_PORT=587
MAIL_USERNAME=ВАШ_ЛОГИН
MAIL_PASSWORD=ВАШ_ПАРОЛЬ
MAIL_ENCRYPTION=tls

Учётные данные — в приветственном письме после регистрации или в личном кабинете.

Docker Compose

Сервис mailpit в docker-compose.yml можно убрать из профиля разработки для команды — приложение ходит напрямую в Mailexam®. Локальный Mailpit имеет смысл оставить только тем, кто сознательно работает полностью offline.

Автотесты

Если тесты ходили в Mailpit API (/api/v1/messages и т.п.), переключите их на API Mailexam® — типичный сценарий: отправка по SMTP → пауза 1–5 с → GET /api/v1/email с фильтром по теме или получателю.

Что ещё стоит знать

Нужна помощь с настройкой для вашей команды? Напишите на support@mailexam.ru.