az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack

Describe the bug

az webapp create --runtime resolves the selected runtime but does not apply the stack-specific site configuration supplied by the App Service stacks API in siteConfigPropertiesDictionary.

The current observable failure is Windows Node 24. Its stack metadata includes:

{
  "siteConfigPropertiesDictionary": {
    "use32BitWorkerProcess": false
  }
}

Node 24 is 64-bit only, but an app created with --runtime "NODE:24LTS" has use32BitWorkerProcess: true. A Node 24 probe then fails with HTTP 500. Changing only this property to false allows the same probe to run successfully as Node 24 x64.

This should not be fixed with a Node 24-specific or Windows-only condition. The stacks API is the source of truth for runtime-specific site configuration on both Windows and Linux. Upcoming runtimes, including .NET 11 on Windows, will also require use32BitWorkerProcess: false, while Linux stacks may use the dictionary for other platform-appropriate settings. Every consumer of the stacks API should honor these properties generically so that adding or changing a stack does not require another Azure CLI release or runtime-specific branch.

Related command

az webapp create

Related inspection and workaround commands:

az webapp list-runtimes
az webapp config show
az webapp config set --use-32bit-worker-process false

Errors

The create command succeeds, but the resulting app is configured incorrectly:

{
  "nodeVersion": "",
  "use32BitWorkerProcess": true,
  "windowsFxVersion": null
}

After deploying a no-dependency Node probe:

GET https://<app-name>.azurewebsites.net/
HTTP 500
<empty response body>

The identical probe on an otherwise identical app where only use32BitWorkerProcess is set to false returns:

{
  "nodeVersion": "v24.18.0",
  "architecture": "x64",
  "platform": "win32"
}

Issue script & Debug output

The following reproduces the configuration defect on a currently selected subscription. App names must be globally unique.

$location = "eastus2"
$resourceGroup = "node24-cli-repro"
$planName = "node24-cli-repro-plan"
$appName = "node24-cli-repro-<unique-suffix>"

az group create `
  --name $resourceGroup `
  --location $location

az appservice plan create `
  --resource-group $resourceGroup `
  --name $planName `
  --location $location `
  --sku P0v3 `
  --is-linux false

az webapp list-runtimes `
  --os-type windows `
  --query "[?config=='NODE|24LTS']"

az webapp create `
  --resource-group $resourceGroup `
  --plan $planName `
  --name $appName `
  --runtime "NODE:24LTS" `
  --debug

az webapp config show `
  --resource-group $resourceGroup `
  --name $appName `
  --query "{nodeVersion:nodeVersion, windowsFxVersion:windowsFxVersion, use32BitWorkerProcess:use32BitWorkerProcess}"

Runtime discovery correctly returns Node 24:

[
  {
    "config": "NODE|24LTS",
    "os": "Windows",
    "runtime": "Node",
    "version": "24.0 LTS"
  }
]

Relevant sanitized --debug output:

Will set appsetting {'name': 'WEBSITE_NODE_DEFAULT_VERSION', 'value': '~24'}

PUT .../providers/Microsoft.Web/sites/<app-name>?api-version=2025-05-01
Request body:
{
  "properties": {
    "siteConfig": {
      "appSettings": [
        {
          "name": "WEBSITE_NODE_DEFAULT_VERSION",
          "value": "~24"
        }
      ],
      "alwaysOn": true
    },
    "serverFarmId": "<redacted>"
  }
}

PUT .../providers/Microsoft.Web/sites/<app-name>/config/metadata?api-version=2025-05-01
Request body:
{
  "properties": {
    "CURRENT_STACK": "node"
  }
}

Neither request applies use32BitWorkerProcess: false. The resulting value is true:

{
  "nodeVersion": "",
  "use32BitWorkerProcess": true,
  "windowsFxVersion": null
}

The workaround is:

az webapp config set `
  --resource-group $resourceGroup `
  --name $appName `
  --use-32bit-worker-process false

Expected behavior

When --runtime selects a Windows or Linux stack whose stacks API entry contains siteConfigPropertiesDictionary, az webapp create should merge those properties into the siteConfig sent to ARM.

For Windows Node 24, the initial create payload should therefore include:

{
  "properties": {
    "siteConfig": {
      "use32BitWorkerProcess": false
    }
  }
}

The implementation should be generalized:

Resolve the selected runtime's OS-specific stacks API entry.
Apply the valid siteConfigPropertiesDictionary entries to the create payload using the SiteConfig schema.
Do not hard-code an operating system, runtime name, or version such as Windows, NODE|24LTS, or .NET 11.
Preserve current defaults when the dictionary or a property is absent.
Give an explicit caller-supplied value precedence if az webapp create supports an override for the same property.

Regression coverage should verify that:

Windows Node 24 is created with use32BitWorkerProcess == false and can run an x64 probe.
Another stack carrying the same metadata receives the same setting without a runtime-specific code path. This should cover the upcoming .NET 11 requirement when that stack is available.
A Linux stack or test fixture carrying site configuration metadata receives its declared properties through the same generalized path.
A stack without this metadata retains its existing behavior.
Additional valid SiteConfig properties supplied by stack metadata use the same generalized path.

