If you’re going through the .NET in-process to isolated worker migration ahead of the November 10, 2026 end-of-support deadline, you’re probably auditing your function app settings as part of the work. That’s where WEBSITE_NODE_DEFAULT_VERSION tends to surface. Teams inherited it, copied it into Bicep templates, and left it alone assuming it was a platform requirement. It isn’t? at least not for .NET.
What the setting actually does
The official app settings reference on Microsoft Learn is direct about scope: “Windows only. Sets the version of Node.js to use when running your function app on Windows.” That is the full job description. Node.js, Windows. Nothing else.
I find it slightly confusing. When you provision a new Function App, Azure sometimes adds WEBSITE_NODE_DEFAULT_VERSION automatically regardless of the chosen runtime. It looks like a platform requirement. However, it isn’t!
What actually controls the .NET runtime version
For .NET function apps, the runtime is configured through three settings, none of which involve Node.js:
| Setting | Platform | Purpose |
|---|---|---|
| FUNCTIONS_WORKER_RUNTIME | All | Set to dotnet or dotnet-isolated |
| netFrameworkVersion | Windows | SiteConfig property, e.g. v8.0 |
| linuxFxVersion | Linux | e.g. dotnet-isolated|8.0 |
The Microsoft docs on upgrading language versions make the separation explicit. WEBSITE_NODE_DEFAULT_VERSION only appears under the Node/JavaScript section. The .NET upgrade path goes through netFrameworkVersion on Windows or linuxFxVersion on Linux. The two stacks don’t cross.
Using ~ to stay on the latest minor version
While reviewing app settings during a migration, you’ll also encounter FUNCTIONS_EXTENSION_VERSION. This controls which version of the Functions runtime host your app runs on. The app settings reference documents the tilde notation explicitly: a value of ~4 means the app runs on version 4.x and automatically picks up new minor versions as they become available.
The same tilde convention applies to WEBSITE_NODE_DEFAULT_VERSION for Node.js apps: setting ~18 tracks the latest Node 18 minor release without manual updates. But again, that is only relevant if your function app actually runs Node.js.
For .NET isolated worker apps on v4, the correct settings in your IaC are:
{
"FUNCTIONS_EXTENSION_VERSION": "~4",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
That’s it. No Node version setting needed.
Can you remove it from a .NET function app?
Yes. A Microsoft Q&A thread on exactly this question confirmed that the setting is only created by default when you provision a Node.js function app. If your function app has no Node.js code, the setting has no effect.
Max Ivanov’s 2021 deep-dive on Node.js versioning in Azure Functions backs this up: on Linux, WEBSITE_NODE_DEFAULT_VERSION has no effect at all regardless of runtime. For non-Node runtimes on any OS, the setting is irrelevant.
Conclusion: If you’re migrating to the isolated worker model and find this in your app settings or IaC, remove it. It’s configuration noise, and configuration noise has a habit of confusing the next person who reads it.