Node.js 26 перешел в LTS: как обновить сайт и CRM
28 октября 2026 года ветка Node.js 26 перешла в долгосрочную поддержку — LTS. Первым выпуском с этим статусом стал Node.js 26.13.0 Lithium. Для команд, которые поддерживают сайт, личный кабинет, CRM или интеграционный сервис на Node.js, появился новый вариант рабочей платформы с поддержкой, запланированной до конца апреля 2029 года.
Переход требует проверки приложения: зависимостей, сборки, способа запуска и обмена с внешними системами. Работающий проект на поддерживаемой ветке 22 или 24 может сначала получить актуальные исправления своей ветки, а смену основной версии пройти отдельным релизом. Для Node.js 18 и 20 нужно планировать переход с уже завершившей обычную поддержку платформы.
Ниже — порядок выбора версии, подготовки тестовой среды и приемки обновления. Он рассчитан на разработчика, администратора и технического заказчика. Сведения о релизах проверены 30 октября 2026 года; дальнейшие patch-версии и требования зависимостей следует сверять перед вашей выкладкой.
Что означает переход Node.js 26 в LTS
В официальном анонсе указано: версия 26.13.0 меняет метаданные статуса LTS и не содержит дополнительных изменений относительно 26.12.1. Поэтому именно этот выпуск не следует представлять как новый набор функций или обещание ускорения сайта.
Для проекта практическое изменение — горизонт сопровождения выбранной ветки. Команда может планировать обновления, поддержку библиотек и следующий переход с учетом опубликованного календаря. Сам статус LTS не подтверждает совместимость вашей ORM, фреймворка, драйвера базы или собственного кода.
Проект Node.js рекомендует использовать в production ветки Active LTS или Maintenance LTS. Оба статуса допускают эксплуатацию; решение о конкретной ветке зависит также от требований приложения и плана сопровождения.
Какую версию выбрать на 30 октября 2026 года
В таблице приведены даты обычной поддержки проекта Node.js по официальному расписанию. Это календарь жизненного цикла, а не гарантия доступности конкретного приложения.
| Ветка | Статус на дату проверки | Окончание поддержки | Действие команды |
|---|---|---|---|
| Node.js 18 | EOL, поддержка завершена | 30 апреля 2025 года | Подготовить переход на поддерживаемую ветку |
| Node.js 20 | EOL, поддержка завершена | 30 апреля 2026 года | Проверить ограничения зависимостей и запланировать миграцию |
| Node.js 22 | Maintenance LTS | 30 апреля 2027 года | Ставить актуальные исправления; определить срок следующего перехода |
| Node.js 24 | Maintenance LTS с 20 октября 2026 года | 30 апреля 2028 года | Поддерживать текущую ветку либо готовить проверенный переход на 26 |
| Node.js 26 | Active LTS с 28 октября 2026 года | 30 апреля 2029 года | Рассматривать для нового проекта и миграции после проверки совместимости |
Для действующей CRM выбор начните с ее ограничений. Если критичный драйвер или библиотека официально поддерживает 24, а совместимость с 26 пока не подтверждена, переход на 24 может стать обоснованным промежуточным этапом. Зафиксируйте причину и дату следующей проверки, чтобы временное решение не осталось без владельца.
Обновление безопасности и смена major-версии имеют разный объем. Например, 21 октября 2026 года исправления были выпущены для веток 22, 24 и 26. Получение актуальных исправлений в поддерживаемой ветке не требует автоматически переводить приложение на другую major. Но и такой patch-релиз нужно проверять перед production.
Общий выбор языка, базы и архитектуры разобран в материале об устройстве кастомной CRM. Здесь задача уже: безопасно изменить среду выполнения существующего JavaScript-приложения.
Сначала найдите все процессы, использующие Node.js
На одном сервере могут работать сайт, API, обработчик очереди, бот и задания по расписанию. У них могут различаться версия Node.js, каталог приложения и пользователь запуска. Обновление бинарника в одной SSH-сессии не показывает, под чем продолжает работать каждый сервис.
Составьте короткую ведомость:
| Компонент | Что записать | Зачем это нужно |
|---|---|---|
| Сайт или API | Версию Node.js, путь к бинарнику, каталог релиза, команду запуска | Воспроизвести текущую рабочую конфигурацию |
| Фоновые обработчики | Очереди, расписание, способ завершения задачи | Не потерять работу и не запустить ее параллельно дважды |
| Сборка и CI | Версии Node.js и пакетного менеджера, lockfile | Сравнивать одинаковые условия сборки |
| Контейнер | Базовый образ и идентификатор собранного образа | Подготовить повторяемую выкладку и откат |
| Менеджер процессов | Пользователя, interpreter, рабочий каталог и автозапуск | Проверить запуск после обновления и перезагрузки |
В выбранной среде можно получить сведения о запущенной команде Node.js:
node -p 'JSON.stringify({node:process.version,execPath:process.execPath,platform:process.platform,arch:process.arch,modules:process.versions.modules,napi:process.versions.napi})'
npm --version
npm pkg get enginesПервый вывод относится к этому вызову node, а не ко всем процессам сервера. engines описывает заявленные ограничения пакета; отсутствие поля не доказывает поддержку любой версии. Проверьте также реально выполняющийся сервис и его конфигурацию. Секреты окружения в общий отчет переносить не требуется.
Проверьте зависимости и окружение Linux
Соберите список компонентов, без которых не выполняется основной сценарий: веб-фреймворк, ORM, драйверы БД, генерация PDF, обработка изображений, криптография, очереди и интеграционные SDK. Для каждого нужны версия, заявленная поддержка Node.js и результат проверки в целевой среде.
Особого внимания требуют нативные расширения. В документации Node.js отмечено, что изменения V8 могут потребовать адаптации и пересборки модулей, использующих его API. Это не означает, что любое расширение обязательно сломается: способ реализации, в том числе использование Node-API, имеет значение. Проверяйте конкретный пакет.
Практический порядок — заново установить зависимости в отдельной сборочной директории под целевой Node.js и ОС. Старый node_modules, скопированный из другого окружения, способен скрыть проблему до первого вызова редко используемой функции. Сам факт запуска сервера такую функцию не проверяет.
Для официальных Linux-бинарников есть отдельная деталь: в анонсе 26.13.0 напоминают о зависимости от libatomic, появившейся начиная с Node.js 25. В некоторых дистрибутивах ее нужно установить отдельно. Проверьте требования выбранного бинарника или образа на тестовой машине; команда установки зависит от ОС.
В список совместимости включите рабочие HTTPS-соединения, сертификаты и прокси. Проверяйте их с прежними требованиями к безопасности: отключение проверки сертификата ради успешного запроса скроет проблему конфигурации.
Соберите отдельный релиз с сохраненным lockfile
Перед экспериментом сохраните текущий рабочий релиз, конфигурацию запуска и сведения о его Node.js. Подготовьте резервные копии данных по правилам проекта и проверьте, кто выполнит восстановление при необходимости. Затем создайте отдельную директорию или тестовый образ для кандидата.
Для npm-проекта с package-lock.json и настроенным скриптом build базовая проверка выглядит так:
# Только в отдельной директории кандидата, не в работающем релизе
node --version
npm --version
npm ci
npm run buildПо документации npm, npm ci использует lockfile, завершается ошибкой при его несоответствии package.json и удаляет существующий node_modules перед установкой. Поэтому запускать эту команду в каталоге действующего сервиса рискованно. Сохраните и настройки пакетного менеджера, с которыми создан lockfile.
Если проект использует Yarn или pnpm, применяйте предусмотренную им установку из lockfile и зафиксированную версию менеджера. Не меняйте одновременно runtime, пакетный менеджер и весь набор зависимостей без необходимости: при сбое будет сложнее найти причину.
После установки выполните существующие тесты и production-сборку. Точное имя тестовой команды зависит от проекта. Запустите кандидата на отдельном локальном порту или в тестовом контуре, с разрешенными данными и отключенными реальными рассылками, оплатами и другими внешними действиями.
Для приложения с серверным рендерингом собирайте и запускайте кандидата под согласованной версией Node.js. Генерация новых файлов поверх каталога, который обслуживает рабочий процесс, может смешать старую конфигурацию в памяти с новым результатом сборки. Отдельный релиз упрощает проверку соответствия кода, файлов и процесса.
Что проверить в Docker и PM2
Docker: состав образа и инструмент сборки
В карточке релиза сохраните точный базовый образ и идентификатор полученного образа приложения. Обновление должно быть воспроизводимым: команда должна понимать, какой набор компонентов прошел приемку и какой образ возвращается при откате.
В рекомендациях официальных образов Node.js отмечено, что начиная с Node.js 26 Yarn в них отсутствует. Если сборка рассчитывает на уже установленный yarn, заранее определите, как проект получает нужную версию пакетного менеджера. Проверяйте именно свой образ: пользовательский Dockerfile может добавлять собственные инструменты.
При переходе сохраняйте понятные границы эксперимента. Если одновременно меняются Node.js, семейство Linux-образа и способ установки нативных библиотек, перечислите каждое изменение и проверьте его отдельно. У кандидата должны быть проверены запуск, остановка, доступ к данным и необходимые сетевые соединения.
PM2: исполняемый файл и автозапуск
Для PM2 проверьте приложение по его имени и конфигурационный файл: поля cwd, script и interpreter. В interpreter можно указать абсолютный путь. Это позволяет явно задать, какой Node.js запускает конкретный сервис.
Отдельно проверьте автозапуск после перезагрузки. Документация PM2 требует обновить startup-конфигурацию после обновления локальной версии Node.js. Иначе проверенный ручной запуск и следующий запуск системы могут использовать разные пути.
Изменения выполняйте по плану нужного приложения, с сохранением прежней конфигурации для отката. Общий перезапуск всех процессов не является приемочным тестом одного обновляемого сервиса.
Как принять обновление сайта или CRM
Успешный HTTP-ответ главной страницы — начало проверки. После смены runtime важны те действия, ради которых бизнес использует приложение. Для каждого подготовьте исходные данные, ожидаемый результат и подтверждение выполнения.
| Сценарий | Что проверить | Подтверждение |
|---|---|---|
| Публичные страницы | Главную, услуги, кейсы, нужные языковые версии | Верные HTTP-коды, заголовки, canonical и содержание |
| Файлы интерфейса | Скрипты, стили, изображения и загрузку динамических компонентов | Отсутствие ошибок загрузки и смешения файлов релизов |
| Вход и права | Обычного пользователя и роль с ограничениями | Доступны свои данные, чужие записи закрыты |
| Форма обращения | Прием, сохранение и последующую доставку | Связанный идентификатор заявки и результата в CRM |
| Обмен и очереди | Одну штатную операцию, временный отказ и повтор | Результат находится; повтор не создает лишнее действие |
| Документы и файлы | Загрузку, скачивание и генерацию, если предусмотрены | Файл открывается, права соблюдаются |
| Длительные соединения | WebSocket или другую используемую связь | Событие приходит, восстановление соединения работает |
| Нагрузка | Сопоставимые операции в старой и новой среде | Время ответа, ошибки, CPU, память и состояние очередей |
Для форм используйте подробные сценарии из статьи об интеграции сайта с CRM. Сообщение в браузере и письмо разработчику не заменяют проверку полного пути обращения.
Не назначайте универсальный допустимый рост задержки или время наблюдения. Согласуйте границы до релиза по текущим показателям и бизнес-сценарию. Если фоновая задача выполняется ночью, несколько минут проверки днем не подтверждают ее работоспособность.
Подготовьте переключение и откат
До выкладки запишите условия остановки выпуска. Например: не проходит вход, нарушена доставка заявок, растет число ошибок согласованного API или зависла очередь. Для каждого условия назначьте наблюдение и ответственного за решение.
План переключения должен включать:
- Идентификаторы прежнего и нового релизов, версии Node.js и зависимости.
- Подтвержденные результаты приемки кандидата.
- Порядок завершения текущих запросов и фоновых операций.
- Переключение нужного приложения и повторную проверку через публичный адрес.
- Возврат прежнего релиза вместе с его средой выполнения и конфигурацией.
- Проверку записей и задач, появившихся в период работы новой версии.
Откат кода не отменяет уже выполненную оплату, отправленное сообщение или изменение данных. Если релиз включает изменения схемы БД, заранее проверьте совместимость старого приложения с новой схемой. Для изменения runtime полезно ограничить объем релиза, чтобы возврат не зависел от нескольких несвязанных преобразований данных.
Готовность к откату проверьте на тестовом контуре до production. Сохраненный архив без инструкции запуска и понятной версии Node.js еще не подтверждает, что прежний сервис удастся восстановить в нужное время. Перенос всего сайта с изменением размещения имеет более широкий состав; для него есть отдельный чек-лист миграции корпоративного сайта.
Что передать исполнителю для оценки работ
Соберите версии Node.js и зависимостей, репозиторий или состав доступных исходников, способ развертывания, перечень процессов, критичные сценарии и ограничения по окну обслуживания. Секреты передавайте отдельно через согласованный канал. Укажите, что уже проверено, а что остается неизвестным.
Попросите разделить обследование, адаптацию зависимостей, тесты, подготовку релиза и сопровождение после переключения. Если совместимость пакета не установлена, эта неопределенность должна быть видна в оценке. Единой стоимости «обновления Node.js» без такого обследования нет.
Совместимость серверной части и интеграций можно обсудить в рамках backend-разработки. Для действующего проекта отдельно согласуйте сопровождение и условия SLA: какие показатели контролируются, кто принимает решение об откате и как команда разбирает ошибку после выпуска.
FAQ
Нужно ли срочно переводить исправно работающий проект с Node.js 24 на 26?
Переход 26 в LTS сам по себе не завершает поддержку 24. Установите актуальные исправления своей поддерживаемой ветки и составьте план миграции с учетом библиотек и срока сопровождения. Срочность конкретного обновления безопасности оценивают по официальному уведомлению и использованию затронутых функций.
Можно ли обновить только Node.js на сервере, оставив старые зависимости?
Такой вариант нужно проверять как отдельный кандидат. Нативные расширения и другие зависимости могут иметь ограничения. Чистая установка из lockfile и тесты в целевой среде дают больше информации, чем перенос прежнего node_modules и проверка одного экрана.
Можно ли гарантировать обновление без простоя?
Это зависит от архитектуры, числа экземпляров, хранения сессий, фоновых задач и способа переключения. Требование непрерывной работы включают в проект заранее и проверяют на тестовом развертывании. По одной версии Node.js такую гарантию дать нельзя.
Нужно ли обновлять Node.js, если сайт состоит из статических файлов?
Проверьте, где он используется. Node.js может участвовать только в сборке; тогда обновляют и проверяют сборочный контур. Если есть SSR, API, обработчик форм или отдельный бот, их среда выполнения требует самостоятельной проверки.
Источники
- Node.js 26.13.0 Lithium: переход в LTS 28 октября 2026 года.
- Расписание поддержки веток Node.js.
- Node.js: статусы релизов и рекомендации для production.
- Обновления безопасности Node.js от 21 октября 2026 года.
- npm CLI v11: условия работы npm ci.
- Node.js: совместимость нативных расширений.
- PM2: параметры конфигурации приложения.
- PM2: автозапуск после обновления Node.js.
- Официальные Docker-образы Node.js: рекомендации по сборке.
Материал подготовлен по документации, проверенной 30 октября 2026 года. Матрица приемки и порядок релиза — инженерные рекомендации. Они не описывают выполненную миграцию NBM-IT и требуют адаптации к конкретному приложению.