Environment Summary

azure-cli                         2.88.0
azure-cli-core                    2.88.0
azure-cli-telemetry               1.1.0

Python (Windows)                  3.14.5
OS                                Windows 11

The issue was reproduced on a Windows P0v3 App Service plan in East US 2. The plan reported kind: app and reserved: false.

Additional context

The CLI correctly maps NODE|24LTS to WEBSITE_NODE_DEFAULT_VERSION=~24 and writes CURRENT_STACK=node; the missing behavior is propagation of the selected stack's site configuration metadata.

The observed side-by-side test used the same plan and identical deployment package:

Creation/configuration	`use32BitWorkerProcess`	Result
`az webapp create --runtime "NODE:24LTS"` with no post-create change	`true`	HTTP 500
Same create command, followed only by `az webapp config set --use-32bit-worker-process false`	`false`	HTTP 200, Node `v24.18.0`, `x64`, `win32`

The generalized, OS-independent stacks metadata behavior is the requested fix. A Node 24-only or Windows-only workaround in az webapp create would leave the same defect for .NET 11, Linux stacks, and other future runtime requirements.

Thank you for opening this issue, we will look into it.

Routed to Azure/azure-cli-extensions as #10175 (Azure/azure-cli-extensions#10175) because this targets the webapp extension, whose source lives in Azure/azure-cli-extensions.

Posted by agent-assist (autonomous bug-fix pipeline).

Following the routed issue and draft PR, the current blocker is repository ownership rather than diagnosis:

[webapp] az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack azure-cli-extensions#10175 contains the reproduced root cause and proposed regression coverage.
Route webapp create stack configuration fix to Azure CLI core azure-cli-extensions#10176 confirmed that the webapp extension only contributes webapp scan; az webapp create is implemented in the Azure CLI core App Service module.
The draft PR therefore changes no files, and I could not find a corresponding implementation PR in this repository.

Could this issue be assigned to the Azure CLI core App Service owner and the fix implemented here? The expected behavior is to apply the selected stack's siteConfigPropertiesDictionary generically to the create payload, while preserving explicit caller overrides. For Node 24 on Windows, this must set use32BitWorkerProcess=false; otherwise the CLI creates an incompatible app that returns HTTP 500.

The existing workaround remains:

az webapp config set --use-32bit-worker-process false

Yong Zhang (@yonzhan)

Yong Zhang (@yonzhan) Aditya Pujara (@a0x1ab) — could we please assign this to the Azure CLI core App Service owner and target it for the 2.91.0 milestone?

This is currently breaking Windows Node.js 24 customers: az webapp create --runtime "NODE:24LTS" succeeds but creates a 32-bit app for a 64-bit-only runtime, causing the deployed application to return HTTP 500. Setting use32BitWorkerProcess=false is the confirmed workaround.

The automated workflow routed this to azure-cli-extensions, but Azure/azure-cli-extensions#10176 confirmed that az webapp create is implemented here in CLI core. There is still no core implementation PR.

The requested fix is to apply the selected stack’s siteConfigPropertiesDictionary generically during creation—not a Node.js-specific workaround—so future runtimes such as .NET 11 also receive their required configuration.

Ethan Yang (@necusjz) DanielMicrosoft Arya Sadeghi (@aryasadeghi) — flagging for 2.91.0 planning ahead of the September 29 code-complete date.

CC: Gillian Laming (@glaming1) Jordan Selig (@seligj95)

aamos-company

aamos-company — tagging you for visibility because this is breaking Windows Node.js 24 today and overlaps with your recent App Service CLI Node runtime work. There is currently no core implementation PR, and we are trying to target the fix for Azure CLI 2.91.0.

aamos-company

@copilot please implement this fix in the Azure CLI core App Service module and open a PR targeting dev for the Azure CLI 2.91.0 milestone.

Requirements:

Apply the selected stack's siteConfigPropertiesDictionary generically to the siteConfig used by az webapp create; do not hard-code Node.js 24, Windows, or a specific property.
Preserve existing behavior when the dictionary or property is absent.
Ensure an explicit caller-supplied value takes precedence over stack metadata.
Add regression coverage for Windows Node.js 24 setting use32BitWorkerProcess=false, another valid generic site-config property, and a stack without metadata.
Run the targeted App Service tests and required checks, and report any remaining blockers.
In the generated PR, tag aamos-company, Gillian Laming (@glaming1), Jordan Selig (@seligj95), and Byron Tardif (@btardif) for visibility and review.

The previous automated routing to azure-cli-extensions was incorrect; az webapp create is implemented in this repository.

Navigation Menu

Repository navigation

az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack #33835

Describe the bug

Related command

Errors

Issue script & Debug output

Expected behavior

Environment Summary

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack #33835

Description

Describe the bug

Related command

Errors

Issue script & Debug output

Expected behavior

Environment Summary

Additional context

Activity

yonzhan commented on Aug 3, 2026

x-engineering-agent commented on Aug 3, 2026

btardif commented on Aug 19, 2026

btardif commented on Aug 26, 2026

btardif commented on Aug 28, 2026

btardif commented on Aug 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions