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.

Perhaps rewriting the application would take months, or you no longer have access to all the original source code. Even after migrating, you may be wondering how to bring AI capabilities to the business logic you already have.

In A Practical Path to Building AI-Ready Applications on Azure App Service, the team demonstrates how three Azure App Service capabilities can create a practical, incremental modernization path:

• Managed Instance on Azure App Service helps move Windows applications to a managed platform while preserving important operating system and application dependencies.
• GitHub Copilot app modernization can assess applications and accelerate modernization when source code is available.
• Built-in MCP on Azure App Service can expose existing APIs as Model Context Protocol (MCP) tools, making them available to agents without requiring you to build and host a separate MCP server.

The session also includes an end-to-end demonstration showing how these capabilities work together.

Instead of starting with a large, risky rewrite, you can lift, extend, and modernize: move the application first, take advantage of the managed Azure App Service platform, and then add modern and AI-powered experiences incrementally.

If you are facing a migration project that could take 6, 12, or even 18 months, watch the recording to see how this approach can help shorten and simplify the journey.

Watch the Session

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
• Managed Instance quickstart repository
• DevShop sample on GitHub
• Configure App Service built-in MCP
• Configure MCP server authorization
• GitHub Copilot App Modernization documentation
• Introduction to GitHub Copilot App Modernization
• Agentic IIS Migration to Managed Instance on Azure App Service
• IIS Migration MCP Server repository
• Managed Instance storage-mount CLI reference
• Managed Instance install-script CLI reference
• Managed Instance instance CLI reference

See startup health across every Linux app instance

The new az webapp troubleshoot status command, currently in preview, combines App Service runtime status with recent startup results from SCM (Kudu). By default, it returns structured data for every instance seen during the last 24 hours:

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

The result can include each instance’s current state and details, its latest startup error when one is available, and counts of recent successful and failed startup attempts. This gives you an app-wide overview before you inspect an individual startup log.

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

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

Use --instance with either an ARM instance ID or a machine name to inspect one worker. Add --slot <slot-name> to troubleshoot a deployment slot.

This command supports Linux web apps. If the startup-summary endpoint is not yet available for an app, the command reports that status instead of presenting missing startup data as zero attempts. Runtime status may still be available while the supporting App Service capability rolls out across regions.

Get the release

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

az upgrade
az version

This capability is now available directly in the Azure portal through Deployment Center.

To use it:

1. Open your Linux web app in the Azure portal.
2. Go to Deployment Center.
3. Select Manual Deployment (Push).
4. Choose Publish files (new) as the source.
5. Drag and drop your ZIP file or select Browse files.

You can now upload and deploy your application without navigating separately to the Kudu site. This is useful for getting started, testing an application, or performing an occasional manual deployment. For repeatable production deployments, we recommend configuring a CI/CD pipeline.

To learn more about the deployment experience, including package preview, build options, progress tracking, and deployment logs, see our previous post: A simpler way to deploy your code to Azure App Service for Linux.

This sample implements both horizons on Azure App Service with Microsoft Agent Framework, Azure Managed Redis, Azure Cosmos DB for NoSQL vector search, and Azure OpenAI. It is deployed and available as a complete reference implementation with a browser UI, deterministic local mode, tests, Bicep, and Azure Developer CLI support.

Sample: https://github.com/seligj95/app-service-agent-memory

Why one memory store is not enough

Conversation history and durable memory have different jobs.

Conversation history is ordered, session-specific, frequently updated, and naturally short-lived. The agent needs it to resolve statements such as “use the second option” or “what did I just say?”

Durable memory is selective, user-scoped, and useful across sessions. It holds facts such as a preferred deployment region, product name, accessibility need, or writing preference. Retrieval is semantic rather than chronological.

Putting both into one unbounded prompt makes cost, latency, privacy, and deletion harder to reason about. The sample instead gives each horizon a purpose-built store and joins them through the Agent Framework context pipeline.

The Azure architecture

The public FastAPI application runs on one always-on App Service Premium v4 instance with Python 3.13. The browser creates demo user and conversation IDs in local storage. That keeps the sample easy to explore, but it is not production authentication.

