The Grafana dashboard experience for Azure App Service brings platform metrics and links to App Service diagnostics into a single starting point in the Azure portal. It gives you another way to explore your application’s health and take the next step when something needs attention.

Start with the application you already manage

Open your App Service web app in the Azure portal and select Monitoring > Dashboards with Grafana (Preview) from the navigation menu. In the gallery, open Azure | Insights | Web Apps - Platform Metrics.

The dashboard brings together platform metrics for your app, helping you review its behavior without first assembling a dashboard from scratch. Whether you’re checking on an application after a deployment or investigating a reported issue, you can start with a shared view of its health.

In this Linux demo, we generated healthy baseline traffic, followed by controlled slow responses and simulated HTTP 500 errors. The 15-minute view shows HTTP status codes and average and maximum server response times across the test. The empty Health Check panel reflects that App Service Health Check wasn’t configured for this demo; an application health endpoint alone doesn’t enable that feature.

Move from observation to investigation

Imagine a customer reports that your application feels slower than usual. Your first task is to understand whether the application’s metrics show a corresponding change.

Start with the dashboard to explore the affected period. When you identify something worth investigating, follow the diagnostic links to explore further using App Service’s diagnostic tools.

The dashboard includes operating-system-specific diagnostic links, helping you find relevant investigation paths for your application’s environment. The goal is straightforward: make it easier to move from “something looks different” to “here’s where I should look next.”

In our Linux example, the link beside Server Response Time (sec) is labeled Deep dive: app slowness detector. It opens Availability and Performance > Web App Slow, where you can explore the diagnostic results.

Check the time range again in the diagnostic view so it covers the period you’re investigating.

The dashboard is a starting point, not a replacement for application logs, tracing, or deeper troubleshooting. Use it alongside your existing monitoring tools to build a fuller picture. For more about the investigation tools, see the App Service diagnostics overview.

Work within your existing access permissions

The dashboard in the Azure portal queries data using your signed-in identity. Your existing Azure resource permissions govern access; the dashboard does not grant additional access to the underlying resources.

That distinction matters when teams collaborate on troubleshooting: each person needs the appropriate permissions to view the relevant data. Sharing a view of the dashboard does not bypass those permissions.

This follows the Azure Monitor dashboards with Grafana model, which uses the current user’s identity for data-source authentication. It is distinct from Azure Managed Grafana, a separate service with additional configuration options.

Try it with your next application health check

To get started:

1. Open your App Service web app in the Azure portal.
2. Select Monitoring > Dashboards with Grafana (Preview) and open the Web Apps platform metrics dashboard.
3. Explore the platform metrics and use the diagnostic links when you need more context.

You don’t need to wait for an incident. Start with a healthy application to become familiar with its normal behavior, then use that context when you investigate a change.

Resources

• Visualize Azure Monitor data with Grafana
• Monitor Azure App Service
• App Service diagnostics overview

We expect most PHP apps to continue working without any changes, particularly those using the default Nginx configuration. However, if you’ve customized your Nginx configuration or startup command, we recommend validating your app against the updated images.

What should you check?

If your app uses a custom Nginx configuration, review the following potentially affected customizations:

• Loading optional Nginx modules using load_module
• Using module directives such as echo, geoip2, image_filter, or XSLT
• Hardcoded Nginx paths, such as /var/lib/nginx/
• Custom startup commands that replace or start Nginx

These are examples, not an exhaustive list. Having a customized configuration does not necessarily mean your app will be affected.

How to prepare

The updated PHP images are already available on the Latest channel, so you can test compatibility ahead of the rollout to Standard.

We recommend using an App Service deployment slot to validate your app without affecting production. Configure the staging slot to use the Latest channel, test your application and Nginx customizations, and keep your production slot on Standard.

We plan to begin a gradual rollout of the updated images to the Standard (default) channel starting October 14, 2026 (UTC), with rollout across all Azure regions expected to take several days.

If you encounter any issues, you can temporarily switch to the Extended channel to return to an earlier image while you investigate and update your configuration.

Once your app is compatible, we recommend using Standard (or Latest, if appropriate) to continue receiving platform and security updates.

For instructions on viewing or changing your channel, see Control runtime patch updates with Platform Release Channel.

The session covered:

• Choosing when to adopt runtime patches with Platform Release Channel.
• Simplifying deployment with Quick Deploy, plus previews of code rollback and Secure Builds.
• Connecting to custom containers without an SSH server and collecting Node.js CPU, memory, and network diagnostics.

Watch the Session

Watch on YouTube

Validate runtime patches before production adopts them

Runtime patches bring security fixes and platform improvements, but applications may need validation before moving to a newer patch. Platform Release Channel gives Linux apps a choice of update cadence:

Tulika demonstrated three copies of a .NET application, one on each channel. Inspecting their runtime versions in SCM (Kudu) showed different patch levels, making the progression from Latest to Standard to Extended concrete. Those versions were a snapshot of the rollout, not permanently pinned versions or a fixed update schedule.

The team highlighted a practical testing pattern: keep production on Standard and configure a deployment slot on Latest to test upcoming patches. Channel selection can differ by slot. During the demonstration, Tulika also explained that changing the channel recycles the app to use the corresponding runtime image.

You can configure the channel in the Azure portal’s Stack settings or through Azure CLI. For example, explicitly select the default channel:

az webapp update \
  --resource-group <resource-group> \
  --name <web-app> \
  --platform-release-channel Standard

Channels control when patches arrive; they are not a way to avoid runtime updates indefinitely. Plan validation around the rollout rather than assuming a particular patch will remain on a channel.

Deploy with more confidence

Test changes and roll back quickly

Quick Deploy brings ZIP upload directly into the Azure portal’s Deployment Center. You can inspect the package and choose whether to run a server-side build before deploying. It is useful for getting started and testing; repeatable production deployments should still use a CI/CD pipeline.

In the session, Tulika uploaded a ZIP package that replaced a working page with a broken version. She then opened the preview Rollbacks experience in SCM (Kudu), selected a retained previous deployment, and restored the working page without uploading the old package again.

The demo showed the current deployment and two previous versions. The presenters explained that retention depends on available filesystem space. Treat this as a preview of the demonstrated recovery workflow, not a guarantee that every deployment or app has a recoverable version. Keep versioned release artifacts and use deployment slots as part of your production release process.

Spot vulnerable components with Secure Builds

The team previewed Secure Builds, showing a deployment-specific report that matched components against GitHub security advisories. Opening a finding led to the corresponding advisory, giving the developer a starting point for remediation. In the demonstrated experience, findings were reported without blocking the deployment.

Rollback and Secure Builds were described as previews during the recording. Their current regional, plan, runtime, and deployment-method coverage has not been independently confirmed in published documentation, so this recap describes what was shown rather than announcing broad availability.

Troubleshoot Linux apps without rebuilding the container

Open a terminal without adding an SSH server

Custom Linux containers traditionally needed their own SSH server configuration for the legacy WebSSH experience. Tulika demonstrated a container without that setup: the old connection failed, but az webapp exec successfully opened a shell in the running app container.

The command, available in preview starting with Azure CLI 2.90.0, uses the local terminal consistently on Windows, macOS, and Linux. Use an up-to-date Azure CLI and select a shell that exists in your image:

az webapp exec \
  --resource-group <resource-group> \
  --name <web-app> \
  --shell /bin/sh

The session also showed Try the new terminal in SCM (Kudu) connecting to the same container. This platform path removes the need to install an SSH daemon or embed an SSH credential in the image. Availability can vary while the platform rollout completes.

Beyond interactive shells, az webapp exec supports detached execution. The presenters discussed running a one-off database migration from an app instance that already has the required network access. An accepted response confirms only that the request was accepted, not that the command completed successfully; detached execution does not return the command’s output or exit code.

Shell access is a privileged operational capability. Apps that do not need it can disable access through the sshEnabled configuration property.

Move from CPU and memory symptoms to useful evidence

For Node.js apps on Linux, the team demonstrated CPU and memory diagnostics in SCM (Kudu) > Diagnostic Tools. You can collect an artifact for local analysis or choose Collect & analyze to generate a built-in report.

The memory report highlighted large strings, closures, and arrays that could help narrow down a suspected leak. The CPU demonstration contrasted a capture taken while the app was idle with one that identified elevated CPU activity and event loop blocking. These reports provide investigation leads, not an automatic fix.

A memory dump captures a point in time; a CPU profile observes activity over a selected interval. Collect evidence while the problem is occurring. Dumps consume storage, and collection and analysis can affect the instance serving your app. The presenters recommended short captures and, where appropriate, reproducing the issue on a deployment slot with a controlled portion of traffic.

During the recording, this diagnostic experience was described as a preview rolling out with Node.js support first. Do not assume the same CPU and memory tooling is available for every Linux runtime.

Separate backend connectivity failures from application errors

The Network Capture demonstration investigated an app returning errors while trying to reach a backend. The generated report showed failed TCP handshakes and retransmissions, directing attention toward the connection path rather than only the frontend web server.

Network Capture is in preview for App Service for Linux and supports collection with optional built-in analysis in SCM (Kudu). Published documentation also describes Azure CLI support through az webapp troubleshoot collect network-capture for Linux web apps on dedicated App Service plans, even though the session discussed additional CLI diagnostics as upcoming.

Captures target a selected app instance, stop at 100 MB, and have a maximum duration of 300 seconds. HTTPS traffic remains encrypted. Packet captures can contain sensitive application data, so handle them accordingly. Choose Collect only and download the .pcap for local investigation when you want to avoid running the analysis on the app instance.

Resources

• Control runtime patch updates with Platform Release Channel
• Deploy ZIP packages from the Azure portal
• Azure CLI 2.90.0: container access and Linux troubleshooting
• Diagnose CPU and memory issues in Node.js apps on Linux
• Capture and analyze network traces on Linux
• Azure CLI network capture reference

Diagnose Linux app configuration from the terminal

The new az webapp troubleshoot config command, currently in preview, evaluates common Linux App Service settings and pairs the results with a recent runtime error when one is available:

az webapp troubleshoot config \
  --resource-group <resource-group> \
  --name <web-app>

The command checks settings such as the runtime stack, port binding, startup command, Always On, and health check path. It combines configuration checks from SCM (Kudu) with App Service runtime status, returning structured output by default so you can use standard Azure CLI output formats.

For a human-readable, color-coded view, add --report:

az webapp troubleshoot config \
  --resource-group <resource-group> \
  --name <web-app> \
  --report

Runtime errors are included only when they occurred within the last 15 minutes, which avoids presenting stale failures as current problems. For a 24-hour view of runtime status and startup attempts, continue to use az webapp troubleshoot status.

Use --instance <worker-machine-name> to run the checks for a specific worker. The command matches the runtime error to that worker and does not fall back to an error from another instance. Add --slot <slot-name> to diagnose a deployment slot.

This preview supports Linux web apps. If the configuration-check endpoint is unavailable, the command reports that condition and can still return a recent runtime error when App Service provides one.

Update access restrictions without changing unrelated settings

Commands under az webapp config access-restriction now send only the access-restriction properties being changed instead of resubmitting the complete site configuration. This prevents add, remove, and set operations from unintentionally dropping unrelated settings while updating rules for the app or its SCM (Kudu) site.

For example, you can add an allow rule without risking changes to other site configuration:

az webapp config access-restriction add \
  --resource-group <resource-group> \
  --name <web-app> \
  --rule-name <rule-name> \
  --action Allow \
  --ip-address <ip-address-or-cidr> \
  --priority <priority>

Existing command syntax and access-restriction behavior remain unchanged. For more examples, see Set up Azure App Service access restrictions.

Get the release

Run az upgrade to install the latest available Azure CLI release, then verify the installed version:

az upgrade
az version

What’s New?

• Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.

• Stalled controller start up due to slow role discovery has been resolved.

• Database performance improved with reductions of locking and unnecessary saves.

• Updates to the following application frameworks and tools:

• .NET Framework 3.5 and 4.8.1
• ASP.NET Core
  • 10.0.11
  • 10.0.8
  • 8.0.30
  • 8.0.303
  • 8.0.424
• Microsoft OpenJDK 11
  • 11.0.30.7.
• Microsoft OpenJDK 17
  • 17.0.18
• Microsoft OpenJDK 21
  • 21.0.10
• Microsoft OpenJDK 25
  • 25.0.2
• Node.js
  • 22.23.1
• Npm
  • 8.1.0
  • 10.9.8
  • 11.16.0
• Tomcat
  • 9.0.109
  • 9.0.113
  • 9.0.115
  • 9.0.116
  • 10.1.146
  • 10.1.50
  • 10.1.53
  • 11.0.11
  • 11.0.15
  • 11.0.20

• Updated Kudu to 2026.08.1.2

• Continual accessibility and usability updates

All other fixes and updates are detailed in the App Service on Azure Stack Hub 26R1 Release Notes The App Service on Azure Stack Hub 26R1 build number is 102.20.2.2 and requires Azure Stack Hub to be updated with 2311 or later prior to deployment/upgrade.

You can download the new installer and offline package:

• Installer
• Offline package

Please read the updated documentation prior to getting started with deployment:

• Update the App Service Resource Provider for updating existing deployments

You can now collect and analyze memory dumps and CPU profiles for Node.js applications running on Azure App Service for Linux.

The experience is available in Kudu for App Service on Linux and supports both collection and built-in analysis, so you can investigate CPU and memory issues without having to download the dump or profile and analyze it separately.

Memory profiling: understand what is using your heap

A memory dump gives you a point-in-time snapshot of the Node.js process memory.

Select the App Service instance and Node.js process you want to investigate, then choose Collect & analyze to capture the dump and generate an analysis report.

A few things to keep in mind:

• The memory dump is collected from the selected App Service instance.
• A memory dump captures the full process memory for point-in-time analysis.
• Dump size is proportional to process memory. Larger processes take longer to capture and consume more storage.
• Your app is not restarted, but collection can briefly affect responsiveness.
• A memory dump represents a specific moment in time rather than memory behavior over a period.

If you are investigating a suspected memory leak, it is best to capture the dump while memory usage is elevated. Comparing captures taken before and after memory growth can also help identify objects that are accumulating.

Built-in memory analysis

Once the capture is complete, App Service can analyze the dump and generate a report with a high-level view of the heap and the areas that may need further investigation.

The report includes information such as:

• total heap usage and object count
• memory used by application objects versus the V8 engine
• heap composition by object type
• large strings and other unusually large objects
• high closure counts
• object types with unusually high instance counts
• potential memory leak patterns
• application objects consuming the most memory

The report also surfaces key findings and recommendations to help narrow down the problem.

For example, unusually large strings may point to large JSON payloads, logging buffers, cached responses, or string accumulation. A high number of closures may indicate event listeners or callbacks that are not being cleaned up.

The analysis can also identify object types with unusually high instance counts, which may help highlight potential unbounded growth.

Instead of starting with thousands of objects in a raw heap dump, you can start with the areas that are most likely to need attention.

CPU profiling: find the code consuming CPU

CPU profiling works differently because CPU behavior needs to be observed over a period of time.

The profiler samples the application’s call stack at regular intervals to identify hot paths and determine where the application is spending its CPU time.

Select the Node.js process and profile duration, then start profiling. You can choose a predefined duration such as 15, 30, or 60 seconds, or specify a custom duration.

A few things to keep in mind:

• The CPU profile is collected from the selected App Service instance.
• CPU profiling samples the call stack at regular intervals to identify hot paths.
• The profile runs for the specified duration.
• Longer profiles generally capture more representative data.
• Profiling has minimal performance impact on the application.

For best results, capture the profile while the slowdown or high CPU usage is actually occurring.

From CPU usage to the function responsible

After profiling completes, the analysis report shows where CPU time was spent during the profiling period.

For Node.js applications, the report can surface:

• active CPU during the profile
• CPU time spent in application code
• Node.js runtime overhead
• garbage collection overhead
• hot functions consuming the most CPU
• source locations for identified functions
• event loop health
• long-running synchronous operations
• potential event loop blocking
• recommendations based on the findings

This can help move the investigation from a general symptom such as high CPU to the specific function or execution path responsible.

For example, if one application function accounts for most of the sampled CPU time, the report can identify the function and its source location so you can investigate it directly.

The profiler can also highlight Node.js-specific issues such as event loop blocking. Long-running synchronous operations can prevent the event loop from processing other requests, resulting in slow response times even when the underlying cause is not obvious from CPU metrics alone.

Collect and analyze - or just collect

Both CPU and memory profiling support two modes.

Collect & analyze captures the memory dump or CPU profile and generates an App Service analysis report.

Collect only captures the diagnostic artifact without running the built-in analysis, allowing you to download it and use your preferred profiling or debugging tools if needed.

This gives you a quick way to investigate common issues while still keeping access to the underlying diagnostic data for deeper analysis.

Getting started

To try CPU or memory profiling:

1. Open Kudu for your App Service Linux app.
2. Under Diagnostic Tools, select Memory or CPU.
3. Select the App Service instance you want to investigate.
4. Select the Node.js process.
5. For memory, capture the dump while memory usage is elevated.
6. For CPU, select a profiling duration and capture while the CPU issue or slowdown is occurring.
7. Select Collect & analyze to generate the built-in analysis report.

CPU and memory problems can have many causes, but the first step is usually getting visibility into what the application was doing when the problem occurred.

With CPU and memory profiling for Node.js applications in Kudu, App Service for Linux can now help you move from a high-level performance symptom to the code, objects, or runtime behavior that may be causing it.

We’re making that workflow much easier with a new Network Capture experience, now available in preview.

You can collect network traces directly from Kudu or the Azure CLI. And instead of stopping at packet capture, you can optionally have the trace automatically analyzed to generate a report that highlights potential problems and summarizes what happened during the capture.

Capture a network trace from Kudu

In Kudu, go to Diagnostic Tools > Network Capture.

Select the App Service instance where you want to collect the trace, and configure the capture. You can select the network interface and capture duration, with preset options for 30, 60, and 120 seconds or a custom duration.

Note: Before starting a network capture, make sure the app container is up and running.

For more targeted troubleshooting, advanced settings let you configure options such as:

• Snap length
• Capture IP address
• BPF filter, for example tcp port 443

You can then choose between two modes:

Collect & analyze captures the network trace and automatically generates an analysis report.

Collect only captures the trace without running the built-in analysis, so you can download the .pcap file and inspect it using a tool such as Wireshark.

You can also use Analyze existing .pcap if you already have a packet capture that you want to inspect using the built-in analyzer.

A few things to keep in mind when collecting a trace:

• Network traces are collected on the selected App Service instance serving your app.
• If your app communicates with remote endpoints over TLS or SSL, including HTTPS, the traffic in the trace will be encrypted.
• A network trace can capture up to 100 MB of data. The capture stops automatically when this limit is reached.
• Only the five most recent captures are retained.

After collection, your captures appear in Capture history, where you can view the generated report, download the .pcap file, or delete the capture.

Capture network traces from the Azure CLI

You can also collect network traces without opening Kudu by using the Azure CLI.

For example, to collect a packet capture without running automatic analysis:

az webapp troubleshoot collect network-capture \
    -g <resource-group> \
    -n <capture-name> \
    --instance $instance \
    --duration 10 \
    --collect-only

To collect the trace and run the built-in analysis:

az webapp troubleshoot collect network-capture \
    -g <resource-group> \
    -n <capture-name> \
    --duration 10

This makes it easier to use network capture as part of your normal command-line troubleshooting workflow, without first connecting to the container over SSH.

Make sure you’re using the latest version of the Azure CLI.

Install the latest Azure CLI

Go from packet capture to useful insights

Capturing the packets is often only the first part of troubleshooting. The harder part is figuring out which packets matter and what they tell you about the problem.

When you choose to collect and analyze a trace, Network Capture does some of that work for you. It processes the trace and generates a report that summarizes the traffic and highlights findings that may warrant further investigation.

For example, the report can identify:

• HTTP 5xx responses
• Connections that did not complete the TCP handshake
• TCP resets
• Retransmissions
• HTTP 4xx and 5xx request rates
• Slow HTTP requests

The report also provides context for some findings. For example, connections that remain in SynSent and never receive a SYN-ACK can point to connectivity, firewall, or SNAT-related problems.

Instead of starting with hundreds or thousands of individual packets, you get a quick view of where to begin your investigation.

Understand what happened during the capture

The report also provides visualizations that help you understand network behavior across the capture window.

Requests over time

See HTTP requests over time, grouped by response status class.

This makes it easier to identify periods where 4xx or 5xx responses occurred and correlate them with other network activity.

Response latency

View average and 95th-percentile request-to-response latency over time.

This can help highlight latency spikes and narrow down the part of the capture that needs further investigation.

Throughput

See inbound and outbound traffic during the capture window.

This provides a quick view of traffic patterns and periods of higher or lower network activity.

Errors over time

TCP resets, retransmissions, and HTTP 5xx responses are shown on the same timeline, making it easier to see when different network symptoms occur together.

Capture limits

Network captures are intentionally bounded so they can be collected safely from a running app.

A snap length of 0 captures the entire packet, which is needed when you want the analyzer to fully decode unencrypted HTTP traffic. Positive snap-length values are constrained to the supported range.

The requested capture duration is capped at 300 seconds, and collection also stops automatically if the trace reaches the 100 MB size limit first.

Try Network Capture

The Network Capture experience is currently in preview for Azure App Service for Linux.

If you’re troubleshooting connectivity failures, HTTP errors, latency, retransmissions, or other network-related issues, you can now collect the trace directly from Kudu or the Azure CLI.

And when you want a quicker starting point than examining the raw .pcap, use the built-in analysis to surface potential problems, latency patterns, throughput, errors, and other useful signals from the trace.

Give it a try and let us know what you think. We’d especially like feedback on the automated analysis: which findings are useful today, and what other network problems would you like the report to help identify?

The next generation of application runtimes is arriving on Azure App Service.

.NET 11, Python 3.15, and Node.js 26 are now available in preview on App Service on Linux, giving you an early opportunity to test application compatibility and experiment with new runtime and language capabilities.

Here are a few things you can try.

A new Ubuntu 26.04 foundation

All three runtime images are based on Ubuntu 26.04 (Resolute Raccoon). They also use a leaner package baseline to reduce image size, package maintenance, and security exposure.

If your application or startup scripts depend on operating-system tools or packages supplied by an earlier runtime image, test those dependencies before upgrading. Install application-specific dependencies as part of your deployment, or use a custom container when additional system packages are required.

Ubuntu 26.04 also uses the Rust-based uutils implementation for common commands such as ls, cp, and cat. These commands are largely GNU-compatible, but scripts that rely on GNU-specific options or output should be tested.

.NET 11

.NET 11 brings updates across the runtime, ASP.NET Core, libraries, and C# 15.

Try C# 15 language features Experiment with new capabilities such as union types and closed hierarchies, which can make it easier to model API results, application states, and other scenarios with a defined set of possible outcomes.

Test the latest web and runtime improvements Try your ASP.NET Core applications with the latest runtime and framework improvements, and identify package or framework compatibility issues ahead of upgrading production applications.

A leaner runtime image The .NET 11 image removes runtime-unnecessary operating-system packages, including development headers and disk, volume, and kernel-management libraries. Common App Service troubleshooting tools such as curl, wget, tcpdump, tcpping, dig, and nslookup remain available.

Explore what’s new in .NET 11

Python 3.15

Python 3.15 introduces new capabilities around startup performance, profiling, and developer productivity.

Experiment with lazy imports Python 3.15 adds explicit lazy imports, allowing modules to be loaded only when they’re needed. Applications with larger dependency trees can experiment with this to reduce work during startup.

Explore new profiling capabilities Try the new profiling tools in Python 3.15, including Tachyon, to investigate CPU usage and application performance with real web workloads.

Review system and development dependencies The Python 3.15 image no longer includes the C/C++ compiler toolchain, SWIG, SQL Server ODBC driver and command-line tools, or preinstalled profiling packages such as VizTracer. Applications with source-only Python packages should use prebuilt wheels or a custom container. Applications connecting to Azure SQL or SQL Server through pyodbc must install the Microsoft ODBC driver as part of their deployment.

The image continues to include common application servers and frameworks such as Gunicorn, Uvicorn, and Flask.

Explore what’s new in Python 3.15

Node.js 26

Node.js 26 brings the latest V8 runtime and JavaScript platform capabilities to App Service.

Try the Temporal API Temporal provides a modern approach to working with dates, times, time zones, and durations—and is enabled by default in Node.js 26.

Explore the latest JavaScript and HTTP improvements Node.js 26 includes V8 14.6 and Undici 8, along with new JavaScript APIs. Try your existing application to validate package compatibility and explore the latest runtime capabilities.

Review globally available tools The Node.js 26 image no longer includes a system Python interpreter, Corepack, or the globally installed Application Insights npm package. Applications that require Corepack—for example, to use pnpm or Yarn Berry—should install it explicitly. Applications using the Application Insights SDK should declare it in their own package.json. Yarn Classic remains available.

Explore what’s new in Node.js 26

Get started

You can create an App Service app using these runtime versions through the Azure portal, Azure CLI, or an ARM/Bicep template.

Node.js 26 LinuxFxVersion standardization

Starting with Node.js 26, App Service uses the standardized LinuxFxVersion value NODE|26.

When you create or configure an app through the Azure portal, the portal automatically selects this standardized value. When using Azure CLI, specify Node.js 26 as the runtime:

az webapp create \
  --resource-group <resource-group-name> \
  --plan <app-service-plan-name> \
  --name <app-name> \
  --runtime "NODE:26"

For Bicep-based deployments, set linuxFxVersion explicitly to NODE|26:

resource webApp 'Microsoft.Web/sites@2024-11-01' = {
  name: appName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: 'NODE|26'
    }
  }
}

.NET 11 and Python 3.15

There is no change to the runtime naming or deployment experience for .NET 11 and Python 3.15. You can create apps using these stacks through the Azure portal, Azure CLI, or ARM/Bicep templates as usual.

Because support is currently in preview, we recommend using these versions for development, experimentation, and compatibility testing.

Give them a try and let us know what you think.

The session covered:

• The general availability of Managed Instance on Azure App Service, a hosting option for Windows applications with operating system and infrastructure dependencies.
• The public preview of Markdown for Agents, which can convert an app’s HTML responses into cleaner, more token-efficient Markdown when a client requests it.
• New Azure CLI 2.90.0 capabilities, including az webapp exec for interactive shell access and detached command execution on Linux web apps.

Watch the Session

Watch on YouTube

Move legacy Windows applications directly to PaaS

Managed Instance on Azure App Service is designed for applications that cannot easily move to the standard App Service sandbox. These applications may depend on registry access, COM components, GAC assemblies, Windows services, MSI installers, custom fonts, mapped drives, network shares, or specific Windows features and runtimes.

Instead of moving these workloads to virtual machines or delaying migration for a complete rewrite, Managed Instance supports a lift-and-improve approach. You can preserve required dependencies while gaining App Service capabilities such as managed patching, scaling, deployment slots, authentication, managed identity, custom domains, and CI/CD.

