End-of-life for Node.js v20 er ikke overraskende. Versjonssyklusen har vært kjent lenge, og nodejs.org publiserer disse datoene lenge i forveien. Likevel er det mange prosjekter som ikke er klare. Årsaken er enkel: det er lett å prioritere ned runtime-oppgraderinger når alt tilsynelatende fungerer. Problemet er at «fungerer» og «støttes» er to veldig forskjellige ting, og fra 1. mai er Node 20 i den første kategorien, ikke den andre.
For team som kjører workloads på AWS Lambda, er tidslinjen særlig tydelig. Ifølge CloudQuery blokkerer AWS opprettelse av nye funksjoner på nodejs20.x-runtimen fra juni, og oppdatering av eksisterende funksjoner fra september. Det er ikke en myk overgang – det er en hard stopp. Google Cloud Run setter Node 20 i deprecated-status fra 30. april, med decommission-dato 30. oktober. Azure følger samme mønster.
Hvilken versjon bør man gå til?
DEV Community anbefaler å hoppe direkte til Node.js v24 fremfor v22, ettersom v22 uansett når EOL i april 2027. Det gir lengre ro og unngår en ny migrering om ett år. Det finnes imidlertid noen fallgruver å kjenne til: import-syntaksen endret seg mellom v20 og v22 (assert erstattet av with), og native addons som sharp, bcrypt og better-sqlite3 kan krasje med en NODE_MODULE_VERSION-feil dersom de ikke er rekompilert mot den nye versjonen. En grundig gjennomgang av avhengigheter i package.json er et nødvendig første steg.
Vi i JPro anbefaler alltid å starte migreringen i et testmiljø med full test suite aktivert, og å sjekke om pakkene prosjektet avhenger av allerede har droppet Node 20 fra sine engines-felt. Noen har det, og det kan påvirke lockfilen på uforutsigbare måter.
Dersom Node.js-migreringen ikke allerede er i gang, er nå rett tidspunkt. En god start er å kartlegge hvilke tjenester og funksjoner som kjører på Node 20, identifisere de mest kritiske avhengighetene, og planlegge en oppgradering i to steg: test og staging først, produksjon etter validert gjennomgang. Det er ikke en stor jobb for de fleste prosjekter – men det er en jobb som bør gjøres nå, ikke etter at AWS begynner å blokkere.
Verdt å vite
Mens teams håndterer Node.js-migreringen, er det verdt å ta med seg at den bredere cloudbildet er i bevegelse. AWS lanserte nylig Trainium3-instanser, som ifølge selskapet er tre ganger raskere enn forgjengeren Trainium2 for AI-trening – et tydelig signal om at skyleverandørene konkurrerer hardt om AI-workloads. Google Cloud kuttet compute-prisene med 8 % på tvers av alle regioner i første kvartal 2026, noe som kan ha reell innvirkning på kostnadskalkylene for compute-intensive prosjekter. Azure på sin side har integrert GPT-5 nativt i sine enterprise-tjenester, og reduserer dermed friksjonen for organisasjoner som ønsker å bygge AI-funksjonalitet direkte inn i eksisterende Microsoft-arkitektur.
Disse bevegelsene minner om noe vi ser jevnlig i prosjektene vi er en del av: valg av skyplattform handler ikke lenger bare om pris og tilgjengelighet, men i stadig større grad om hvilke AI-kapabiliteter som er tett integrert i plattformen. Arkitektur og cloud-strategi henger tettere sammen enn noensinne.
Har du spørsmål om migreringsstrategi eller lurer på hvordan endringene i cloudlandskapet påvirker arkitekturen i ditt prosjekt? Ta gjerne kontakt med oss.
