По состоянию на 3 июня 2026 года переход GitHub Actions с Node.js 20 на Node.js 24 уже нельзя считать отдаленной технической новостью. Для бизнеса это риск из практической плоскости: сборка может начать выдавать предупреждения, часть actions окажется несовместимой с новым runtime, self-hosted runner потребует обновления ОС, а релиз в интернет-магазине, личном кабинете или API-сервисе зависнет в самый неудобный момент.
GitHub в changelog сообщил, что Node.js 20 для GitHub Actions выводится из использования после завершения жизненного цикла Node.js 20. В актуальном примечании к публикации GitHub указывает дату начала переключения runner на Node.js 24 по умолчанию: 16 июня 2026 года. В расписании Node.js 20 уже отмечен как End-of-Life с 30 апреля 2026 года, а Node.js 24 находится в статусе Active LTS. Дополнительно в релизах runner images есть отдельное объявление о смене установленной по умолчанию версии Node.js на образах и удалении Node.js 20.
Для владельца проекта это не значит, что сайт немедленно перестанет работать. Но это значит, что релизный контур нужно проверить до того, как предупреждения превратятся в отказ сборки.
Что именно меняется
В GitHub Actions есть два разных слоя, которые часто смешивают.
Первый слой — runtime для JavaScript actions. Когда workflow использует сторонний action, например для checkout, сборки, деплоя, публикации артефактов или отправки уведомлений, сам action может быть написан под Node.js 20. GitHub переводит такие actions на Node.js 24, поэтому старые версии actions нужно обновить или протестировать принудительно.
Второй слой — версия Node.js внутри самой сборки проекта. Если Next.js, Node.js API, frontend-приложение или мобильный проект с web-сборкой собирается командой npm, pnpm или yarn, версия Node.js должна быть явно задана через setup-node, Docker-образ, Volta, asdf,.node-version или другой механизм. Если проект просто полагается на установленную по умолчанию версию runner image, результат может измениться без участия команды.
Есть и третий слой — self-hosted runners. Если компания держит runner на собственном сервере, старой macOS, ARM32-устройстве или нестандартной Linux-сборке, важно проверить совместимость с Node.js 24 и обновить сам runner. GitHub отдельно предупреждает, что Node.js 24 несовместим с macOS 13.4 и ниже, а ARM32 для Node.js 24 официально не поддерживается.
Почему это важно для рабочих сайтов
CI/CD редко виден пользователям, пока работает нормально. Но именно он отвечает за предсказуемый путь от задачи к релизу: прогон тестов, сборку фронтенда, миграции, деплой API, публикацию мобильных артефактов, проверку линтеров, доставку уведомлений и откат.
Если workflow ломается, бизнес получает не абстрактную DevOps-проблему, а конкретные задержки:
- исправленная ошибка в форме заявки не доезжает до production;
- обновление оплаты или CRM-интеграции откладывается;
- критический security patch нельзя безопасно выкатить;
- разработчики начинают чинить сборку вместо продуктовой задачи;
- релизы становятся ручными, а значит менее повторяемыми и более рискованными.
Для проектов на Next.js, Nuxt, NestJS, Express, Strapi, headless CMS и сложных SPA риск выше: сборка напрямую зависит от Node.js, lock-файла, версии пакетного менеджера и нативных зависимостей. Но даже PHP-проект на Symfony или Laravel может зависеть от Node.js в frontend pipeline, сборке ассетов, Storybook, Cypress, Playwright или Vite.
Что проверить в первую очередь
1. Actions, которые выполняются на Node.js 20
Откройте все workflow-файлы в.github/workflows и посмотрите, какие actions используются. В зоне внимания не только очевидные actions от GitHub, но и сторонние actions для деплоя, SSH, Docker, уведомлений в мессенджеры, работы с секретами и публикации артефактов.
Типовой порядок проверки:
- обновить официальные actions до актуальных major-версий, где уже поддержан Node.js 24;
- посмотреть changelog сторонних actions;
- убрать заброшенные actions, если у них нет свежих релизов;
- заменить самописный action на shell-команду или Docker action, если поддерживать JavaScript action больше некому;
- проверить, нет ли предупреждений о Node.js 20 в последних job logs.
Важно не обновлять все blindly за один коммит. Например, новая major-версия action может менять входные параметры, права доступа, формат артефактов или поведение кеша. Правильнее собрать матрицу: action, текущая версия, новая версия, риск, тестовый workflow, результат.
2. Версию Node.js для сборки проекта
Если проект собирается через npm, pnpm или yarn, версия Node.js должна быть закреплена. Надежный workflow не зависит от того, что сегодня установлено на runner image.
Для сайта или сервиса стоит проверить:
- есть ли.nvmrc,.node-version, packageManager в package.json или Volta-конфигурация;
- какую версию задает actions/setup-node;
- совпадает ли версия в CI с Dockerfile, production-сервером и локальной разработкой;
- не использует ли проект Node.js 20 после его End-of-Life;
- проходят ли install, build, test и lint на Node.js 22 или 24.
Если проект пока не готов к Node.js 24, это нормально. Но тогда нужен план: сначала поддерживаемая LTS-ветка, затем обновление зависимостей, затем тесты на Node.js 24. Самый опасный вариант — обнаружить несовместимость только после изменения runner.
3. Self-hosted runners и серверы сборки
Self-hosted runner часто ставится один раз и годами живет без внимания. Перед миграцией проверьте версию runner, ОС, архитектуру, права сервисного пользователя, доступ к Docker, кеши, временные каталоги и сетевые ограничения.
Особенно внимательно стоит смотреть на runners, которые обслуживают:
- production-деплой;
- сборку мобильных приложений;
- подписывание артефактов;
- доступ к закрытым окружениям;
- интеграции с CRM, оплатой и внутренними API.
Если runner работает на старой macOS или нестандартной архитектуре, обновление может потребовать не только новой версии runner, но и переноса сборки на другой хост.
Как безопасно провести обновление
Практичный сценарий состоит из пяти этапов.
Этап 1. Инвентаризация
Соберите список workflows, actions, self-hosted runners, Docker-образов и package manager. Отдельно отметьте workflow, которые отвечают за production-деплой, миграции базы, публикацию мобильных сборок и критические интеграции.
На этом этапе не нужно сразу переписывать CI/CD. Задача — понять, где есть Node.js 20, где версия не закреплена, где используются устаревшие actions и где нет тестового контура.
Этап 2. Тестовый прогон Node.js 24
Для JavaScript actions GitHub предлагает принудительно проверить Node.js 24 через переменную окружения FORCE_JAVASCRIPT_ACTIONS_TO_NODE24. Такой тест лучше запускать в отдельной ветке или staging workflow, чтобы не рисковать production-релизом.
Для сборки самого проекта используйте отдельную matrix-конфигурацию: текущая LTS-версия, следующая LTS-версия, Node.js 24. Это покажет, где ломаются зависимости, тесты, native modules или сборка ассетов.
Этап 3. Обновление actions и зависимостей
Обновляйте actions группами: сначала official actions, затем сторонние, затем самописные. После каждой группы фиксируйте результат: install, build, tests, deploy dry-run, публикация артефактов.
Если проект использует Next.js, Vite, Webpack, Playwright, Cypress или Storybook, отдельно проверьте совместимость версий. Иногда проблема не в Node.js как таковом, а в старом transitive dependency или бинарном пакете, который не собирается на новом runtime.
Этап 4. Проверка релизного пути
CI/CD считается обновленным не тогда, когда зеленеет один job, а когда весь путь релиза воспроизводим:
- тесты проходят;
- артефакты собираются;
- секреты читаются только там, где нужно;
- деплой идет в правильное окружение;
- миграции контролируются;
- уведомления приходят;
- rollback остается понятным.
Для сайтов с заявками, оплатой, личными кабинетами и API полезно добавить post-release smoke tests: открыть ключевые страницы, проверить форму, авторизацию, webhook или интеграцию, которая обычно страдает после срочных релизов.
Этап 5. Документация и регламент
После обновления зафиксируйте, какая версия Node.js используется в CI, почему она выбрана, где закреплена, когда следующая проверка. Это простая вещь, но она снижает риск повторного аврала через год.
Где OpenStart может помочь
OpenStart ведет поддержку сайтов, API, CRM, личных кабинетов и мобильных приложений не только в момент аварии, но и в плановом режиме. Для такой задачи мы обычно начинаем с технической диагностики: смотрим workflows, версии Node.js, package manager, Dockerfile, self-hosted runners, историю падений сборки и связку CI/CD с production.
После этого можно составить понятный план:
- что обновить сразу;
- что вынести в staging;
- какие actions заменить;
- какие зависимости требуют отдельной проверки;
- где добавить smoke tests;
- как не сорвать ближайший релиз.
Для бизнеса это важнее, чем просто «обновить Node». Цель — сохранить управляемый релизный процесс: чтобы исправления, интеграции и security patches доходили до пользователей без ручного героизма и ночных откатов.
Короткий чек-лист
Проверьте проект до переключения runner:
- в workflow нет устаревших actions на Node.js 20 без свежих версий;
- версия Node.js для сборки проекта закреплена явно;
- self-hosted runner обновлен и совместим с Node.js 24;
- production-деплой протестирован на staging;
- cache, artifacts и secret-dependent steps работают после обновления;
- есть понятный rollback;
- владелец проекта знает, кто отвечает за CI/CD и когда будет следующая проверка.
Если в проекте уже появились предупреждения GitHub Actions или релизы стали нестабильными, лучше не ждать даты переключения. Технический аудит CI/CD обычно дешевле, чем срочно восстанавливать сборку в день важного обновления.