Как мы переехали с mail.ru на собственный сервер

У нас команда примерно из 30 человек. Мы купили сервер, подняли на нем почту, Mattermost для чатов и звонков, GitLab, Jira, Confluence, Nextcloud и менеджер паролей, а вход во все это объединили через Keycloak. Ниже — зачем мы в это ввязались, сколько потратили и на каких граблях постояли.

Корпоративной почтой Mail.ru мы пользовались много лет. Она была бесплатной, работала на нашем домене, имела API и общие рабочие папки. Для небольшой компании — то, что нужно: завел сотрудников и работаешь.

Остальные инструменты тем временем появлялись сами по себе. Рабочие чаты жили в Telegram, там же проходила часть созвонов. Файлами обменивались через Google: загрузил, открыл доступ, кинул ссылку в чат. Код, задачи, документация и пароли находились каждый в своем сервисе, часто со своей учетной записью.

Пока команда небольшая, к этому привыкаешь. Но со временем рабочая информация расползается: обсуждение осталось в Telegram, файл лежит где-то на Google Диске, задача — в Jira, а нужная ссылка потерялась в переписке. Новому сотруднику приходится выдавать доступы в нескольких местах. При увольнении — вспоминать, где их закрывать.

Потом бесплатный тариф закончился. За первый год мы заплатили около 60 тысяч рублей. Продление на следующий год для 32 пользователей стоило уже 79 552 рубля.

Вот так выглядело письмо счастья от mail.ru:

80 тысяч в год — не те деньги, из-за которых компания завтра закроется. Мы могли заплатить и продолжить работать. Но стало понятно, куда все идет: число пользователей остается примерно тем же, сервис — тоже, а счет растет. И через год он наверняка не станет меньше.

Почему мы все-таки решили переезжать

Нас подтолкнула не только цена. В 2026 году Яндекс сообщил пользователям доменной почты, что IMAP, SMTP и POP3 будут доступны только на платном тарифе. Если почта подключена к Outlook, Thunderbird, боту или системе уведомлений, то после смены условий все это либо перестает работать, либо требует оплаты.

Следом похожая история произошла с Mail.ru: доступ через IMAP и SMTP привязали к платному Mail Space. У части пользователей отключились пароли приложений.

Тут все по классике: сначала сервис бесплатный или очень дешевый. За несколько лет компания переносит туда архивы, заводит сотрудников, подключает почтовые клиенты и ботов. А потом привычная функция становится частью платного тарифа. Переезд к этому моменту уже требует времени и денег, поэтому проще заплатить.

Ждать следующего письма о новых тарифах не хотелось. Решили потратить деньги на свое железо и свои сервисы.

Изначально мы собирались заменить только почту. Но когда начали обсуждать переезд, посмотрели на остальные рабочие инструменты и решили заодно навести порядок. Так почтовый сервер постепенно превратился в наш собственный «ящик Пегого Дудочника» из «Силиконовой долины». (Кто в теме, тот в теме :) )

Что мы построили

В начале года купили сервер примерно за 140 000 рублей:

• 64 ГБ DDR5;

• 2 ТБ SSD под виртуальные машины и рабочие данные;

• 2 ТБ HDD под локальные бэкапы.

Еще 25 000 рублей ушло на ИБП. Обязательно берите с чистой синусоида, наличием USB и RS-232. Вместе сервер и ИБП обошлись примерно в 165 000 рублей.

ИБП мы брали не для долгой работы без электричества. Он должен пережить короткое отключение, а если питание не вернулось — дать серверу нормально выключиться. Мы настроили автоматическое завершение работы: сначала останавливаются виртуальные машины и контейнеры, данные записываются на диски, после чего выключается сам хост. Для почтовых баз, репозиториев и виртуалок это заметно безопаснее, чем внезапно выдернутая розетка.

На сервере сейчас работает такой набор:

• Единый вход - Keycloak

• Рабочие чаты и звонки - Mattermost

• Почта - mailcow

• Менеджер паролей - Vaultwarden

• Задачи - Jira

• База знаний - Confluence

• Репозитории - GitLab Self-Managed

• Файлы - Nextcloud

Все развернуто в контейнерах. Установка и обновление конфигурации автоматизированы через GitLab CI. GitLab и Jira отправляют события в нужные каналы Mattermost, поэтому уведомления по проекту лежат рядом с обсуждением. Там же команда созванивается и показывает экран — отдельный сервис для рабочих звонков нам больше не нужен.

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

Немного про деньги

Говорить, что open source ничего не стоит, было бы нечестно. За лицензии многих продуктов платить не нужно, но само железо надо купить, подключить и обслуживать. Есть электричество, интернет, статический IP, бэкапы, замена аккумуляторов в ИБП и время инженеров. Иногда нужны платные плагины или лицензии.

Если смотреть только на почту, два года по текущей цене обошлись бы нам в 159 104 рубля. Это почти цена сервера вместе с ИБП.

Сравнение, конечно, упрощенное: сервер тоже требует расходов. Но и работает на нем не одна почта, а еще семь сервисов. Мы не пытались доказать, что свое железо всегда дешевле любого облака. Нам были важны понятные расходы и возможность самим решать, что происходит с данными и сервисами.