For every chat turn, the application:

1. Validates the user ID, session ID, message, and retrieval limit.
2. Loads bounded conversation history from Azure Managed Redis.
3. Creates an embedding for the new input.
4. Runs a partition-scoped vector query in Cosmos DB for the same user.
5. Adds relevant durable memories to the Agent Framework context.
6. Runs gpt-5-mini.
7. Stores the new conversation messages in Redis and refreshes their TTL.
8. Extracts conservative durable facts, embeds them, deduplicates them, and upserts them to Cosmos DB.

The chat response also returns memory attribution so the UI can show that a memory influenced the turn.

Short-term history with a custom HistoryProvider

Agent Framework’s current Python API makes history a context provider. The custom provider only implements the storage boundary; the framework handles when to load and persist messages.

class RedisHistoryProvider(HistoryProvider):
    def __init__(self, store, ttl_seconds, max_messages=40):
        super().__init__("redis-history")
        self._store = store
        self._ttl_seconds = ttl_seconds
        self._max_messages = max_messages

    async def get_messages(self, session_id, *, state=None, **kwargs):
        user_id = _required_state_value(state, "user_id")
        values = await self._store.load(user_id, session_id)
        return [Message.from_dict(json.loads(value)) for value in values[-self._max_messages:]]

    async def save_messages(self, session_id, messages, *, state=None, **kwargs):
        user_id = _required_state_value(state, "user_id")
        values = [json.dumps(message.to_dict()) for message in messages]
        await self._store.append(
            user_id, session_id, values, self._ttl_seconds, self._max_messages
        )

The Redis key is session:{user_id}:{session_id}. Each append also trims the list and refreshes the seven-day TTL. Serializing the complete Agent Framework Message preserves tool and attribution metadata instead of reducing history to plain strings.

Durable recall with a custom ContextProvider

The durable provider participates before and after the model call.

class CosmosContextProvider(ContextProvider):
    async def before_run(self, *, agent, session, context, state):
        user_id = _required_state_value(state, "user_id")
        embedding = await self._embeddings.embed(_latest_input_text(context))
        recalled = await self._store.recall(user_id, embedding, self._recall_limit)
        state["recalled_memories"] = [item.model_dump(mode="json") for item in recalled]

        if recalled:
            facts = "\n".join(f"- {item.text}" for item in recalled)
            context.extend_instructions(
                self.source_id,
                "Use these durable memories only when relevant:\n" + facts,
            )

    async def after_run(self, *, agent, session, context, state):
        for fact, category in extract_durable_facts(_latest_input_text(context)):
            embedding = await self._embeddings.embed(fact)
            await self._store.remember(
                state["user_id"], fact, category, state["source_turn"], embedding
            )

The Cosmos container uses /user_id as its partition key and a 1,536-dimension cosine quantizedFlat vector index. Recall is always routed to one user’s partition and is bounded to a small TOP N result set. A stable ID derived from the user scope and normalized content hash makes writes idempotent.

Passwordless by default

App Service uses its system-assigned managed identity for every data service.

• Azure OpenAI: Cognitive Services OpenAI User
• Cosmos DB: native built-in data contributor
• Key Vault: Key Vault Secrets User
• Azure Managed Redis: database-scoped Entra access-policy assignment

Azure OpenAI and Cosmos DB local authentication are disabled. Redis requires TLS and Entra authentication, and its access keys are disabled. The application explicitly selects ManagedIdentityCredential in Azure and AzureCliCredential for local real-service development. It does not use a broad production credential chain.

Key Vault remains the secrets boundary for future extensions, although this passwordless sample does not need a runtime secret.

Try it locally without Azure

The deterministic fake mode exercises the real provider pipeline and complete UI without an Azure subscription:

uv sync --python 3.13 --all-groups
uv run uvicorn app.main:app --reload

Open http://127.0.0.1:8000, tell the agent “My favorite launch color is teal,” start a new conversation, and ask for the color. You can inspect attribution, list the stored memory, and forget it.

Deploy with Azure Developer CLI

