On this page · 11 sections
Summary. Azure App Service published a Node 22 LTS retirement notice at 17:30 UTC on 24 August 2026, with support ending on 30 April 2027, 249 days out. The notice tells you to "upgrade your app to Node 24 LTS before April 30, 2027". The Node.js Release Working Group schedule puts Node 24 into maintenance on 20 October 2026, 57 days after the notice, and ends it on 30 April 2028, exactly 366 days after the Node 22 cliff. Node 26 becomes Active LTS on 28 October 2026 and runs to 30 April 2029, 731 days past the cliff. Following the notice literally buys 12 months of runway. Following the Node.js schedule buys 24. App Service plans in Central India ran from $0.018 per hour for Basic B1 Linux to $0.818 for Premium v4 P3v4 on 24 August 2026, so the runway is cheap and the migration is not.
What the notice says
The retirement record is terse and worth reading in full, because the operative sentence is the last one. "On April 30 2027, support for Node 22 LTS will end. Your apps that are hosted on App Service will continue to run, but security updates will no longer be available, and we'll no longer provide customer service for Node 22 LTS. Required action: To avoid potential security vulnerabilities and minimize risk for your App Service apps, follow the steps to upgrade your app to Node 24 LTS before April 30, 2027."
The Azure release record is filed against the App Service product with an availability ring of "Retirement" for April 2027. Nothing about the date is negotiable, because App Service does not set it. The language runtime support policy is explicit: "App Service follows community support timelines for the lifecycle of the runtime."
The date the notice does not mention
That policy sentence is what makes the recommended target odd. If App Service follows community timelines, the community timeline is the document that should decide your target version. Here is what it says, taken from schedule.json in the nodejs/Release repository.
| Node.js version | Enters maintenance | End of life |
|---|---|---|
| 20 (Iron) | 22 October 2024 | 30 April 2026 |
| 22 (Jod) | 21 October 2025 | 30 April 2027 |
| 24 (Krypton) | 20 October 2026 | 30 April 2028 |
| 26 | 20 October 2027 | 30 April 2029 |
| 27 | 20 October 2027 | 30 April 2030 |
Node 22 has been in maintenance since 21 October 2025. That is 307 days before Microsoft sent the notice. Maintenance releases carry critical and security fixes only, so the narrowing everyone is being warned about started nearly ten months ago and the App Service date is the point where the platform stops relaying even those.
Node 24 has been Active LTS since 28 October 2025 and enters maintenance on 20 October 2026. That is 57 days after this notice was published. So the version Azure names as the fix will already be a maintenance release before most teams finish planning the change, and it ends 366 days after the version it replaces.
| Question | Node 24 LTS (the notice's target) | Node 26 LTS |
|---|---|---|
| Active LTS from | 28 October 2025 | 28 October 2026 |
| Enters maintenance | 20 October 2026 | 20 October 2027 |
| End of life | 30 April 2028 | 30 April 2029 |
| Runway past the 30 April 2027 cliff | 366 days | 731 days |
| Still Active LTS on 30 April 2027? | No, in maintenance since 20 October 2026 | Yes, until 20 October 2027 |
Five rows, and the fifth is the one that matters. If your reason for moving is "we want to be on a version that still gets full releases", Node 24 does not deliver that on the day the cliff arrives. Node 26 does.
Why the notice still says 24
There is a defensible reason, and it is worth stating plainly rather than treating the notice as a mistake. Node 26 does not become Active LTS until 28 October 2026, 65 days after the notice was written. Microsoft cannot name a version that is not yet an LTS line as the supported migration target, and the current App Service documentation reflects the same lag: the Node.js configuration guide uses WEBSITE_NODE_DEFAULT_VERSION="~24" on Windows and NODE|24-lts on Linux in its worked examples.
The practical consequence is a scheduling one. A team that starts the migration now and ships in Q4 2026 can land on Node 26 for the same effort, because the code changes between 22 and 24 and between 22 and 26 largely overlap. A team that follows the notice to the letter does the work twice.
What actually breaks
Three things, none of them the runtime.
You cannot pin a patch level to buy time. The language runtime support policy says App Service "updates major versions of stacks but can't guarantee any specific minor versions or patch versions" and that "the platform controls minor and patch versions". If you need a specific patch, the documented answer is a custom container, which moves runtime patching from Microsoft onto your build pipeline. That is a real operational transfer, not a config flag.
The rollback path closes. The Microsoft-maintained App Service Linux runtime notes state that "once a version of Node.js has reached it's end of life (EOL) it will no longer be available from Runtime Stack selection dropdown", while also saying that "existing applications configured to target a runtime version that has reached EOL should not be affected". Those two sentences sit badly next to a retirement notice that says security updates stop. The reconciliation: your app keeps running on the setting it already has, but you cannot select that setting again, so a post-cliff rollback from Node 24 to Node 22 is not a portal operation.
The notification may not reach the people who own the app. The support policy lists the roles that receive reminders as account administrators, service administrators and coadministrators, and states that "contributors, readers, or other roles don't directly receive notifications unless they opt in to receive notification emails by using Service Health Alerts". On a subscription where the platform team holds Contributor, nobody on that team is on the list by default.
What to do, in order
- Inventory. On Linux,
az webapp config show --resource-group <rg> --name <app> --query linuxFxVersion. On Windows, query theWEBSITE_NODE_DEFAULT_VERSIONapp setting. Both commands are in the App Service Node.js configuration guide.
- Decide the target version against the Node.js schedule, not the notice. If you will ship after 28 October 2026, target Node 26 and skip a migration.
- Subscribe the platform team to Service Health Alerts so the next retirement notice reaches the people who own the change.
- Change the stack setting last. The runtime support notes warn that changing stack settings restarts the application, so it belongs in a maintenance window with a slot swap behind it.
Do not treat this as a version bump. The real cost is usually the dependency tree, not the runtime: native modules compiled against a V8 ABI, packages that pinned an engines range at Node 22, and build images in your pipeline that still install 22.
What the plan costs while you migrate
These are Azure Retail Prices API values for Linux App Service plans in Central India, queried on 24 August 2026.
| Tier | SKU | USD per hour |
|---|---|---|
| Basic | B1 | 0.018 |
| Basic | B2 | 0.036 |
| Standard | S3 | 0.352 |
| Premium v4 | P1v4 | 0.204 |
| Premium v4 | P3v4 | 0.818 |
Five rows. The runtime itself carries no line item in that result set, which is the point: the retirement costs you engineering time, not Azure spend.
India-specific considerations
For teams running App Service from Central India, the 30 April 2027 date lands in the first month of the Indian financial year, which is usually the worst possible window for an unplanned platform change. Pulling the work into the 2026-27 financial year is the cheaper choice on both the budget and the risk side. Where the application processes personal data, note that running a runtime with no security updates past 30 April 2027 is difficult to defend as a reasonable security safeguard under the Digital Personal Data Protection Act 2023, and the App Service notice is now dated evidence that you were told.
What is still unknown
Microsoft has not published an App Service availability date for Node 26, and the Node.js configuration guide still shows Node 24 in its examples. Whether App Service adds a Node 26 stack option shortly after 28 October 2026, and whether the retirement notice is later amended to name it, are both open as of 24 August 2026.
FAQ
How eCorpIT can help
Runtime retirements are the cheapest migrations to plan and the most expensive to postpone. Our cloud migration and modernization practice handles App Service runtime moves as dependency work first and stack-setting work last, which is the order that keeps the rollback usable. If your estate has Node 22 apps and no inventory of them, ask for an App Service runtime audit and we will start with linuxFxVersion across the subscription. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised.
Related reading: the Node.js one-release-per-year cadence change and Node 27, our Bun versus Node.js backend runtime decision, the App Service Isolated v4 cost and performance decision, and the Interop 2026 web platform guide.
References
- Azure updates: Retirement: Support for Node 22 LTS ends on April 30, 2027 (published 24 August 2026)
- Azure Retail Prices API (queried for Azure App Service, Central India, 24 August 2026)
Last updated: 24 August 2026.