← Усі статті

Next.js без 502 під час деплою: PM2 reload і Kubernetes

Zero-downtime на VPS: cluster mode, reload замість restart, не видаляти .next під час збірки.

Теги
Новиниdevopsnextjs
Next.js без 502 під час деплою: PM2 reload і Kubernetes
Зміст

Коротко

Кожен деплой Next.js на VPS — лотерея: хвилина 502 Bad Gateway або обійшлося. На Habr розібрали рецепт з PM2: reload замість restart, cluster mode і дисципліна навколо .next.

Що сталося

Типовий сценарій: пуш у main, CI збирає проєкт, на сервері pm2 restart — nginx віддає 502, поки процес піднімається. Проблема масова без Kubernetes.

Дві часті помилки:

  1. pm2 restart — процес зникає, порт порожній.
  2. Видалення .next на живому сервері до завершення next build.

Рішення — pm2 reload у cluster mode: нові воркери стартують, старі гаснуть після готовності.

Чому це важливо

Для малого й середнього трафіку VPS + PM2 часто дешевший і простіший за кластер Kubernetes — якщо reload налаштований правильно.

Підхід Плюси Мінуси
PM2 на VPS Простий CI Самі стежите за SSL і масштабом
Kubernetes Rolling update Складність для одного застосунку

На практиці

  1. Next у cluster (instances: max або фіксована кількість).
  2. Після збірки — pm2 reload, не restart.
  3. .next збирати в CI; не чистити .next під працюючим процесом.
  4. Healthcheck nginx після reload.

Підсумок

502 при деплої — зазвичай помилка процесу релізу, а не «прокляття» Next. Для VPS часто вистачає PM2 з reload; Kubernetes — коли зросли вимоги до відмовостійкості.