Кожен гайд по деплою Next.js порівнює фічі. Цей порівнює досвід — три реальних клієнтських проєкти, кожен на різній платформі, кожен у продакшні понад 6 місяців.
Проєкти
Проєкт A (Vercel): Портфоліо-сайт із блогом. 60 статичних сторінок, MDX-контент, контактна форма через Server Action. ~3 000 відвідувань на місяць.
Проєкт B (Fly.io): B2B SaaS-дашборд. Серверно-рендерені сторінки, WebSocket-з'єднання, Postgres-база на тій самій платформі. ~800 активних користувачів на день.
Проєкт C (Railway): Інтернет-магазин. ISR для сторінок товарів, Stripe checkout, каталог із великою кількістю зображень. ~15 000 відвідувань на місяць.
Порівняння вартості
| Vercel | Fly.io | Railway | |
|---|---|---|---|
| Щомісячна вартість | $20 (Pro план) | $15–25 (за споживанням) | $10–20 (за споживанням) |
| Що отримуєш | Хостинг + edge-мережа + аналітика | 2 VM (256MB) + білдер | 1 сервіс + білдер |
| База даних | Окремо (Neon: $0–19) | Вбудована (Fly Postgres) | Окремо (Railway Postgres: $5+) |
| Трафік | 1TB включено | Оплата за GB ($0.02) | 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, Image Optimization, Analytics — все вбудовано. Досвід розробника неперевершений.
Обмеження: Vercel opinionated. Ти запускаєш Next.js їхнім способом. Serverless-функції мають ліміти часу виконання (10 сек на Pro, 60 сек на Enterprise). WebSocket-підтримка вимагає обхідних рішень. Тривалі фонові задачі не вписуються в модель.
Для проєкту A (статичне портфоліо) Vercel ідеальний. Для проєкту B (WebSocket-дашборд) це був би поганий вибір.
Fly.io
Час деплою: 2–4 хвилини. Білдить Docker-образ і деплоїть на VM по всьому світу.
Плюси: Повний контроль. Ти запускаєш справжній Node.js-сервер, а значить WebSocket-и працюють нативно, фонові задачі виконуються в тому самому процесі, і немає serverless-лімітів на час виконання. Мульти-регіональний деплой зрозумілий — твій застосунок запускається на VM у вибраних регіонах.
Обмеження: Ти управляєш інфраструктурою. Розмір VM, health checks, конфіг auto-scaling, бекапи Postgres — все на тобі. Конфіг fly.toml має криву навчання. Коли щось ламається о 2 ночі, ти дебажиш інфраструктуру, а не просто код.
Для проєкту B (SaaS-дашборд) контроль виправдав операційні накладні витрати. WebSocket-з'єднання тримались живими без обхідних рішень, а процесор фонових задач запускався в тому самому деплої.
Railway
Час деплою: 90–120 секунд. Визначає фреймворк, білдить, деплоїть.
Плюси: Простіше за Fly, гнучкіше за Vercel. Отримуєш справжній сервер (не serverless) без управління VM. Деплой із Git — автоматичний. Дашборд чистий і показує логи, метрики та витрати в одному місці. Postgres — один клік.
Обмеження: Лише один регіон (US або EU, на вибір). Мульти-регіональний деплой потребує кількох сервісів. Auto-scaling базовіший, ніж у Fly. Платформа молодша — менше документації, менше ком'юніті.
Для проєкту C (інтернет-магазин) простота Railway підійшла. Один регіон (EU) для європейської аудиторії — нормально, а налаштування ISR/Stripe запрацювало без жодних змін.
Холодні старти
Це важливо для serverless-платформ (Vercel) і конфігів scale-to-zero (Fly, Railway).
- Vercel: Serverless-функції стартують холодно за 200–500 мс. Статичні сторінки та edge-функції: без холодного старту.
- Fly.io: При scale-to-zero завантаження VM займає 3–5 секунд. З
min_machines_running = 1— без холодного старту (але платиш за простоюючу VM). - Railway: Без холодних стартів — сервіс працює безперервно. Але платиш за час простою.
Для портфоліо (проєкт A) холодні старти Vercel були непомітні — Server Action контактної форми виконувалась за 300 мс при холодному старті, цілком нормально для відправки форми.
Для SaaS-дашборду (проєкт B) холодні старти були неприйнятні. Користувачі очікують миттєвого завантаження дашборду. Ми тримали одну Fly VM запущеною весь час.
Фреймворк прийняття рішень
Вибирай Vercel коли:
- Застосунок переважно статичний або ISR
- Хочеш нульового DevOps
- Влазиш у бюджет Pro плану ($20/місяць)
- Не потрібні WebSocket-и або тривалі процеси
- Продуктивність і DX важливіші за контроль над інфраструктурою
Вибирай Fly.io коли:
- Потрібні WebSocket-и, фонові задачі або тривалі процеси
- Хочеш мульти-регіональний деплой
- Комфортно управляти інфраструктурою
- Застосунку потрібна суміщена база даних (Fly Postgres)
Вибирай Railway коли:
- Хочеш щось між простотою Vercel і контролем Fly
- Одного регіону достатньо
- Хочеш передбачуване ціноутворення без serverless-складності
- Деплоїш Next.js застосунок із базою даних
Мій дефолтний вибір
Для клієнтських проєктів мій дефолт — Vercel. Не тому що він завжди найкращий — а тому що він прибирає цілу категорію рішень. Жодних Dockerfile-ів, жодного вибору розміру VM, жодного конфігу масштабування. Клієнт отримує задеплоєний застосунок із preview URLs і автоматичними деплоями з першого дня.
До Fly.io я звертаюсь, коли проєкту потрібне те, чого Vercel не вміє: WebSocket-и, фонова обробка або специфічні вимоги до інфраструктури. Компроміс — операційна складність в обмін на можливості.
Railway — моя рекомендація, коли клієнти хочуть самостійно управляти проєктом після передачі. Дашборд інтуїтивний, ціноутворення прозоре, і потрібно менше vendor-специфічних знань для підтримки деплою.
Деплоїш Next.js застосунок і не знаєш, яка платформа підходить? Напиши — я допомагаю обрати правильну інфраструктуру, щоб не мігрувати на 6-й місяць.