Azure App Service will end extended support for Node.js 22 LTS on April 30, 2027. The announcement went out on the Azure Updates feed on August 24, and it follows the pattern anyone running Node workloads on the platform already knows: your apps keep running after the cutoff, but they stop receiving security updates, and Microsoft stops providing customer support for the runtime.
Nothing breaks on May 1, 2027. That is precisely the problem. The apps that stay on an unsupported runtime work fine right up until a Node or V8 vulnerability lands with no patch coming, at which point you are doing an emergency migration instead of a planned one.
The cadence is annual and predictable
This is the second year running for this exact sequence. Extended support for Node 20 LTS ended April 30, 2026, with the same warning language. App Service follows the community LTS timelines rather than inventing its own, so Node 22’s retirement date simply tracks Node.js end-of-life for that release line. If you were caught by the Node 20 cutoff this year, you already know the drill. If you upgraded to 22 to escape it, you have traded an eight-month reprieve for the same deadline wearing a different number.
The safe target is Node 24, which has been available on App Service for Linux since October 2025. It ships V8 13.6 and npm 11, and brings JavaScript features that previously needed polyfills: RegExp.escape, Float16Array, global URLPattern, and better WebAssembly memory handling. The built-in node:test runner now waits on nested subtests automatically, which removes a class of flaky CI failures where tests reported success before async cleanup finished.
Find your exposed apps first
Notification emails about runtime retirements go to account admins, service admins, and co-admins. Contributors and readers get nothing unless they opt in through Service Health alerts, so if you are the person who actually maintains the apps, do not assume the notice reached your inbox. Query for it directly:
resources
| where type =~ "microsoft.web/sites"
| extend linuxFx = tostring(properties.siteConfig.linuxFxVersion)
| where linuxFx == "NODE|22-lts"
| project resourceGroup, name, linuxFxThat catches Linux apps, which is where most Node workloads live. Windows App Service apps track the runtime differently, so check the application settings on those separately. While you are in there, look for apps with no runtime pinned at all, since those inherit whatever the platform default is and can drift between regions.
What the upgrade involves
For most apps this is a one-line change to the stack configuration, plus a staging-slot test. The mechanical part is updating linuxFxVersion to NODE|24-lts (or the equivalent Windows setting) and swapping slots after validation. The risk lives in the details:
- Native modules compiled against older Node ABI versions need a rebuild, and some abandoned packages never got Node 24 support.
- App Service controls minor and patch versions of the runtime. You cannot pin
24.3.1; the platform decides. If you need an exact version, the supported path is a custom container. - Behavioral changes in V8 and npm occasionally surface latent bugs that only appear under the newer engine, which is why the staging slot exists.
Microsoft’s language support policy is explicit that unsupported runtimes must be upgraded before App Service will provide support at all, so an app stuck on Node 22 in April 2027 is also an app that cannot open a normal support ticket.
Eight months is enough, if you start
The deadline is far enough out that nobody needs to panic, and close enough that “later” quietly becomes next year’s fire drill. The practical move is to run the KQL query this week, size the list, and schedule the upgrades before the December change freeze. Teams that did this for Node 20 found the migration mostly uneventful; the ones who hit trouble were the ones who discovered native module breakage in March with no slack left in the schedule.
The update notice links to Microsoft’s Node version upgrade guidance at aka.ms/nodeversion. Read it, run the query, and book the work in. Node 24 has been a stable target on the platform for the better part of a year, which is about as de-risked as a runtime migration gets.
Common migration snags
A short list of things that actually break, gathered from teams that ran this migration for Node 20. Global tooling installed through npm at image level disappears when the base image changes, so anything your deployment scripts assume is present needs to move into your project dependencies or a startup script. Memory behavior shifts slightly between V8 versions, and apps tuned to run right at the App Service plan’s memory ceiling sometimes tip over after the swap; bump the plan before you blame the runtime. Diagnostics settings and logging extensions are tied to the app, not the runtime, so those carry over cleanly, but custom startup commands that invoke node by absolute path will break because the Node 24 image puts the binary somewhere else. Finally, check any native modules early: bcrypt, sqlite3, canvas, and their relatives need rebuilds for the new ABI, and if one of them has no Node 24 prebuilt binary available, the fallback compile path needs build tools on the image, which the slim default images do not include. Finding this out in a staging slot on a Tuesday costs an hour. Finding it in production cutover in April costs a lot more.