Azure infographic highlighting Node.js upgrades to v24 LTS and Linux Functions moving from Consumption to Flex Consumption.
Microsoft support for Node.js 22 on Azure ends April 30, 2027. After that date, apps still running Node.js 22 will keep working, but Microsoft will no longer ship security updates for the runtime or provide customer service for it. Microsoft's instruction to Azure App Service customers is to move to Node 24 LTS before the deadline. The date is the same one the Node.js project set for the end of the 22.x line, so Azure is following the open-source lifecycle and adding no extra time on top of it. Seven months is enough for most teams to move. Some Azure Functions customers have a harder job, because for them the runtime upgrade may also mean changing hosting plans.

Azure App Service Sets April 30, 2027 as the Node 22 LTS Cutoff​

The clearest version of the notice is Microsoft's Azure Updates retirement post from August 24, 2026, titled "Support for Node 22 LTS ends on April 30, 2027." It covers apps hosted on Azure App Service. Those apps continue to run after the date, but security updates stop and Microsoft stops providing customer service for Node 22 LTS. The required action is to follow Microsoft's steps and upgrade each app to Node 24 LTS before April 30, 2027. Microsoft points customers to its short link aka.ms/nodeversion for version-specific upgrade steps.

A second Azure Updates record, published September 22, 2026, carries a slightly different title: "Retirement: Support for Node.js 22 ends on April 30, 2027." Its body was not available when we checked, so it is unclear which service it covers. Microsoft has used this naming before. Its earlier Node 20 notice, "Support for Node.js 20 ends on April 30, 2026 – upgrade your apps to Node.js 22," said that "In alignment with the end of community support, on April 30, 2026, support for Node.js 20 in Azure Functions will end." The later record is probably the Azure Functions version of the App Service notice. That is our inference from the naming pattern, not something Microsoft has confirmed. The deadline is the same either way.

Neither notice describes a shutdown. Microsoft is not deleting apps, not stopping them, and not upgrading them automatically on May 1, 2027. What ends is the patching and support that makes it reasonable to run a production workload on a managed runtime.

The Node.js 22 "Jod" Lifecycle Sets the Azure Deadline​

Microsoft did not choose this date itself. The Node.js Release Working Group's schedule lists 22.x (codename Jod) as follows:

  • It was first released on April 24, 2024.
  • It entered Active LTS on October 29, 2024.
  • It moved to Maintenance LTS on October 21, 2025.
  • Its end of life is set for April 30, 2027.

The project notes that "dates are subject to change." In practice, April end dates for even-numbered releases have been very consistent.

Microsoft's App Service language runtime policy says the service follows community support timelines for each runtime. Once community support ends, apps using that runtime "continue to run unchanged," but App Service "can't provide security patches or related customer support for that runtime version past its end-of-support date." The policy also says that if your app uses an unsupported language version, you must upgrade it to a supported version before it can get App Service support. After the deadline, a support ticket about a Node 22 app is likely to start with a request to upgrade.

Azure Functions has followed the same rule. When Node.js 20 reached end of life, Microsoft framed the Functions retirement as matching the end of community support. It told customers that apps hosted on Functions would continue to run, but security updates and performance optimizations would no longer be available. The Azure SDK team follows the same lifecycle. It said that on July 9, 2026, the Azure SDK for JavaScript would specify Node.js 22.x as the minimum supported version in its engines field. Based on that pattern, expect the SDK to set a higher minimum some time after April 2027, though Microsoft has not announced one yet.

"Continues to Run" Stops Being Safe After Node.js 22 EOL​

An app that keeps running looks fine on a dashboard, which is why these deadlines tend to get missed. The Node.js project's end-of-life guidance explains the risk. An EOL release line gets no more updates, including security patches. When a vulnerability is fixed in a newer line, the EOL line gets no release even if the same bug affects it. The project warns that users of affected code paths are then immediately exposed to attacks that use those publicly disclosed flaws.

The project lists other problems too. Popular npm packages gradually drop support for EOL runtimes, and many industry audits forbid unmaintained runtimes. For an enterprise app, the compliance finding may cause trouble before any exploit does.

Microsoft answered a similar question about Node.js 20 on Azure Logic Apps Standard on its Q&A forum. The answer said there is no planned "hard stop" or automatic shutdown solely due to the Node.js 20 end‑of‑support milestone. It also warned that any new security issues discovered after this date will remain unpatched, and Microsoft Support may ask you to upgrade before investigating runtime‑related issues. The same answer added that in the future, platform changes, host upgrades, or redeployments may require moving to a supported Node.js version. That was about Logic Apps and Node 20. Node 22 on App Service is likely to work the same way, with no hard stop, a gradual loss of support, and possible future platform changes that could force the issue.

For teams that truly cannot upgrade in time, the Node.js project lists commercial extended-support vendors: HeroDevs, NodeSource, and TuxCare, which operate through the OpenJS Foundation's Ecosystem Sustainability Program. The project calls this "a temporary solution." Paying a vendor for patches also does not bring back Microsoft's support for the runtime on App Service.

Node 24 "Krypton" Is Microsoft's Target, and Its Own Clock Is Running​