After creating an azd environment and setting its subscription and supported region, deployment is one command:

azd up --no-prompt

The Bicep creates App Service, Managed Redis, Cosmos DB, Azure OpenAI model deployments, Key Vault, Application Insights, and Log Analytics. A smoke test then checks health, same-session history, explicit remember, new-session recall, list, forget, and absence after forget.

Azure Managed Redis availability is subscription- and region-dependent. The deployed reference uses East US 2 after the service preflight rejected East US for this subscription.

What the demo deliberately does not hide

The browser identity is anonymous and user-controlled. That is useful for understanding the data flow, but a production application must replace it with authenticated claims and authorization on every memory operation.

The sample also keeps one App Service instance. Before scaling out, replace the in-process conversation lock with a distributed lock so concurrent requests cannot reorder one session’s history.

Other production work includes private endpoints and VNet integration, consent and retention policy, user export and deletion, content safety, prompt-injection defenses, abuse throttling, per-user quotas, and evaluation of retrieval thresholds.

Learn more

• Microsoft Agent Framework memory
• Agent Framework context providers
• Configure Python on Azure App Service
• Use Microsoft Entra ID with Azure Managed Redis
• Vector search in Azure Cosmos DB for NoSQL
• Use Azure OpenAI without keys

Two memory horizons make the agent easier to operate and easier to trust: session history remains temporary, durable memory remains selective and user-scoped, and both have explicit lifecycle controls.

To make this easier, we have added a new Log stream page in Kudu for Azure App Service on Linux, available under the Logs dropdown. This experience gives you a single place to stream, browse, search, and filter logs so you can understand what is happening in your app faster.

Opening the Logs page

You can open Kudu from the Azure portal:

1. Go to your App Service.
2. Select Advanced Tools.
3. Click Go.

You can also open Kudu directly by going to:

https://<app-name>.scm.azurewebsites.net

From there, open the Logs page.

View live logs across your app and platform

The Logs page lets you view logs as they are being written, with filters for timeframe, instance, container, log type, and level.

This helps when you want to focus on a specific instance, look only at errors, or separate application logs from platform events.

For example, you can use platform logs to understand container lifecycle events, restarts, startup behavior, warmup probe activity, and other platform-side events related to your app.

Quickly find the log entries that matter

You can use keyword search to narrow down the log stream or historical logs. This is useful when you are looking for a specific error message, request path, exception, dependency failure, timeout, or any application-specific keyword.

Instead of scanning through hundreds of entries, you can search for the terms that are relevant to the issue you are investigating.

Investigate issues within a specific timeframe

The Log stream page also supports viewing logs for a selected time range. This is useful when you know when an issue occurred and want to inspect both application and platform activity around that time.

For example, you can filter to a specific timeframe, switch to Application logs, and check what your app was doing when the issue happened.

This can help you troubleshoot scenarios such as failed requests, application exceptions, slow startup, container restarts, dependency issues, or configuration problems.

Summary

The new Log stream page in Kudu makes it easier to work with logs for Azure App Service on Linux. With live streaming, keyword search, historical views, and filters for application and platform logs, you can quickly narrow down the information you need and troubleshoot issues more efficiently.

We are continuing to improve the App Service Linux experience to make diagnostics simpler and more useful for day-to-day development and operations.

To make this easier, we have added new Azure CLI commands that let you list and view App Service startup logs directly from the command line.

List available startup logs

You can list startup logs for an app using:

az webapp log startup list \
  --name <app-name> \
  --resource-group <resource-group>

The output shows whether the startup attempt succeeded or failed, along with the instance name and log file size. This helps you quickly identify the right log file, especially when there are multiple startup attempts across different instances.

Show startup log content

To view the latest startup log, run:

az webapp log startup show \
  --name <app-name> \
  --resource-group <resource-group>

You can also view a specific log file by name:

az webapp log startup show \
  --name <app-name> \
  --resource-group <resource-group> \
  --log-file-name <log-file-name>

The log content includes startup events from the platform and the application. For example, you can see the container image being pulled, the startup script being generated, the app command being run, and the warmup probe result.