During the demonstration, Andrew compared the same ASP.NET Web Forms application on standard App Service and Managed Instance. The application depended on:

• A database connection value stored in the Windows registry.
• GDI-based chart generation.
• A third-party component for PDF export.

The standard App Service sandbox blocked those operations. On Managed Instance, the application could run the existing functionality while also using managed identity to connect to Azure SQL.

Managed Instance provides plan-level configuration for these scenarios:

• Configuration scripts install Windows features, services, components, fonts, custom runtimes, and other dependencies when an instance starts.
• Registry adapters securely provide registry values backed by Azure Key Vault.
• Storage mounts support Azure Files, custom UNC paths, drive-letter mappings, and temporary local storage.
• Azure Bastion access provides just-in-time RDP for diagnostics when the plan is integrated with a virtual network.

Changes made interactively through RDP apply only to the current instance. Any configuration that must survive restarts, scaling, or platform maintenance should be captured in the installation script so App Service can reapply it consistently.

Managed Instance is generally available for Windows web apps in select regions on Premium v4 and Premium Memory-Optimized v4 plans.

Make existing websites easier for agents to consume

Web pages contain scripts, styles, navigation, and other HTML that browsers need but AI agents often do not. Sending all of that markup to a model increases response size and token usage before the agent can reach the useful content.

Markdown for Agents, now in public preview, lets App Service convert supported HTML responses into Markdown at the platform layer. After the feature is enabled, an agent requests Markdown through standard HTTP content negotiation:

curl -i \
  -H "Accept: text/markdown" \
  "https://<APP_NAME>.azurewebsites.net/"

A converted response uses Content-Type: text/markdown; charset=utf-8 and includes the x-markdown-source: easy-markdown response header. Normal browser requests continue to receive the application’s original response, and the app’s existing authentication, authorization, and network access controls still apply.

The standup demo used a Contoso Outdoors site and reduced the response size by 81 percent without changing the application. Broader internal testing across more than 637,000 pages produced Markdown responses that were 97 percent smaller at the median, with a median conversion time of 2 milliseconds. Results vary by page and content.

During the public preview, Markdown for Agents is available for Windows apps in all Azure public regions on Basic or higher App Service plans. It can be enabled through az rest, ARM, or Bicep. The team also previewed an upcoming Azure portal experience that brings Markdown for Agents and built-in MCP together under a new AI configuration area. Linux support, dedicated Azure CLI commands, and the portal experience are planned for future updates.

Modernize in practical steps

Together, Managed Instance and Markdown for Agents demonstrate an incremental path for existing applications:

1. Move a Windows application and its dependencies to a managed App Service environment.
2. Adopt platform capabilities such as managed identity, Key Vault, deployment slots, and autoscale.
3. Make existing web content easier for agents to retrieve by enabling Markdown responses.
4. Expose existing APIs as agent tools with App Service built-in MCP when the application has an OpenAPI specification.

This approach lets teams modernize infrastructure and add AI-ready experiences without waiting for a full application rewrite.

Also highlighted: Azure CLI 2.90.0

The team also called out the Azure CLI 2.90.0 release. The new az webapp exec command provides a consistent way to open an interactive shell or start a detached command in a running Linux web app. A related platform improvement, rolling out separately, allows for BYO container scenarios to no longer require their own SSH server.

Resources

• Announcing General Availability of Managed Instance on Azure App Service
• Managed Instance on App Service overview
• Deploy Managed Instance on Azure App Service
• Configure Managed Instance on Azure App Service
• Managed Instance on Azure App Service GitHub repository
• Announcing public preview: Markdown for Agents in Azure App Service
• Configure App Service built-in MCP
• What’s new for Azure App Service in Azure CLI 2.90.0
• A Practical Path to Building AI-Ready Applications on Azure App Service

Connect directly to Linux web app containers

The existing az webapp ssh experience was designed primarily for interactive, human-operated sessions and could behave differently across client operating systems. On Windows, for example, it could open a browser-based WebSSH session instead of using the local terminal. This made cross-platform documentation, automation, and operational tooling difficult to standardize.

The new az webapp exec command, currently in preview, provides a consistent CLI surface for interactive shell access and detached command execution against running Linux web apps.

Open an interactive shell in the main app:

az webapp exec \
  --resource-group <resource-group> \
  --name <web-app>

Shell mode uses the local terminal on Windows, macOS, and Linux. By default, it connects to one app instance using /bin/bash. Use --instance to select a specific instance or --shell to use another shell, such as /bin/sh.

You can also connect to SCM (aka Kudu):

az webapp exec \
  --resource-group <resource-group> \
  --name <web-app> \
  --target kudu

