Как перенести приложение с Railway на VPS: база, очередь и файлы

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

В интерфейсе Railway проект выглядит как несколько аккуратных блоков: приложение, PostgreSQL, очередь, иногда отдельный работник. Между ними проведены связи, переменные подставляются автоматически, внутренние адреса появляются без вашего участия. При переносе на VPS именно эти связи важнее картинок. Если просто запустить тот же код, он может продолжить искать базу по имени, существовавшему только внутри Railway.

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

Нарисуйте зависимости до заказа сервера

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

Полезно проследить один конкретный запрос. Например, пользователь отправляет изображение, приложение создаёт запись в PostgreSQL и задание в очереди, работник уменьшает изображение, а результат сохраняется в файловом хранилище. Теперь видно, почему успешный HTTP-ответ не доказывает завершение переезда: обработка ещё только началась.

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

Что происходит с переменными Railway

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

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

Не переносите внутренние адреса Railway как есть. Для каждого подключения проверьте, где будет находиться сервис после переезда. База внутри контейнерной сети может называться db, но это имя разрешается только участниками этой сети. Программа на самом VPS и программа в контейнере могут использовать разные адреса одного и того же сервиса.

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

PostgreSQL: пробное восстановление раньше финального экспорта

У Railway есть документация PostgreSQL, включая параметры подключения. Для миграции определите версию базы, расширения и объём данных. Выберите совместимые инструменты экспорта и целевую версию PostgreSQL. Не объединяйте перенос с большим обновлением базы без отдельной репетиции.

Создайте резервную выгрузку и восстановите её в отдельный тестовый экземпляр на VPS. Используйте пустую базу с тестовым именем. Прежде чем выполнять команды, проверьте адрес назначения: похожие строки подключения способны испортить день даже аккуратному администратору.

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

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

Тома и пользовательские файлы

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

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

В новом окружении разделите код и постоянные данные. Выпуск приложения можно пересоздать из репозитория; загруженные клиентом фотографии должны переживать замену контейнера. Проверьте владельца каталога и права записи от имени реального процесса, а не только от администратора сервера.

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

Очередь требует своего решения

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

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

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

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

Соберите новую схему и проверьте её отказ

На VPS можно использовать Docker Compose, если проект уже контейнеризирован, либо отдельные службы. Для небольшого набора сервисов Compose делает внутренние связи наглядными. Публично открывайте только обратный прокси; базу и очередь оставьте во внутренней сети.

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

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

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

Окно переключения и первые сутки

Выберите время с небольшой активностью. Остановите новые изменения на старой площадке, завершите очередь по согласованному плану, сделайте финальный экспорт базы и догрузите файлы. После восстановления на VPS выполните короткую проверку и переключите DNS.

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

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

Какая конфигурация MAATRIX нужна

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

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

В MAATRIX можно подобрать VPS под целую схему приложения или начать с тестового переноса. Стоимость внешних API и почты учитывается отдельно. Главный результат переезда — воспроизводимая система, где понятно, кто хранит данные, кто выполняет задания и что делать при следующем обновлении.