Большинство гайдов по деплою Next.js сравнивают фичи. Этот сравнивает опыт — из трёх реальных клиентских проектов, каждый на своей платформе, каждый в продакшне 6+ месяцев.
Проекты
Проект A (Vercel): Портфолио-сайт с блогом. 60 статических страниц, MDX-контент, контактная форма через Server Action. ~3 000 посещений в месяц.
Проект B (Fly.io): B2B SaaS-дашборд. Server-rendered страницы, WebSocket-соединения, Postgres-база на той же платформе. ~800 активных пользователей в день.
Проект C (Railway): E-commerce витрина. ISR для страниц товаров, Stripe checkout, каталог с большим количеством изображений. ~15 000 посещений в месяц.
Сравнение стоимости
| Vercel | Fly.io | Railway | |
|---|---|---|---|
| Стоимость в месяц | $20 (Pro-план) | $15–25 (по использованию) | $10–20 (по использованию) |
| Что входит | Хостинг + edge-сеть + аналитика | 2 VM (256MB) + builder | 1 сервис + builder |
| База данных | Отдельно (Neon: $0–19) | Включена (Fly Postgres) | Отдельно (Railway Postgres: $5+) |
| Bandwidth | 1TB включено | По $0.02 за GB | 100GB включено |
| Минуты билда | 6 000/мес | Без лимита (твоя VM) | 500 включено |
Реальные затраты за 6 месяцев:
- Проект A (Vercel): $20/мес фиксировано. Лимиты Pro-плана ни разу не были превышены.
- Проект B (Fly.io): в среднем $22/мес. Один месяц скакнул до $35, когда всплеск трафика поднял машины.
- Проект C (Railway): в среднем $16/мес. Предсказуемо — ценообразование Railway по использованию проще, чем у Fly.
Опыт деплоя
Vercel
Время деплоя: 45–90 секунд на полный билд. Инкрементальные билды (ISR) — мгновенно, только изменившиеся страницы.
Плюсы: Нулевая конфигурация для Next.js (они сами его делают). Git push → задеплоено. Preview deployments для каждого PR. Edge Functions, оптимизация изображений, аналитика — всё встроено. DX вне конкуренции.
Ограничение: Vercel навязывает свой подход. Ты запускаешь Next.js по их правилам. У serverless-функций есть лимиты времени выполнения (10 сек на Pro, 60 сек на Enterprise). WebSocket требует обходных путей. Долго выполняющиеся фоновые задачи в эту модель не вписываются.
Для Проекта A (статическое портфолио) Vercel — идеальный выбор. Для Проекта B (WebSocket-дашборд) это был бы плохой вариант.
Fly.io
Время деплоя: 2–4 минуты. Собирает Docker-образ и деплоит на VM глобально.
Плюсы: Полный контроль. Ты запускаешь настоящий Node.js-сервер, а значит WebSocket работает нативно, фоновые задачи живут в том же процессе и никаких serverless-ограничений по времени нет. Multi-region деплой — прямолинейный: приложение работает на VM в выбранных регионах.
Ограничение: Ты управляешь инфраструктурой. Размер VM, health checks, конфиг auto-scaling, бэкапы Postgres — всё на тебе. Конфиг fly.toml требует времени на освоение. Когда что-то ломается в 2 ночи, ты дебажишь инфраструктуру, а не просто код.
Для Проекта B (SaaS-дашборд) контроль стоил операционной нагрузки. WebSocket-соединения жили без костылей, а процессор фоновых задач работал в том же деплое.
Railway
Время деплоя: 90–120 секунд. Определяет фреймворк, собирает, деплоит.
Плюсы: Проще Fly, гибче Vercel. Получаешь настоящий сервер (не serverless), не управляя VM. Деплой из Git — автоматический. Дашборд чистый: логи, метрики и затраты в одном месте. Postgres — в один клик.
Ограничение: Только один регион (US или EU, ты выбираешь). Без multi-region без запуска нескольких сервисов. Auto-scaling базовый по сравнению с Fly. Платформа моложе — меньше документации, сообщество поменьше.
Для Проекта C (e-commerce) простота Railway подошла. Один регион (EU) был нормален для европейской аудитории, и ISR/Stripe-настройка заработала без изменений.
Холодные старты
Это важно для serverless-платформ (Vercel) и конфигураций с масштабированием до нуля (Fly, Railway).
- Vercel: Serverless-функции стартуют за 200–500ms. Статические страницы и edge-функции — без холодного старта.
- Fly.io: Если масштабировать до нуля, загрузка VM занимает 3–5 секунд. При
min_machines_running = 1холодного старта нет (но платишь за простаивающую VM). - Railway: Холодных стартов нет — сервис работает непрерывно. Но платишь за простой.
Для портфолио (Проект A) холодные старты Vercel были незаметны — Server Action контактной формы занимал 300ms при холодном старте, нормально для отправки формы.
Для SaaS-дашборда (Проект B) холодные старты были неприемлемы. Пользователи ждут, что дашборд загрузится мгновенно. Мы держали одну Fly VM запущенной постоянно.
Как выбрать
Выбирай Vercel, когда:
- Приложение в основном статическое или ISR
- Хочешь нулевой DevOps
- Бюджет под Pro-план ($20/мес)
- WebSocket и долгие процессы не нужны
- Производительность и DX важнее контроля над инфраструктурой
Выбирай Fly.io, когда:
- Нужны WebSocket, фоновые задачи или долгие процессы
- Нужен multi-region деплой
- Ты комфортно чувствуешь себя с управлением инфраструктурой
- Приложению нужна совместно размещённая база (Fly Postgres)
Выбирай Railway, когда:
- Хочешь что-то между простотой Vercel и контролем Fly
- Один регион — нормально
- Хочешь предсказуемое ценообразование без serverless-сложности
- Деплоишь Next.js-приложение с базой данных
Мой дефолт
Для клиентских проектов мой дефолт — Vercel. Не потому что он всегда лучший вариант, а потому что убирает целую категорию решений. Никаких Dockerfile, никакого размера VM, никакого конфига масштабирования. Клиент с первого дня получает задеплоенное приложение с preview URL и автоматическими деплоями.
К Fly.io я тянусь, когда проекту нужно то, что Vercel не умеет: WebSocket, фоновая обработка или особые требования к инфраструктуре. Компромисс — операционная сложность в обмен на возможности.
Railway — моя рекомендация, когда клиент хочет самостоятельно управлять после передачи. Дашборд интуитивен, ценообразование прозрачно, и нужно меньше платформо-специфичных знаний для поддержки деплоя.
Деплоишь Next.js-приложение и не знаешь, какая платформа подойдёт? Напиши мне — помогу выбрать правильную инфраструктуру, чтобы не мигрировать через 6 месяцев.