Execute mode starts a command without opening an interactive session. This is useful for triggering setup tasks, migrations, diagnostics, and long-running work from automation or agent-driven workflows. You can target one instance, a comma-separated list of instances, or every instance. Requests for multiple instances run in parallel.

For example, run a shell command on every instance and redirect its output to a file:

az webapp exec \
  --resource-group <resource-group> \
  --name <web-app> \
  --mode execute \
  --instance all \
  --shell-command "echo hello > /home/LogFiles/output.txt 2>&1"

Execute mode is fire-and-forget. An accepted result confirms that the platform accepted the request, not that the command completed successfully. The command runs detached, and the CLI does not return its standard output, standard error, or exit code. Use --command to invoke a program directly, --shell-command when you need shell operators such as |, &&, or >, and --working-directory to choose an absolute working directory.

The command also supports deployment slots. This first preview focuses on interactive shell access and detached command execution; file transfer and port forwarding are not included.

A safer path for custom Linux containers

The legacy WebSSH model for custom Linux containers can require adding an OpenSSH server to the container image, embedding a root password, and listening on port 2222. Security-conscious teams may be unable to use that model because it conflicts with policies that prohibit plaintext secrets, SSH daemons, or multiple processes in production images. Reusing the same image outside App Service can also expose those image changes in environments that do not have App Service protections in front of the SSH port.

A related App Service platform improvement, planned to roll out separately later in September, uses Kudu as an authenticated proxy to attach directly to the running container. Once available for an app, this path removes the need to modify the image, embed an SSH credential, or run an SSH daemon. Availability may vary by App Service region while the platform rollout completes.

Control SSH access

Treat container shell access as a privileged operations capability and disable it on apps that do not need it. The sshEnabled property controls access at the app level. For example, disable SSH with:

az webapp config set \
  --resource-group <resource-group> \
  --name <web-app> \
  --generic-configurations '{"sshEnabled": false}'

Set sshEnabled to true to enable access again. Add --slot <slot-name> to configure a deployment slot.

For governance across many apps, assign the built-in App Service apps should disable SSH and App Service app slots should disable SSH policies at the subscription or management-group scope. Assigning them at the tenant root management group applies the control across the tenant. Both policies default to Audit and can use Deny to prevent noncompliant app configurations. For policy IDs and assignment links, see the Azure App Service built-in policy reference.

Collect network captures from Linux web apps

A new preview troubleshooting command can collect a bounded packet capture from a Linux App Service worker:

az webapp troubleshoot collect network-capture \
  --resource-group <resource-group> \
  --name <web-app> \
  --duration 30

The command uses Kudu to finalize and analyze the capture, then returns authenticated links to the packet capture and analysis report. Use --collect-only when you only need the raw capture.

Give deployments a friendly name

az webapp deploy now supports --tag, allowing Linux web app deployments to carry a recognizable name:

az webapp deploy \
  --resource-group <resource-group> \
  --name <web-app> \
  --src-path app.zip \
  --tag september-production-release

This makes individual deployments easier to identify in deployment history and operational workflows.

Get more useful web app creation errors

For Linux web apps, az webapp create adds the opt-in --enriched-errors parameter. When enabled, the CLI returns more detailed diagnostic information when creation fails:

az webapp create \
  --resource-group <resource-group> \
  --plan <app-service-plan> \
  --name <web-app> \
  --runtime "PYTHON:3.13" \
  --enriched-errors true

This can help identify invalid runtime, container, and site configuration values without requiring additional troubleshooting steps.

Create Isolated v4 App Service plans

Azure CLI now recognizes the Isolated v4 SKUs for App Service Environment plans:

• I1V4 through I6V4
• I1MV4 through I5MV4

For example:

az appservice plan create \
  --resource-group <resource-group> \
  --name <app-service-plan> \
  --app-service-environment <ase-resource-id> \
  --sku I1V4

These SKUs are mapped to the IsolatedV4 ARM tier. An App Service Environment is required, and zone-redundant plans are supported.

App Service configuration and plan fixes

This release also addresses two important usability issues:

• az webapp config set --generic-configurations now preserves camelCase properties such as webJobsEnabled, whether supplied as key=value input or JSON.
• Windows examples for az appservice plan create now include --is-linux false. Because the command defaults to Linux when the option is omitted, this avoids accidentally creating a Linux plan when following a Windows example.

Get the release

Upgrade to Azure CLI 2.90.0 or later, then verify the installed version:

az version

Summary

Azure CLI 2.90.0 gives App Service users better container access, stronger troubleshooting tools, support for the latest isolated compute tier, and more predictable configuration behavior.