SonyDev Blog
Назад к статьям

11.05.2026 · Разработка

Node.js 24 LTS: когда пора обновлять серверные проекты

Node.js 24 уже находится в LTS, а старые ветки постепенно уходят. Разбираемся, как обновлять серверные проекты без случайного простоя.

Node.js удобно обновлять, пока проект маленький. Когда вокруг уже появились systemd-сервисы, PM2, cron, сборка фронтенда и пара старых зависимостей, переход на новую LTS-ветку внезапно становится отдельной задачей.

На май 2026 года Node.js 24 находится в LTS, Node.js 22 тоже остается поддерживаемой LTS-веткой, а Node.js 20 уже отмечен как EOL на странице релизов Node.js. Это хороший момент хотя бы посмотреть, что стоит на сервере.

С чего начать

node -v
npm -v
which node
systemctl list-units --type=service | grep -i node

Если проект запускается через systemd, стоит открыть unit-файл и проверить WorkingDirectory, ExecStart, пользователя и переменные окружения. Нередко оказывается, что интерактивная shell-сессия видит один Node.js, а сервис запускается с другим PATH.

Почему LTS важнее “самой новой” версии

Для продакшена обычно лучше LTS, а не Current. Current интересен для тестов и библиотек, но серверным приложениям чаще нужна предсказуемость: security fixes, совместимость и понятный срок поддержки.

Node.js официально описывает цикл так: major-версии сначала находятся в Current, а четные версии после шести месяцев переходят в Active LTS. Production-приложения рекомендуется держать на Active LTS или Maintenance LTS.

План обновления без боли

Я бы делал так:

  1. Проверить текущую версию Node.js на сервере и локально.
  2. Обновить зависимости в отдельной ветке.
  3. Запустить тестовую сборку.
  4. Проверить runtime warnings.
  5. Развернуть на staging или хотя бы на отдельном порту.
  6. Переключить systemd unit.
  7. Оставить старую версию как быстрый rollback.

Если используется nvm, важно помнить: systemd сам по себе не читает твой интерактивный .bashrc. Для сервисов лучше явно указывать путь к бинарнику или использовать пакетный менеджер/официальные бинарники.

Что ломается чаще всего

Поэтому лучший индикатор готовности — не node -v, а успешная сборка и запуск конкретного приложения.

Источники