Host Remote MCP Servers in Azure App Service
My colleague, Anthony Chu, from Azure Container Apps, recently published an excellent blog post outlining how to get started with MCP servers in Azure Container Apps. I highly recommend reading it, as there are many similarities between hosting MCP servers on Azure Container Apps and Azure App Service. He also provides great background information on remote MCP servers and their future plans. In this article, I will build on that foundation and show you how to run remote MCP servers as web apps in Azure App Service, and how to connect to them with GitHub Copilot in Visual Studio Code. Quick Background on MCP Servers MCP (Model Context Protocol) servers are part of a rapidly evolving technology used for hosting and managing model-based contexts. These servers interact with clients like GitHub Copilot in VS Code, offering advanced features and enriching the functionality of large language models (LLMs). While most MCP servers are run locally, remote MCP servers are gaining traction. This is where cloud services like Azure App Service, Azure Functions, and Azure Container Apps come into play, providing developers with scalability and flexibility. Building a Remote MCP Server on Azure App Service We’ve released an official Azure Sample for hosting a remote MCP server on Azure App Service: remote-mcp-webapp-dotnet. Follow the README file for step-by-step instructions on deploying the server locally and then to Azure App Service. The sample also guides users on connecting to the MCP server from VS Code. Additional language-specific samples will be released in the coming weeks. For more information on using MCP servers in VS Code, check out the VS Code docs. This sample includes pre-built tools, such as the weather MCP server from Anthropic’s official quickstart, which has been adapted for deployment on Azure App Service with support for an /sse endpoint. Additionally, the sample features an azd template, enabling the entire solution to be deployed to Azure App Service with just a few CLI commands. We encourage you to expand upon this sample by adding more tools and customization.
App Service Linux container amid conversations.
What's communicating with what? What are the various IP addresses involved when App Service Linux container talks to a remote resource (e.g., Databases)? From the remote end of the connection, would I see a private IP or Public IP as the Linux Container source address?Introducing the 'Session Affinity Proxy' setting in App Service Configuration.
From our own metadata and experience at Microsoft, we know that a considerable number of our customers use App Service behind one of our reverse proxy solutions, such as Azure Application Gateway or Azure Front Door. In simple terms, this means that when our customers have an App Service, it often runs as part of the backend pool of an Azure Application Gateway or is configured as the origin in an Azure Front Door profile, which is great because this setup is beneficial for several reasons. Firstly, it enhances security by obfuscation. With a reverse proxy in the data path, clients only contact the reverse proxy instances and are unaware of the second connection between the reverse proxy instances and the real backend. This unrevealed internal architecture reduces the attack surface for malicious actors. Secondly, the reverse proxy can act as the TLS termination point, offloading the TLS handshake, encryption, and decryption from the App Service. This reduces the TLS computational load on the App Service and simplifies the management of TLS certificates, through Key Vault. Thirdly, the reverse proxy can load balance and distribute incoming client requests across multiple backend servers or origins, improving performance and ensuring no single server is overwhelmed, making scalability attainable. Finally, if Azure Front Door is used as the reverse proxy solution, it can also act as a cache, reducing the load on backend servers by serving content directly from the reverse proxy POPs (Point of Presence) servers, which improves response times for users, as the content is served directly from a location closer to the user, which is faster than contacting the origin. As we can see, using a reverse proxy like Azure Application Gateway or Front Door before an App Service, seems very convenient, but there is a drawback: maintaining session affinity and authentication can be challenging if custom domains are not being used in the App Service configuration. This is because in a reverse proxy scenario, instead of one connection we have two: one between the client and the reverse proxy, and another one between the reverse proxy and the backend / origin and maintaining the original information across those different connections is a challenge. What is the problem that we are trying to resolve with the new "Session Affinity Proxy" setting? When employing a reverse proxy to front App Services, clients typically utilize a custom domain that directs to the proxy´s IP address, while communication between the proxy and the backend App Services occurs via the default App Services domain name. Although this configuration is generally effective, it may present challenges when employing advanced configurations such as Session Affinity or Authentication within App Services (explained further in this article). To address these issues and ensure that an App Services deployment is reverse-proxy aware -utilizing the same domain name requested by the client to the proxy- a new configuration was recently introduced, beggining with Session Affinity cookies. First, let´s clarify what "Cookie-Based Affinity" Means. A "Cookie Based Affinity," also known as a "sticky session" or "session persistence," is a technique used to ensure that a client's requests are always sent to the same server. This is particularly important in scalable environments where web servers instances are added dynamically and hosted applications store user data in session variables or in a local cache, commonly referred to as a stateful application. Therefore, maintaining the "Session Affinity" is crucial for stateful applications that can use cookies to store important session information. If we send the request to a server without the stored sessions variables, the application logic can break, session state can get lost, authentication can fail, or back-end URLs can inadvertently be exposed to end users. Why maintaining "Session Persistence" challenging in scenarios with an App Service behind a reverse proxy without custom domains? Let´s use below diagram as an example for further explanation. In this diagram, we need to consider that Session Affinity (ARR) in App Services is enabled When the clients send the request to Application Gateway or Front Door (1), they send it with a host value in the request header equal to "constoso.com", that is different from the hostname configured in the backend "contoso.azurewebsites.net" (2). The HTTP Response from the backend (3) includes affinity cookies with a default domain name of "contoso.azurewebsites.net" (ARR enabled in the configuration of App Service) that differs from the original one "contoso.com". Due to security reasons, clients do not accept a cookie with the default domain name "contoso.azurewebsites.net" in the response (4) because its domain differs from the original, and therefore the "sticky session" is not maintained and the stateful application is broken. The new "Session Affinity Proxy" setting to the rescue For solving the problem that we have described above, we are introducing the "Session Affinity Proxy" setting in the App Service configuration. This is the portal view of the new setting: And you can also enable it via az cli: az resource update –name <app-name> --resource-type "Microsoft.Web/sites" -g <resource-group-name> --set properties.clientAffinityProxyEnabled=true This new property is available for the following services Web App Functions /Logic Apps (Standard) The new App Services property "clientAffinityProxyEnabled" that you set when you choose from the Portal "Session affinity proxy: On", in the configuration of a Web App, Function, or Logic App (or when you activate it via CLI) is a boolean setting that provides an out-of-the-box experience by setting cookie domain name based on incoming requests as seen by Application Gateway/Front Door. The following illustration demonstrates how this new solution works: As you can see when we enable the setting, we are sending the original domain (as seeing by the client) from the reverse proxy to the backend. As we know the original value, we are capable when we sent the HTTP Response from the backend to includes affinity cookies that contain the original hostname (contoso.com) rather than the configured one (contoso.azurewebsites.net) and therefore these cookies are not going to be rejected by the clients as they contain the expected hostname. This is a straightforward configuration that resolves the problem of "Cookie Based Affinity" and allows to work without custom domains configured on the App Service. Before this setting was introduced, our recommended solution was to use always custom domains as per this documentation, but with the new configuration setting "Session Affinity Proxy: On", we have a solution that just work with one click and reduces the complexity of configuration for our customers. This simplifies the process significantly and provides a seamless experience for users, eliminating the need for additional setup while ensuring consistent session affinity.Strapi on App Service: FAQ
This comprehensive guide is designed to answer all your questions about hosting and deploying Strapi on Azure App Service. Whether you're looking to understand the best platforms for Strapi integration, how to run Strapi in different modes, or how to deploy Strapi on various hosting services, this FAQ has you covered.Strapi on App Service: Quick start
In this quick start guide, you will learn how to create and deploy your first Strapi site on Azure App Service Linux, using Azure Database for MySQL or PostgreSQL, along with other necessary Azure resources. This guide utilizes an ARM template to install the required resources for hosting your Strapi application.Strapi on App Service: Overview
Looking to self-host Strapi? Deploy Strapi on Azure App Service to gain greater customization control, global region availability, and seamless integration with other Azure services. Hosting Strapi on Azure App Service simplifies infrastructure management while ensuring high availability, security, and performance. Whether you're searching for Strapi hosting, Strapi deployment, or where to host Strapi, Azure App Service provides the ideal solution for deploying Strapi efficiently and securely.Get Ready for .NET Conf: Focus on Modernization
We’re excited to announce the topics and speakers for .NET Conf: Focus on Modernization, our latest virtual event on April 22-23, 2025! This event features live sessions from .NET and cloud computing experts, providing attendees with the latest insights into modernizing .NET applications, including technical upgrades, cloud migration, and tooling advancements. To get ready, visit the .NET Conf: Focus on Modernization home page and click Add to Calendar so you can save the date on your calendar. From this page, on the day of the event you’ll be able to join a live stream on YouTube and Twitch. We will also make the source code for the demos available on GitHub and the on-demand replays will be available on our YouTube channel. Learn more: https://focus.dotnetconf.net/ Why attend? In the fast-changing technological environment we now find ourselves, it has never been more urgent to modernize enterprise .NET applications to maintain competitiveness and stay ahead of the next innovation. Updating .NET applications for the cloud is a major business priority and involves not only technical upgrades and cloud migration, but also improvements in tooling, processes, and skills. At this event, you will get the end to end insights across latest tools, innovations, and best practices for successful .NET modernization. What can developers expect? The event will run live for up to five hours each day, covering different aspects of .NET modernizations. Scott Hanselman will set the tone for day one with discussion of the experiences and processes to modernize .NET applications in the era of AI. This will be followed by expert sessions on upgrading .NET apps and modernizing both your apps and data to the cloud. Day two will soar higher into the clouds, with sessions to help with cloud migration, cloud development, and infusing AI into your apps. You can interact with experts and ask questions to deepen your expertise, as we broadcast live on YouTube, or Twitch. Recordings of all sessions will be available with materials after the event. Agenda Here’s a quick snapshot of the schedule. Things may change, and we recommend that you please visit the event home page for the latest agenda and session times: https://focus.dotnetconf.net/agenda Day 1 – April 22, Tuesday Time (PDT) Session 8:00 am Modernizing .NET: Future-ready applications in the era of AI Scott Hanselman, Chet Husk, McKenna Barlow 9:00 am Deep dive into the upcoming AI-assisted tooling to upgrade .NET apps Chet Husk, McKenna Barlow 10:00 am Use Reliable Web App patterns to confidently replatform your web apps Pablo Lopes 11:00 am Modernize Data-Driven Apps (No AI Needed) Jerry Nixon 12:00 pm Modernize from ASP.NET to ASP.NET Core: The Future is Now Taylor Southwick Day 2 – April 23, Wednesday Time (PDT) Session 8:00 am Unblock .NET modernization with AI-assisted app and code assessment tools Michael Yen-Chi Ho 9:00 am Cloud development doesn't have to be painful thanks to .NET Aspire Maddy Montaquila (Leger) 10:00 am Introducing Artificial Intelligence to your application Jordan Matthiesen 11:00 am Modernizing your desktop: From WinForms to Blazor, Azure, and AI Santiago Arango Toro Save the Date! .NET Conf: Focus on Modernization is a free, two-day livestream event that you won’t want to miss. Tune in on April 22 and 23, 2025, ask questions live, and learn how to get your .NET applications ready for the AI revolution. Save the date! Stay tuned for more updates and detailed session information. We can’t wait to see you there!Announcing the Public Preview of the New Hybrid Connection Manager (HCM)
Key Features and Improvements The new version of HCM introduces several enhancements aimed at improving usability, performance, and security: Cross-Platform Compatibility: The new HCM is now supported on both Windows and Linux clients, allowing for seamless management of hybrid connections across different platforms, providing users with greater flexibility and control. Enhanced User Interface: We have redesigned the GUI to offer a more intuitive and efficient user experience. In addition to a new and more accessible GUI, we have also introduced a CLI that includes all the functionality needed to manage connections, especially for our Linux customers who may solely use a CLI to manage their workloads. Improved Visibility: The new version offers enhanced logging and connection testing, which provides greater insight into connections and simplifies debugging. Getting Started To get started with the new Hybrid Connection Manager, follow these steps: Requirements: Windows clients must have ports 4999-5001 available Linux clients must have port 5001 available Download and Install: The new HCM can be downloaded from the following links. Ensure you download the version that corresponds to your client. If you are new to the HCM, check out the existing documentation to learn more about the product and how to get started. If you are an existing Windows user, installing the new Windows version will automatically upgrade your existing version to the new version, and all your existing connections will be automatically ported over. There is no automated migration path from the Windows to the Linux version at this time. Windows download Download the MSI package and follow the installation instructions Linux download From your terminal running as administrator, follow these steps: sudo apt update sudo apt install tar gzip build-essential wget "https://download.microsoft.com/download/HybridConnectionManager-Linux-preview.tar.gz" tar -xf HybridConnectionManager-Linux-preview.tar.gz cd HybridConnectionManager/ sudo chmod 755 setup.sh sudo ./setup.sh Once that is finished, your HCM is ready to be used Run `hcm help` to see the available commands For interactive mode, you will need to install and login to the Azure CLI. Authentication from the HCM to Azure is done using this credential. Install the Azure CLI with: `install azure cli: curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash` Run `az login` and follow the prompts Add your first connection by running `hcm add` Configure Your Connections: Use the GUI or the CLI to add hybrid connections to your local machine. Manage Your Connections: Use the GUI or the CLI with the `hcm list` and `hcm remove` commands to manage your hybrid connections efficiently. Detailed help texts are available for each command to assist you. Join the Preview We invite you to join the public preview and provide your valuable feedback. Your insights will help us refine and improve the Hybrid Connections Manager to better meet your needs. Feedback and Support If you encounter any issues or have suggestions, please reach out to hcmsupport@service.microsoft.com or leave a comment on this post. We are committed to ensuring a smooth and productive experience with the new HCM. Detailed documentation and guidance will be available in the coming weeks as we get closer to General Availability (GA). Thank you for your continued support and collaboration. We look forward to hearing your thoughts and feedback on this exciting new release.
Configure Virtual Applications, Mounted Azure Files, and Static File Access in Azure App Service
Background: In Azure App Service, developers often need to serve files (images, config files, data files, etc.) that are stored outside the app’s wwwroot folder — such as on an Azure File Share. This is especially useful when: You want to share files across multiple web apps Your files are too large to bundle with the app You need to manage files independently from the app deployment To accomplish this, Azure provides the ability to: Mount external Azure File Shares into your web app's file system Expose those mounted folders via virtual paths Configure directory browsing and MIME types to make files directly accessible over the browser Step-by-Step Configuration: ===Azure Storage Account part=== Create Azure File Share ===Azure App Service part=== 1.Mount Azure File Share Azure Portal → App Service → Configuration → Path Mappings → Mount Storage Click + New Azure Storage Mount Provide: Name: (e.g. fileshare) Storage account: Select your storage account Storage container: Select your file share name Mount Path: (e.g. /mounts/share) The mounted path will appear as C:\mounts\share in the backend file system (Kudu). 2.Set Virtual Path to Expose via URL Azure Portal → Configuration → Path Mappings → Virtual applications and directories Click + Add Virtual Path: e.g. /fileshare (URL access path) The Virtual Path is the URL path that users will type in the browser to access a folder or file hosted by your App Service. Physical Path: \mounts\share The Physical Path (Mount Path) is the actual folder path on the file system where your Azure File Share is located inside the App Service. Select Directory This maps URL path (Virtual Path, like /files) to a specific physical folder (Physical Path, like C:\mounts\share). 3.Verify File Structure in Kudu Open Kudu: https://<your-app-name>.scm.azurewebsites.net Go to: Debug Console → CMD → C:\mounts\share You should see your mounted file share contents (e.g., folders, .jpg, .json) Common Issues & Fixes Issue 1: Access Denied When Browsing Virtual Path Example URL: https://<app>.azurewebsites.net/fileshare/ -> Showing directory listing Error message from browser: You do not have permission to view this directory or page. Cause: Directory browsing is disabled by default. Solution: Create a web.config file under site\wwwroot with: <configuration> <system.webServer> <directoryBrowse enabled="true" /> </system.webServer> </configuration> This enables directory listing in browser. Issue 2: Can't open .json Files Example URL: https://<app>.azurewebsites.net/fileshare/folder1/AppInit.json -> Serving .json file correctly Error message from browser: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable. Cause: MIME type for .json files is not configured. Solution: Update web.config to allow serving .json: <configuration> <system.webServer> <staticContent> <mimeMap fileExtension=".json" mimeType="application/json" /> </staticContent> </system.webServer> </configuration> Reference: Configure an App Service App - Azure App Service | Microsoft Learn
