Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article explains how Azure App Service updates operating system (OS) and runtime software, how you can get version information, and how you can manually upgrade to new versions.
App Service is a Platform-as-a-Service (PaaS), so Azure manages the OS and application stack for you. You manage only your application and its data. If you need more control over the OS and application stack, you can use Azure Virtual Machines.
It's still helpful for you as an App Service user to know information such as:
- How and when OS updates are applied.
- How App Service is patched against significant and zero-day vulnerabilities.
- When supported language runtimes are updated, added, or deprecated.
- How to control runtime patch update timing with the Platform Release Channel (Linux).
- How to find out which OS and runtime versions are running your apps.
This article provides transparency on the process, and helps you stay updated on security-related announcements and runtime updates. For security reasons, certain specific security information isn't published.
How and when are OS updates applied?
Azure manages OS patching for both the physical servers and the guest virtual machines (VMs) that run App Service resources. Both machine layers are updated monthly, aligning to the monthly Patch Tuesday schedule.
These updates are applied automatically, while guaranteeing the high-availability service-level agreement (SLA) for Azure services. Azure App Service OS patching follows Safe Deployment Practices (SDP) and an availability-first approach. The latest patches are applied as soon as possible, but OS patching may be slowed or paused at times to avoid app impacts and outages.
For detailed information on how updates are applied, see Demystifying the magic behind App Service OS updates.
How does Azure deal with significant vulnerabilities?
When high-priority issues such as zero-day vulnerabilities require immediate patching, Azure handles the updates on a case-by-case basis. To stay current with critical Azure security announcements, see the Azure Security Blog.
When are supported language runtimes updated, added, or deprecated?
New stable major, minor, or patch versions of supported language runtimes are periodically added to App Service instances. Some updates overwrite the existing installation, while others are installed side-by-side with existing versions.
An overwrite installation means that your app automatically runs on the updated runtime. A side-by-side installation means you must manually migrate your app to take advantage of a new runtime version. For more information, see the following sections.
Note
This information applies to language runtimes that are built into an App Service app. A custom runtime you upload to App Service, for example, remains unchanged unless you manually upgrade it.
New patch updates
Patch updates to .NET, PHP, Java SDK, or Tomcat version are applied automatically by overwriting the existing installation with the latest version. Node.js patch updates are installed side-by-side with the existing versions, similar to major and minor versions. New Python patch versions can be installed manually through site extensions, side-by-side with the built-in Python installations.
New major and minor versions
New major or minor versions are installed side-by-side with the existing versions. You can manually upgrade your app to the new version.
If you configured the runtime version in a configuration file such as web.config or package.json, you need to upgrade by using the same method. If you used an App Service setting to configure your runtime version, you can change it in the Azure portal or by running an Azure CLI command in Azure Cloud Shell.
The following examples show Azure CLI configuration commands for various supported language runtimes. You replace <appname> and <groupname> with the names of your app and its resource group.
az webapp config set --net-framework-version v4.7 --resource-group <groupname> --name <appname>
az webapp config set --php-version 7.0 --resource-group <groupname> --name <appname>
az webapp config appsettings set --settings WEBSITE_NODE_DEFAULT_VERSION=~24 --resource-group <groupname> --name <appname>
az webapp config set --python-version 3.14 --resource-group <groupname> --name <appname>
az webapp config set --java-version 1.8 --java-container Tomcat --java-container-version 9.0 --resource-group <groupname> --name <appname>
Note
The Node.js example uses the recommended tilde syntax to target the latest available version of the Node.js 24 runtime on Windows App Service.
Control runtime patch update timing with Platform Release Channel
Note
The Platform Release Channel feature is available for Linux App Service only.
By default, the system automatically applies runtime patch updates when they become available. For Linux App Service, the Platform Release Channel setting lets you control the cadence at which runtime patch updates are delivered to your app. This control is useful when you want more predictability and time for validation before a new runtime patch is adopted in production.
Available channels
Choose from three channels:
| Channel | Description | Recommended for |
|---|---|---|
| Latest | Delivers runtime patch updates as soon as they're available. | Apps where immediate access to the newest security fixes is required. Not generally recommended for production workloads. |
| Standard | Updates arrive at the standard release cadence, balancing currency and stability. This channel is the default. | Most production apps. |
| Extended | Stays typically one release behind Standard, giving workloads more time for validation before adopting a new runtime patch. | Production workloads that require extra validation time before picking up a new runtime patch. |
When a new runtime patch is released, it flows through the channels in order: Latest → Standard → Extended. This flow means an update that's immediately available on Latest reaches Standard after further validation, and then Extended after additional validation on top of that.
For example, for .NET 10, the same point in time might look like:
| Channel | .NET version |
|---|---|
| Latest | 10.0.7 |
| Standard | 10.0.4 |
| Extended | 10.0.2 |
Tip
If your app has strict stability requirements, use the Extended channel to reduce the frequency of automatic runtime patch updates. If your app needs the latest security fixes as fast as possible, use Latest.
Configure the platform release channel
- In the Azure portal, go to your App Service app.
- In the left menu, select Stack settings.
- Under Platform Release Channel, select the channel you want: Latest, Standard, or Extended.
- Select Save.
For more information about this feature, see the Platform Release Channel blog announcement.
How can I query OS and runtime update status on my instances?
The Kudu console lets you query the OS version and runtime versions of your App Service instances. Critical OS information is locked down from access. For more information, see Operating system functionality on Azure App Service.
The following table shows how to use Kudu or Cloud Shell commands to find the Windows and language runtime versions that are running your apps. Replace <appname> and <groupname> with your app and resource group names.
| Information | Where to find it |
|---|---|
| Windows version | See https://<appname>.scm.azurewebsites.net/Env#sysinfo. |
| .NET version | At https://<appname>.scm.azurewebsites.net/DebugConsole, run the following command at the command prompt: reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full". |
| .NET Core version | At https://<appname>.scm.azurewebsites.net/DebugConsole, run dotnet --version. |
| PHP version | At https://<appname>.scm.azurewebsites.net/DebugConsole, run php --version. |
| Default Node.js version | In the Cloud Shell, run the following command: az webapp config appsettings list --resource-group <groupname> --name <appname> --query "[?name=='WEBSITE_NODE_DEFAULT_VERSION']". |
| Python version | At https://<appname>.scm.azurewebsites.net/DebugConsole, run python --version. |
| Java version | At https://<appname>.scm.azurewebsites.net/DebugConsole, run java -version. |
Note
Access to registry location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages, where information on Security Bulletins is stored, is locked down.