Node.js 20 : Cloud Run coupe le runtime le 30 octobre

Les équipes qui font tourner du Node.js 20 sur Google Cloud ont trois jours pour agir. Selon le calendrier de cycle de vie publié par Google, le runtime Node.js 20 de Cloud Run, qui sert aussi aux fonctions Cloud Run, sera décommissionné le 30 octobre 2026. Passé cette date, il ne sera plus possible de créer ou de mettre à jour une charge de travail qui l'utilise, et celles qui restent dessus pourront être désactivées.

Ce que signifie « décommissionné »

Google distingue deux étapes dans la fin de vie de ses runtimes. La première, la dépréciation, est intervenue pour Node.js 20 le 30 avril 2026. Pendant cette phase, on peut généralement continuer à créer et à mettre à jour des services, mais Cloud Run n'assure plus de support sur le runtime, et les correctifs du langage et du système suivent la politique de mise à jour automatique des images de base.

La seconde étape, le décommissionnement, est plus radicale. La documentation de Cloud Run est explicite : après cette date, « vous ne pouvez plus créer de nouvelles charges de travail ni mettre à jour les charges existantes » avec ce runtime, et celles qui continuent à l'utiliser « peuvent être désactivées ».

Node.js 20 n'est déjà plus maintenu

Ce couperet découle du calendrier du projet Node.js. La branche 20, baptisée Iron et publiée en avril 2023, est marquée en fin de vie (EOL) sur le site officiel, sa dernière version datant du 24 mars 2026. Elle ne reçoit donc plus de correctifs de sécurité de la part de la communauté.

Les branches maintenues sont aujourd'hui Node.js 22 et Node.js 24, toutes deux en LTS. Node.js 26 doit les rejoindre très prochainement, comme nous l'expliquions dans notre article sur le passage de Node.js 26 en LTS et le nouveau rythme de Node.js 27. Côté Cloud Run, Node.js 26 n'est toutefois encore proposé qu'en préversion.

Vers quelle version migrer

Cloud Run publie des dates précises pour les runtimes suivants :

• Node.js 22 : dépréciation le 30 avril 2027, décommissionnement le 31 octobre 2027 ;
• Node.js 24 : dépréciation le 30 avril 2028, décommissionnement le 31 octobre 2028.

Pour une migration faite dans l'urgence, Node.js 22 limite l'écart de version, mais n'offre qu'un an de répit avant le prochain couperet. Node.js 24 demande sans doute davantage de tests, mais repousse l'échéance à fin 2028. Dans les deux cas, il faut vérifier la compatibilité des dépendances natives et des modules qui s'appuient sur des API modifiées entre les versions majeures.

Comment s'y prendre

La migration consiste à redéployer chaque service ou fonction en désignant un runtime plus récent. Google accepte trois façons d'indiquer l'image de base : l'identifiant du runtime seul (nodejs22 ou nodejs24), recommandé dans la plupart des cas, l'association d'une pile et d'un runtime (par exemple google-24-full/nodejs24) quand un paquet système particulier est nécessaire, ou le chemin complet de l'image dans Artifact Registry pour contrôler précisément la région de provenance.

Quelques réflexes avant la date butoir :

• Inventorier les services et fonctions encore en nodejs20, y compris les projets annexes et les environnements de préproduction ;
• Mettre à jour le champ engines du package.json et la version de Node.js utilisée en intégration continue, pour tester sur la même version que la production ;
• Redéployer d'abord un service peu critique, puis valider les journaux et les métriques avant de généraliser.

Les mises à jour de sécurité automatiques des images de base restent activées par défaut sur Cloud Run, mais Google rappelle qu'elles ne dispensent pas de changer de runtime avant la fin de son support.