In a successful startup, the log shows that the site startup probe succeeded and the site started successfully.

Failure logs are prioritized by default

When you run az webapp log startup show without specifying a log file name, the command automatically prefers failure logs from the most recent date.

This helps reduce the time spent looking for the right log when debugging startup failures. Instead of manually searching through multiple files, you can run one command and immediately see the most relevant failure details.

For example, if the app fails because the worker process does not start within the allotted time, the log shows the timeout details and the platform actions taken during startup cancellation.

Better hints for common startup failures

The command also includes improved handling for common failure scenarios, including runtime startup failures and container startup timeouts.

For example, if the app starts but does not respond on the expected port, the startup log may show application output such as:

listening on 3000 (wrong port)

while the platform is expecting the app to respond on a different port. This makes it much easier to understand why the warmup probe failed.

Slot support

The startup log commands also support deployment slots.

To list startup logs for a slot:

az webapp log startup list \
  --name <app-name> \
  --resource-group <resource-group> \
  --slot <slot-name>

To show startup logs for a slot:

az webapp log startup show \
  --name <app-name> \
  --resource-group <resource-group> \
  --slot <slot-name>

This is useful when debugging slot-specific startup issues before swapping traffic to production.

Summary

The new az webapp log startup commands make it easier to inspect startup behavior for Azure App Service for Linux apps directly from Azure CLI.

These commands are currently in preview. Try them out the next time you need to understand why your App Service Linux app did or did not start successfully.

It’s a clear signal of our continued investment in App Service: the same managed platform you rely on, evolving to meet you where modern apps (and the agents that build and consume them) are headed. Read on for the highlights, with links to deeper dives on each announcement.

App Service Easy AI

We’re introducing Easy AI, a new umbrella of capabilities that make it simple to turn your existing App Service web apps into AI-ready, agent-native applications, with no rearchitecting required. The centerpiece of this first release is a brand-new AI (preview) blade in the Azure Portal, giving you a single place to enable AI capabilities directly on your web app.

The first feature available under Easy AI is Built-in MCP on App Service. With Built-in MCP, you can turn your web app into a Model Context Protocol server with no code changes. Just provide an OpenAPI specification, and App Service automatically generates the tools and a ready-to-use endpoint that AI agents can call. From the MCP servers tab in the AI (preview) blade, you can create and manage your MCP server in a few clicks, and optionally register it in your Azure API Center to catalog and govern it alongside the rest of your APIs and MCP servers. It’s the fastest way to give agents secure, structured access to the functionality your app already exposes.

The AI (preview) blade also includes a new Agents tab, giving you visibility into the AI agents hosted in your App Service. It surfaces key metrics (total agents, calls, tokens consumed, and error rate) drawn from your app’s telemetry in Application Insights, instrumented using OpenTelemetry with Generative AI semantic conventions. From here you can drill into the data in Application Insights to monitor agent behavior, performance, and cost over time.

This is just the beginning. Built-in MCP and the Agents experience are the first in a series of Easy AI features we’re rolling out to make adding AI to your App Service web apps simple and easy, so you can spend less time on plumbing and more time building intelligent, agent-ready applications. To get started, open the AI (preview) blade on your App Service web app today. Stay tuned, there’s much more to come.

Isolated V4

We’re also excited to announce the general availability of Isolated v4 (Iv4) on App Service Environment v3 (ASEv3). Iv4 brings the latest v4 hardware generation (the same next-generation compute that powers Premium v4) to customers running dedicated, single-tenant workloads on ASEv3, delivering significantly better performance than Isolated v2 without compromising the isolation, compliance, and data residency guarantees that mission-critical apps depend on. Iv4 is now generally available across a limited set of Azure regions, with additional regions rolling out over time based on customer demand and capacity. See the docs for the full list. To get started, create a new ASEv3 with an Iv4 plan or scale an existing one; see the App Service pricing page for full SKU and pricing details. Due to significant demand, available capacity may be limited even in supported regions at this time. If you encounter issues, please open a support ticket.