У подписки цена растет вместе с командой. У нашего сервера есть запас по ресурсам, поэтому новый сотрудник сам по себе не создает еще восемь ежемесячных платежей.

Для почты выбрали mailcow: dockerized. Внутри уже есть админка, веб-клиент и все основные почтовые компоненты.

Главный вопрос был не в том, как запустить новый сервер, а в том, как перенести старые ящики вместе с папками и вложениями. Мы нашли imapsync, настроили его и успешно прогнали тестовую синхронизацию. А потом случайно заметили, что этот же механизм уже встроен в mailcow и доступен в разделе Sync Jobs. Через веб-интерфейс настраивать его оказалось проще.

Пароли приложений

Для переноса нужен доступ к старому ящику по IMAP, а для него — пароль приложения Mail.ru. Пользователь мог создать такой пароль только после привязки телефона. Один и тот же номер к куче аккаунтов не привяжешь, а у нас были и сервисные ящики, и сотрудники с несколькими учетками.

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

DNS и доставляемость

Запустить почтовый сервер мало. Нужно еще убедить остальные серверы принимать от него письма.

С PTR пришлось разбираться отдельно. Для офисного сервера эту запись настраивает интернет-провайдер, потому что IP принадлежит ему. Проверить PTR лучше до смены MX, а не когда письма уже начали попадать в спам.

После настройки прогнали несколько проверок: посмотрели распространение DNS через DNSChecker, проверили IP по DNSBL и отправили письмо на mail-tester. Получили 10/10.

10/10 не обещает, что каждое письмо попадет во «Входящие». У нового IP еще нет репутации, а у крупных почтовиков свои фильтры. Но грубые ошибки в SPF, DKIM и DMARC такой тест хорошо показывает.

Где мы споткнулись

Без проблем, конечно, не обошлось.

Письма продолжали приходить на старый сервер

После смены MX часть писем шла на новый сервер, а часть — в VK WorkSpace. Выяснилось, что домен нужно удалить и на стороне старого сервиса. Но даже после удаления часть писем продолжала уходить туда.

В итоге написали в поддержку VK WorkSpace. У них оставалась какая-то внутренняя настройка, которую поправили вручную. После этого маршрутизация заработала как надо.

Готовая интеграция Keycloak подошла не везде

В mailcow есть отдельный провайдер Keycloak, но в нашей версии через него не получилось передать нужные scopes. Подключились через обычный OIDC — так все заработало. Ящик создается при первом входе, если у пользователя есть нужная роль.

У SSO может остаться запасной вход по паролю

GitLab подключили к Keycloak через OmniAuth/OIDC. Пользователи автоматически связываются с локальными учетками, 2FA проверяет Keycloak. Но выяснился нюанс: у локального пользователя GitLab все еще может быть свой пароль и восстановление через почту. Получается обход единой точки входа.

Такое поведение надо проверять в каждом приложении. Где возможно, локальный вход лучше отключать. При этом аварийную учетку администратора стоит оставить и хранить отдельно, иначе проблема с Keycloak отрежет доступ сразу ко всей инфраструктуре.

Звонки Mattermost включены, но не работают

Mattermost у нас отвечает не только за переписку: через него проходят обычные рабочие и групповые звонки, в том числе с демонстрацией экрана. В настройках Calls стояло Enabled, однако звонки не проходили. Мы выключили плагин, сохранили настройки, снова включили и еще раз сохранили. Только после этого конфигурация применилась.

Мелочь, но времени съела прилично.

Что получилось

Сейчас почта, чаты, рабочие звонки, файлы, код, задачи и документация работают на нашем сервере. Пользователи и доступы управляются через Keycloak. Обсуждения, созвоны и уведомления по проектам собраны в Mattermost. Данные бэкапятся по нашим правилам, а не по правилам внешнего поставщика.

Самым ценным для нас оказался даже не прямой выигрыш в деньгах. Теперь мы сами решаем, где лежат данные, когда обновлять систему и как долго хранить резервные копии.

Кому такой вариант может подойти

Свой сервер имеет смысл хотя бы посчитать, если компания платит за несколько сервисов по числу сотрудников, работает с чувствительными данными или зависит от продуктов, которые могут изменить условия из-за тарифов, санкций или географии.

Но self-hosted подходит не всем. Если в компании пять человек, один недорогой SaaS и никто не хочет заниматься администрированием, свой сервер легко окажется дороже и сложнее. Нужно считать не только покупку железа, но и обслуживание, бэкапы и допустимое время простоя.

Мы делали эту инфраструктуру для себя и прошли весь путь: от выбора железа до переноса почты и настройки SSO. Теперь можем собрать похожую систему под ключ и для другой компании — с другим набором приложений, если он лучше подходит ее процессам.

Контакты

• Сайт: saasoft.ru

• Telegram-канал: @saasoftru

P. S. Еще мы поддерживаем C#-библиотеку SaaSoft.MAX.Bot для разработки ботов в MAX.

P.S.S. Да, часть статьи помогла писать ИИ, потому что мы все таки "ботаны", а не писатели. Надеемся маленькую, но пользу принесем