Announcing Azure Web PubSub chat in public preview
Chat is becoming a standard interaction model across customer support, collaboration, gaming, marketplaces, healthcare, financial services, and AI-powered applications. But building a production-ready chat system involves much more than opening a WebSocket connection. Teams also need to manage rooms and membership, deliver and order messages, retain conversation history, recover from connection interruptions, and enforce permissions. Today, we are excited to announce that Azure Web PubSub chat is available in public preview. Azure Web PubSub chat is a managed capability built on Azure Web PubSub. It provides chat-focused client and server APIs so developers can work directly with familiar concepts such as rooms, messages, members, users, and roles, while Azure manages the underlying real-time messaging infrastructure. Focus on the chat experience, not the messaging plumbing Azure Web PubSub already helps developers build large-scale, real-time applications. The new chat capability adds a higher-level abstraction for applications whose primary interaction model is conversation. Instead of defining custom events, message schemas, membership logic, persistence workflows, and reconnect behavior, developers can use built-in chat operations to: Create one-to-one or group rooms. Add and remove room members. Send ordered messages in real time. Retrieve persistent room message history. Apply built-in or custom roles and permissions. Reconnect clients and recover messages after temporary connection loss. These capabilities run on Azure Web PubSub infrastructure and inherit its automatic scaling, geo-replication, security, and compliance foundations. Chat-native APIs for clients and servers Azure Web PubSub chat provides two complementary ways to build. The JavaScript client SDK, available through the `@azure/web-pubsub-chat-client` npm package, connects applications to a chat hub. Clients can create rooms, exchange messages, load history, manage members, and subscribe to chat events. The Chat REST API supports trusted server-side and administrative workflows, including managing rooms, users, members, messages, roles, and permissions. This separation lets client applications deliver responsive real-time experiences while backend services retain control over identity, moderation, governance, and business rules. For example, after connecting a `ChatClient`, creating a room and sending a message takes only a few calls: const room = await client.createRoom("Project Falcon", ["bob", "carol"]); client.on("message", ({ message }) => { console.log(`${message.createdBy}: ${message.content.text}`); }); await client.sendToRoom(room.roomId, "Welcome to the project room!"); Applications can also read message history through an asynchronous iterator, making it straightforward to implement initial conversation loading or incremental history as a user scrolls. Keep chat data in your Azure Storage account Persistent chat data remains in an Azure Storage account selected by the application owner. Azure Web PubSub chat uses the Web PubSub resource's managed identity to access that storage, avoiding storage connection strings or keys in the chat configuration. The stored data includes: Messages and conversation history Rooms and room membership Users Roles and permissions Your data stays in your storage account, and the service keeps no separate copy. This model gives organizations direct ownership of their persisted chat data while the managed service handles real-time delivery and chat operations. Built-in access control with room-level flexibility Chat applications often need different privileges for participants, moderators, room owners, support agents, or automated services. Azure Web PubSub chat includes a role and permission model for these scenarios. Built-in room roles distinguish between members and operators. Both can send messages, read history, and invite members by default, while operators can also remove users. Developers can define custom user or room roles when an application needs a different permission set. Role administration is performed through the Chat REST API, keeping permission management in trusted server-side code. Reliable conversations across connections and devices Users expect chat to continue working when a laptop changes networks, a mobile connection briefly drops, or the same account is open in multiple browser tabs or devices. Azure Web PubSub chat runs on Azure Web PubSub's reliable WebSocket connection. The client reconnects and recovers automatically after an interruption, while the service fans messages out to a user's active connections. Persistent history also allows users to load earlier messages after reconnecting or joining a room later. Choose the right Web PubSub capability The new chat capability complements the existing standard Web PubSub hub. Use a chat hub when the application is centered on conversations and benefits from built-in rooms, membership, history, roles, and chat-focused APIs. Use a standard hub when the application needs full control over its protocol or supports a different real-time workload, such as telemetry, device signaling, multiplayer state, notifications, or live dashboards. Both options use Azure Web PubSub, allowing teams to select the abstraction that best fits each real-time scenario. Get started To try Azure Web PubSub chat: Create or open an Azure Web PubSub resource. Link an Azure Storage account under Persistent Storages. Add a Chat Hub and associate it with that storage. Generate a client access URL for testing. Install the JavaScript client SDK: npm install azure/web-pubsub-chat-client Connect a client, create a room, and send your first message. The portal-generated client URL is intended for experimentation. In production, issue client access URLs from an authenticated backend and derive the chat user ID from the signed-in application identity. Managed identity and Microsoft Entra ID can be used for keyless server authentication. Azure Web PubSub chat is available now in public preview. Start with the Azure Web PubSub chat overview, follow the quickstart, or explore the client SDK and REST API. We look forward to seeing the customer conversations, collaboration experiences, and AI-powered applications you build with it.Announcing General Availability of Managed Instance on Azure App Service
Today, we are thrilled to announce the General Availability (GA) of Managed Instance on Azure App Service. Following the tremendous response to our Public Preview announcement at Ignite 2025, we've spent the past nine months working closely with customers, partners, and the community to harden the platform, expand capabilities, and validate real-world enterprise migration scenarios. Managed Instance on Azure App Service is now ready for your production workloads, backed by a full enterprise SLA. The journey from Preview to GA Since November 2025, thousands of customers have used the public preview to move workloads that were previously "stuck" on-premises or on aging Windows Server VMs. The feedback has been unmistakable: Managed Instance on Azure App Service dramatically shortens the path to the cloud for legacy and complex .NET Framework applications often removing the need for code changes entirely. Enterprises across various sectors like financial services, healthcare, manufacturing, and the public sector migrated applications that depended on GAC assemblies, COM components, Windows Services, registry configuration, and mapped network drives apps that historically required expensive re-platforming or a full rewrite. With Managed Instance on Azure App Service, these workloads now run on a fully managed PaaS platform, side-by-side with modern cloud-native apps. What's new at GA Building on the preview foundation of configuration scripts, registry adapters, storage mounts, and RDP via Azure Bastion, GA brings several important additions: Production SLA (99.95%) – Full enterprise-grade availability commitment across all supported regions. Expanded regional availability – Available in at least 8 Azure regions worldwide at GA with continued expansion planned through the remainder of 2026. Deeper Premium v4 integration – Managed Instance now takes full advantage of the Premium v4 App Service Plan tier for enhanced performance, memory-optimized SKUs, and improved price-performance. Zone redundancy – Deploy Managed Instance workloads across Availability Zones for higher resiliency without additional configuration effort. Enhanced observability – First-class integration with Azure Monitor, Application Insights, and Log Analytics, including instance-level metrics for CPU, memory and disk. Improved configuration script experience – Faster startup times, richer diagnostics when scripts fail, versioning support for configuration bundles, and streamlined rollback. Managed Identity everywhere – All secrets, storage connections, and Key Vault references at GA use Managed Identity by default, eliminating stored credentials from your deployment pipelines. Azure Policy and Defender for Cloud coverage – Governance, compliance, and threat protection controls now apply to Managed Instance the same way they apply to standard App Service workloads. Bicep, Terraform, and ARM templates – Full IaC support with new resource providers and modules for repeatable, auditable deployments. GitHub Copilot Modernization - Deep Integration with GitHub Copilot modernization for Application assessment targeting Managed Instance on App Service https://learn.microsoft.com/en-us/dotnet/azure/migration/appmod/working-with-assessment Why customers are choosing Managed Instance on Azure App Service The core value proposition remains the same and it's stronger than ever at GA: 1. Lift-and-Improve legacy applications Migrate .NET Framework apps with hardcoded file paths, COM dependencies, GAC entries, or registry access with no major code rewrites. Install custom components directly on the managed instance using configuration scripts. 2. Re-platform hard-to-modernize apps Move applications with lost source code, legacy middleware (MSMQ, SMTP servers, third-party runtimes), or tight infrastructure coupling. Managed Instance removes the blockers that historically forced these apps to stay on VMs. 3. Hybrid and regulated workloads Integrate securely with on-premises resources using VNet integration and private endpoints. Enforce data residency, Bring Your Own Storage, and Managed Identity–backed access controls to meet finance, healthcare, and government compliance requirements. 4. Incremental modernization Start with "lift and Improve" then adopt PaaS features like DevOps automation, autoscaling, deployment slots, and centralized configuration at your own pace. Future-proof your portfolio without a big-bang transformation. What customers are saying During preview, we saw real numbers: Migration timelines cut from months to weeks for apps that would otherwise have required substantial refactoring. Zero code changes for a significant share of preview workloads that previously blocked App Service adoption. Reduced infrastructure footprint as customers consolidated Windows Server VMs onto managed App Service Plans with zone redundancy and autoscaling built in. We are grateful to every preview customer whose feedback shaped this release. Pricing and licensing Managed Instance on Azure App Service is billed as a capability on top of the Premium v4 App Service Plan. There is no separate Managed Instance surcharge at GA you pay for the underlying Premium v4 compute you consume. Existing App Service reservations, savings plans, and any other Azure Benefit all apply, helping you optimize the total cost of ownership as you migrate. Getting started Getting started is straightforward: Assess your workload using Azure Migrate's updated App Service assessment, which now flags candidates ideal for Managed Instance. Create a new Web App using the Managed Instance on Azure App Service option in the Azure Marketplace, or via Bicep, Terraform, or the Azure CLI. Package your dependencies into a configuration bundle (a zip file plus a PowerShell install script) and store it in Azure Storage. Grant access via Managed Identity. Configure registry values, storage mounts, and networking to match your on-premises environment. Deploy your application using the same App Service deployment mechanisms you already know—ZIP deploy, GitHub Actions, Azure DevOps, or Visual Studio publish. Operate with confidence use RDP over Azure Bastion for deep troubleshooting when you need it, and Azure Monitor for everything else. Resources 📘 Managed Instance on Azure App Service documentation 🎥 Technical Deep Dive session recording from Build 2026 🧭 GitHub Repo with sample configuration scripts, webapp and guidance for Managed Instance on App Service workloads Looking ahead GA is a milestone, not a finish line. On our roadmap we're already working on: Deeper integration with Azure Migrate's web app discovery and assessment capabilities to help identify web apps suitable for migration to Managed Instance on App Service Enhanced migration tooling with easier dependency detection and one-click configuration bundle generation. Expanded Rollout to Azure Regions across 2026 and beyond. Continuously Release new features and capabilities to make migrations easier and faster than ever before We can't wait to see what you build and what you migrate. Managed Instance on Azure App Service is here to make your modernization journey faster, simpler, and more secure than ever. Welcome to GA. 🚀 The Azure App Service Team
A simpler way to deploy ZIP packages to Azure App Service from the Azure portal
We recently introduced a simpler way to deploy applications to Azure App Service for Linux by uploading a ZIP package through Kudu. The experience lets you review the package contents, choose whether to run a server-side build, and follow the deployment through its different stages. This capability is now available directly in the Azure portal through Deployment Center. To use it: Open your Linux web app in the Azure portal. Go to Deployment Center. Select Manual Deployment (Push). Choose Publish files (new) as the source. 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 | Microsoft Community HubAnnouncing public preview: Markdown for Agents in Azure App Service
Why Markdown for Agents? Web pages often contain scripts, styles, and HTML markup that are useful to browsers but add noise when the content is sent to an AI model. Markdown for Agents removes that extra markup and returns a smaller, text-focused response that is easier for agents to process and can reduce token usage. In internal testing across more than 637,000 pages, converted Markdown responses were 97 percent smaller at the median than the source HTML, with a median conversion time of 2 milliseconds. Results vary based on the page and its content. Public preview availability Markdown for Agents is available in public preview for Windows apps on Azure App Service in all public regions. The app must use an App Service plan in the Basic tier or higher. No additional authentication setup is required for Markdown conversion. Your app's existing authentication, authorization, and network access controls continue to apply. This feature is only supported on Windows App Service at this time. Support for Linux apps will come later this year. Enable Markdown for Agents During the public preview, you can enable the feature through the REST API, ARM/Bicep template, or the Azure CLI using az rest . Dedicated Azure CLI commands and portal support are planned for a future update. Azure CLI with az rest Replace the placeholders with your subscription ID, resource group, and app name: az rest --method patch --url "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>?api-version=2026-03-15" --headers "Content-Type=application/json" --body '{"properties":{"aiIntegration":{"markdown":{"enabled":true}}}}' Verify the setting: az rest --method get --url "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>?api-version=2026-03-15" --query "properties.aiIntegration.markdown" To disable the feature, send the same PATCH request with enabled set to false . ARM template Add the following property to your Microsoft.Web/sites resource using API version 2026-03-15 : "properties": { "aiIntegration": { "markdown": { "enabled": true } } } Bicep resource webApp 'Microsoft.Web/sites@2026-03-15' = { name: appName location: location properties: { serverFarmId: appServicePlanResourceId aiIntegration: { markdown: { enabled: true } } } } Request a Markdown response After enabling the feature, request an HTML page from your app with the Accept: text/markdown header: curl -i -H "Accept: text/markdown" "https://<APP_NAME>.azurewebsites.net/" A successfully converted response includes these headers: Content-Type: text/markdown; charset=utf-8 x-markdown-source: easy-markdown The response body contains Markdown generated from the page's HTML. Common content such as headings, paragraphs, links, lists, images, emphasis, and code is preserved, while script and style content is removed. Pages that cannot be safely converted may return their original HTML. Clients should check the Content-Type and x-markdown-source response headers before processing the response as Markdown. What's next Linux support is planned before the feature reaches general availability. We also plan to add dedicated Azure CLI commands and a portal experience in future updates. Share your feedback Try Markdown for Agents with your Windows App Service apps and let us know how it works for your agent scenarios. Share feedback, questions, and feature requests in the comments below.
Azure App Service secure hostname
Hey Everyone, I see a new change in app service deployment related to the secure hostname. Is it now mandatory to have a secure hostname, because I don't see the option to toggle between the secure hostname and just the format for appservicename.azurewebsites.net ? I wasn't able to find any update notification to verify this change.