Additionally, Iv4 on ASEv3 also lays the foundation for App Service Managed Instance on dedicated infrastructure, unlocking advanced isolation scenarios for compliance and data-residency-sensitive workloads.

Managed Instance on Azure App Service

Managed Instance on App Service (Preview) continues to evolve with key improvements, including faster restarts (~30s), no restarts for registry and storage adapter changes, and integrated diagnostics tooling. The service is expanding to new regions (e.g., Central and South India) with broader rollout underway, alongside deeper integration with the GitHub Copilot App Mod tool, driving continued customer and partner engagement as we drive towards general availability.

Managed Instance on Azure App Service will soon be extended to App Service Environments (ASE) using the new Iv4 SKU, providing a more modern, scalable, and optimized foundation. This enables customers to simplify and accelerate deployment of Windows workloads, especially web applications requiring custom dependencies or deeper OS-level control, while benefiting from ASE’s single-tenant isolation, enhanced security and compliance boundaries, fine-grained network control, and predictable performance at scale. Overall, this offers a seamless path to modernize existing applications with minimal changes while aligning with Azure App Service capabilities and best practices.

Recent updates to the Azure App Service migration PowerShell scripts extend support for Managed Instance on App Service, enabling a more seamless lift & improve experience for applications with OS-level dependencies. By adding the -UseManagedInstance switch during invocation, customers can now automatically generate migration settings tailored for Managed Instance, including configuration for the App Service plan, adapters, and install scripts. This simplifies onboarding by capturing all required parameters in the result settings file, reducing manual setup for complex workloads that rely on registry, COM components, or custom dependencies.

Check out this Agentic IIS Migration to Managed Instance on Azure App Service, which showcases an AI-guided approach to migrating legacy IIS applications using a multi-agent workflow powered by MCP. It simplifies discovery, assessment, and deployment for complex Windows workloads with OS-level dependencies. This is an early pilot, and customers should adapt and extend the approach based on their specific application requirements and environments.

Platform Release Channel

Keeping runtimes evergreen is one of the core promises of a managed platform, but it cuts both ways: the same patch that fixes a CVE can occasionally surface a behavior change in a framework, an incompatibility with a third-party module, or break an assumption hardcoded somewhere in your app. Until now, the answer was “trust the rollout,” and for the apps that couldn’t, the fallback was to move to containers and take on managing the base image yourself.

Platform Release Channel for App Service on Linux changes that. It introduces a simple per-app setting that lets you choose how quickly a new runtime patch reaches your workload. Point your dev and test apps at Latest to pick up new patches as soon as they ship and validate early; leave production on the default Standard channel for the balance most apps want; or move sensitive workloads to Extended to stay one release behind and buy extra validation time. Same managed runtimes, same automatic patching, now with a control plane that fits how real teams ship.

Improvements to AZ CLI: Investing in the Azure CLI for the agent era

AI agents are increasingly using the Azure CLI as a primary entry point for managing Azure resources and orchestrating cloud workflows. To make sure agents (and the developers building them) get what they need, we’ve been investing heavily in the App Service CLI experience across both az webapp and az appservice. The goal: clearer signals, richer data, and more actionable output so both humans and agents can succeed on the first try.

The first few waves of those improvements has already shipped. Enriched deployment errors are a new opt-in switch (--enriched-errors true) on az webapp deploy for App Service on Linux that turn opaque deployment failures into structured, actionable diagnostics (including an error code, deployment context, the raw error, suggested fixes, and even a ready-to-paste GitHub Copilot prompt) directly in your CLI output. We’ve also revamped az webapp list-runtimes, replacing the old flat list with a structured table that includes OS, runtime, version, support lifecycle status, and end-of-life dates, plus new --runtime and --support filters so you (or your agent) can quickly answer questions like “which of my runtimes are nearing EOL?” or “what supported Python versions can I deploy on Linux today?”

Alongside these features, we’ve also burned through a significant chunk of our CLI backlog over the past few releases, so there are plenty of fixes and quality-of-life improvements waiting for you in the latest version. Make sure you, your scripts, and CI pipelines are on the latest CLI version to see all of these updates. This is just the start; more agent-focused CLI investments are on the way.