Microsoft names Node 24 LTS as the upgrade target. According to the Node.js schedule, 24.x (codename Krypton) was released May 6, 2025, entered Active LTS on October 28, 2025, and has an end of life of April 30, 2028.

Node 24 moves into Maintenance LTS on October 20, 2026, less than a month from now. Most apps migrated this winter will therefore land on a runtime that already receives only critical bug fixes and security updates. That is still a supported state. It does mean an app moved to Node 24 in early 2027 has about a year before this whole process repeats.

Node 26 is scheduled to become Active LTS on October 28, 2026, with an end of life of April 30, 2029, which would give a longer runway. Microsoft's notice does not mention Node 26. We have not confirmed whether or when App Service or Functions will offer it as a runtime stack, so Node 24 remains the upgrade path Microsoft has documented.

Microsoft's App Service policy has one more detail that matters when choosing a version. App Service updates major versions of a runtime but does not guarantee a particular minor or patch version, because the platform controls those. Selecting Node 24 gives you whatever 24.x build the platform currently provides. If you need a pinned minor or patch version, Microsoft's answer is a custom container.

Azure Functions Linux Consumption Plans Turn a Runtime Bump Into a Replatform​

This part could be expensive for anyone running Node.js on Azure Functions. Microsoft's Functions runtime documentation, updated in the past week, says that Node.js 22 is the last Node.js version supported for Linux Consumption plan apps. Newer Node.js versions aren't added to Linux Consumption.

If you have a Node 22 function app on the Linux Consumption plan, you cannot simply change the runtime to Node 24. Staying on a supported Node version means leaving the plan. Microsoft says that the option to host function apps on Linux in a Consumption plan is retiring on 30 September 2028. The Linux Consumption plan isn't getting any new features or language versions. Its guidance is to migrate your apps to the Flex Consumption plan before the retirement date. The Linux Consumption restriction does not apply to other plans: apps running on Windows in a Consumption plan aren't currently affected.

The dates line up in an awkward way. Node 22 support ends April 30, 2027, and Linux Consumption itself retires September 30, 2028. Teams could delay both until the second date, but they would spend 17 months on an unpatched runtime. The more sensible path is to do the Flex Consumption migration now and pick Node 24 as part of it.

The same documentation carries a nearer deadline for anyone who has fallen well behind: function apps still running the end-of-life v3 runtime on Linux in a Consumption plan stop running after September 30, 2026, eight days from now. That is a genuine hard stop, unlike the Node 22 retirement.

Retirement Emails Reach Azure Subscription Owners, Not Always Developers​

Many of these deadlines are missed because the warning goes to the wrong people. Microsoft's App Service policy says reminder notifications go to subscription owners, which means account administrators, service administrators, and coadministrators. Contributors, readers, and other roles do not receive them directly unless they opt in through Service Health Alerts.

In many organizations, the developers who own a Node 22 web app hold Contributor rights and may never see the notice. The finance or platform team that owns the subscription may not know which apps run which runtime. Configuring Service Health Alerts for the teams that own the apps is simple and closes that gap.

What This Means for You​

Any team running Node 22 on App Service or Azure Functions should plan the upgrade now and finish it before April 30, 2027. Linux Consumption Functions apps are the most urgent case, because they need a hosting-plan migration as well as a runtime change. Apps already on Node 24 need nothing immediately, but their owners should expect a similar notice before April 30, 2028.

A sensible sequence goes like this. This is our own operational guidance based on the required change, not a checklist from Microsoft.

  1. List every App Service and Function app whose runtime stack is Node 22, and record who owns each one.
  2. Mark any Functions apps on Linux Consumption. Those need a Flex Consumption migration plan, not just a version change.
  3. Test each app and its npm dependencies, including native modules, on Node 24 in a staging slot or a separate non-production app.
  4. Change the production runtime, then check that the app reports a 24.x version and passes its health checks.

For Linux App Service, Microsoft's Node configuration guidance uses the runtime value NODE|24-lts and shows how to set it with Azure CLI:

Code:
az webapp config set --resource-group <resource-group-name> \
  --name <app-name> --linux-fx-version "NODE|24-lts"

This command only changes the runtime setting. It does not test the app for you. Windows App Service and Functions apps are configured differently, and Microsoft's version-specific upgrade steps cover those cases.

  • Node.js 22 support on Azure App Service ends April 30, 2027, and Microsoft's required action is to upgrade to Node 24 LTS.
  • Apps are not shut down on that date, but they lose security patches and Microsoft runtime support.
  • Node 24 enters Maintenance LTS on October 20, 2026 and reaches end of life on April 30, 2028, so planning should cover the next upgrade too.
  • Node.js 22 is the last Node version available on the Azure Functions Linux Consumption plan, so those apps must move to Flex Consumption to get Node 24.
  • Retirement notices go to subscription owners by default, so app teams should set up Service Health Alerts.
  • If you need an exact Node patch version, Microsoft's route is a custom container, because App Service guarantees only the major version.

Node.js now reaches end of life every April, and Azure follows each date exactly, so this migration will come up again every year. The deadline that matters now is April 30, 2027. For most App Service teams, meeting it means a tested runtime change they can finish well before then. For Linux Consumption Functions users, it means moving to Flex Consumption, which is worth starting soon.