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 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 on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly, which aligns to the monthly Patch Tuesday schedule. These updates are applied automatically, in a way that guarantees the high-availability SLA of Azure services. Azure App Service OS patching follows Safe Deployment Practices and Availability-First approach. As such, while we strive to ensure the latest patches are applied as soon as possible, 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, the updates are handled on a case-by-case basis.
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
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 Cli.
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=~18 --resource-group <groupname> --name <appname>
az webapp config set --python-version 3.8 --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 18 runtime on Windows App Service.
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.chinacloudsites.cn/Env#sysinfo. |
| .NET version | At https://<appname>.scm.chinacloudsites.cn/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.chinacloudsites.cn/DebugConsole, run dotnet --version. |
| PHP version | At https://<appname>.scm.chinacloudsites.cn/DebugConsole, run php --version. |
| Default Node.js version | In the Azure Cli, 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.chinacloudsites.cn/DebugConsole, run python --version. |
| Java version | At https://<appname>.scm.chinacloudsites.cn/DebugConsole, run java -version. |
Note
Access to registry location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages, where information on "KB" patches is stored, is locked down.
Related content
Trust Center: Security