Platform Improvements

The same “make the platform easier to live with” thread runs through this other set of recently shipped features. None of them are headline features on their own, but together they take real friction out of the everyday App Service experience:

A faster Python deployment pipeline. We profiled the remote build path end-to-end and rebuilt the slow parts: Zstandard now replaces gzip for build artifacts (compression ~6x faster, decompression ~2.6x faster, which also speeds up cold starts), uv replaces pip as the primary installer when compatible (with automatic fallback to pip), and a redundant staging copy was removed entirely. Net result: roughly 30% faster Python deployments on App Service for Linux, with the biggest wins on AI/ML apps that pull in large dependency trees. See Platform Improvements for Python AI Apps on Azure App Service for the full breakdown.

FastAPI just works. Deploying a FastAPI app no longer requires a custom startup command. App Service now scans common entry-point files (main.py, app.py, api.py, etc.), detects the FastAPI import, and starts the app with the right Gunicorn/Uvicorn worker automatically. Enabled today for Python 3.14+, with more versions on the way. Details in Simplifying FastAPI Deployments on Azure App Service for Linux.

Deployments that survive a config change. With Deferred Kudu Recycle, updating a non-critical app setting or connection string while an async deployment is in flight no longer interrupts it. Kudu defers the recycle for up to 40 minutes so the in-progress deployment can finish, while deployment-critical settings (Kudu/Oryx/SCM prefixes, WEBSITE_RUN_FROM_PACKAGE, and friends) still recycle immediately. You can also mark your own settings as deployment-critical with WEBSITE_DEPLOYMENT_CRITICAL_APPSETTINGS.

Better SSH ergonomics for Python apps. A set of new SSH helper aliases for Python apps on Linux makes the in-container experience friendlier for diagnostics: shortcuts for activating the virtual environment, jumping to common app paths, and inspecting the running process, so you spend less time remembering paths and more time debugging.

Site Status: know what your app is actually doing. When a site won’t start or is behaving oddly, the new Site Status experience in the portal surfaces the platform-level lifecycle state (Starting / Started / Stopping / Stopped / Updating / Blocked) along with the last known error and per-instance detail. From the same view you can take repair actions like restarting the site or replacing the underlying instance, without leaving the blade.

More details

For deeper dives on each of the above, see:

• Performance and reliability improvements for Python deployment pipeline
  • Platform Improvements for Python AI Apps on Azure App Service - Azure App Service
• Simplifying FastAPI Deployments on Azure App Service for Linux
  • Simplifying FastAPI Deployments on Azure App Service for Linux - Azure App Service
• Deferred Kudu Recycle
  • Improving Deployment Resiliency on Azure App Service for Linux with Deferred Kudu Recycle - Azure App Service
• New SSH Helper aliases

  • [New SSH helper aliases for Python apps on Azure App Service for Linux

    Microsoft Community Hub](https://techcommunity.microsoft.com/blog/appsonazureblog/new-ssh-helper-aliases-for-python-apps-on-azure-app-service-for-linux/4520111)

• Site Status Indicator

  • [Understand What’s Happening with Your App Service for Linux Website Using Site Status

    Microsoft Community Hub](https://techcommunity.microsoft.com/blog/appsonazureblog/understand-what%E2%80%99s-happening-with-your-app-service-for-linux-website-using-site-s/4524676)

Wrapping up

Build 2026 is a big moment for App Service, but the through-line is the same one we’ve been pulling on all year: take a managed platform you already trust, and keep making it faster, more flexible, and easier to live with as the way you build apps changes. Easy AI brings agents into the picture without forcing a rewrite, Isolated v4 and Managed Instance push the boundaries of what fully-managed isolation can look like, and the platform and CLI work make the everyday parts of running an app on App Service a little less painful.

As always, we want to hear from you. Try out the new features, give us feedback, and let us know what you want to see next. We’re committed to making Azure App Service the best place to run your web apps in the agent era and beyond, and your input is critical to making that happen. Thanks for being part of the journey!