Railway хорош, пока вы не смешали один проект, БД и фоновые задачи в один сервис

Railway хорош, пока вы не смешали один проект, БД и фоновые задачи в один сервис

Railway часто берут как «быстрый деплой без DevOps», и в этом он реально силён. Но типовая ошибка одна: поднимать всё в одном проекте и считать, что это уже архитектура. Потом ломается миграция, фоновые воркеры съедают память, а рестарт приложения валит и API, и очередь, и cron.

Рабочая схема для небольшого продукта обычно такая:
— web отдельно
— база отдельно
— worker отдельно
— cron отдельно, если он нужен
Так проще масштабировать, смотреть логи и не гадать, почему тормозит весь сервис. Ещё полезно сразу вынести переменные окружения и не хранить секреты в репозитории.

На Railway удобно стартовать с Postgres и простого backend-сервиса, но не стоит рассчитывать на «магическую» устойчивость без контроля ресурсов. Следите за памятью и соединениями к БД: если приложение открывает много коннектов, проблемы всплывают не в коде, а в проде. Для веб-агентств это особенно заметно, когда один шаблон деплоя клонируют на десять клиентов.

Ещё один момент: для прода лучше заранее проверить, как вы будете делать откат, миграции и бэкапы. Если этот план не описан до первого релиза, потом он всегда оказывается «на завтра».

Railway удобен как стартовая площадка, но выигрывает тот, кто сразу делит роли сервисов и держит деплой простым.