Из Heroku на VPS: чем заменить dyno, Procfile и дополнения

MAATRIX · 17 октября 2026 · 7 мин чтения

Две строки в Procfile могут скрывать целую инфраструктуру. Одна запускает сайт, другая — обработчик задач. Heroku подставляет порт, передаёт настройки, собирает приложение и перезапускает процессы. Когда проект переезжает на VPS, эти обязанности переходят к вашей схеме развёртывания.

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

Procfile становится картой процессов

Откройте Procfile и выпишите все типы процессов. Согласно документации Heroku, этот файл описывает команды, а тип web имеет особое значение для приёма внешних запросов. На VPS файл автоматически не исполняется: команды нужно оформить в службы или контейнеры.

Сайт и работник должны управляться независимо. Если работник упал на обработке отчёта, веб-приложение продолжает принимать безопасные запросы. Если обновляется сайт, работник корректно завершает текущую задачу или возвращает её в очередь. Планировщик тоже выделите отдельно, чтобы случайно не запустить его по одному разу в каждом веб-процессе.

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

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

Buildpack заменяется воспроизводимой сборкой

Выясните, какие версии языка, системные библиотеки и действия сборки использовались на Heroku. Проверьте файлы зависимостей, lock-файлы и дополнительные buildpack. Иногда приложение работает благодаря библиотеке, которую никто явно не записал в инструкцию установки.

На VPS выберите контейнерную сборку или подготовленное системное окружение. Контейнер удобен тем, что описывает пакеты и команды рядом с проектом, но сам по себе не делает сборку правильной. В любом варианте зафиксируйте версии и проверьте развёртывание в чистой среде.

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

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

Config vars и секреты

Heroku передаёт настройки через переменные окружения; правила описаны в Config Vars. На VPS подготовьте защищённый файл окружения или настройки панели развёртывания. Отделите секреты от репозитория и публичной документации.

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

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

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

Дополнения: каждому нужен свой план

Составьте список add-ons и определите, какие из них действительно используются. Для PostgreSQL нужен перенос базы, для Redis — понимание роли данных, для почты — новый или сохранённый аккаунт провайдера, для наблюдения за ошибками — перенастройка отправки событий.

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

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

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

PostgreSQL и файлы переносим отдельно

Для Heroku Postgres доступен механизм PGBackups, описанный в официальном руководстве. Подготовьте выгрузку, запишите версию базы и расширения, затем восстановите копию в отдельный тестовый экземпляр на VPS.

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

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

На VPS постоянные файлы размещайте отдельно от кода. Сохраните ключи объектов или измените ссылки управляемой миграцией. Закрытые документы должны сохранить проверку прав. Для выборки файлов сравните размеры и контрольные суммы, затем скачайте их через обычный пользовательский интерфейс.

Работники и очереди: избежать двойной работы

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

Запускайте новые процессы только после настройки их подключений. Тестовый работник не должен случайно обратиться к рабочей очереди и начать рассылку. Для репетиции используйте отдельные имена очередей, ключи и получателей.

Проверьте повторное выполнение. Допустим, задача создаёт документ у внешнего провайдера, а затем сохраняет его идентификатор. Если процесс оборвался между этими действиями, повторная попытка не должна создавать второй документ. Используйте устойчивый идентификатор операции и предусмотренные внешним API механизмы защиты от дублей.

После запуска контролируйте длину очереди и возраст самого старого задания. Низкая загрузка процессора может означать не прекрасную производительность, а отсутствие связи работника с нужной очередью.

Приёмка новой площадки

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

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

Запишите способ отката к предыдущему выпуску и совместимость схемы базы. Если новая версия удалила колонку, старая может уже не запуститься. Безопаснее сначала добавить новую структуру, перевести код и только после отдельной проверки удалять старую.

Во время смены DNS остановите независимую запись на старой площадке. Финальная база и файлы должны отражать одну точку времени. Сохраните исходные ресурсы до окончания наблюдения, учитывая появление новых данных на VPS в плане возврата.

Ресурсы MAATRIX и обязанности команды

Для небольшого приложения с базой и работником начните оценку с MAATRIX Heka Standard: 4 vCPU и 8 ГБ памяти. Более лёгкий проект можно испытать на Uab Start с 2 vCPU и 4 ГБ. Подбор зависит от числа процессов, нагрузки базы и параллельных задач; эквивалент одного dyno нельзя вычислить только по названию тарифа.

Поддерживаемые Ubuntu и Debian позволяют собрать привычную среду. Диск рассчитывайте по данным, вложениям, журналам и запасу для выпусков. Резервные копии храните отдельно и регулярно проверяйте восстановление.

После перехода назначьте ответственного за обновления, сертификаты, ошибки и заполнение диска. VPS MAATRIX даёт инфраструктуру для самостоятельного размещения. Понятный регламент превращает её в рабочий сервис, который сохраняет удобство для пользователей даже после того, как за ним больше не стоит привычная кнопка Heroku.