How to deploy n8n on Azure App Service and leverage the benefits provided by Azure.
Lately, n8n has been gaining serious traction in the automation world—and it’s easy to see why. With its open-source core, visual workflow builder, and endless integration capabilities, it has become a favorite for developers and tech teams looking to automate processes without being locked into a single vendor. Given all the buzz, I thought it would be the perfect time to share a practical way to run n8n on Microsoft Azure using App Service. Why? Because Azure offers a solid, scalable, and secure platform that makes deployment easy, while still giving you full control over your container and configurations. Whether you're building a quick demo or setting up a production-ready instance, Azure App Service brings a lot of advantages to the table—like simplified scaling, integrated monitoring, built-in security features, and seamless CI/CD support. In this post, I’ll walk you through how to get your own n8n instance up and running on Azure—from creating the resource group to setting up environment variables and deploying the container. If you're into low-code automation and cloud-native solutions, this is a great way to combine both worlds. The first step is to create our Resource Group (RG); in my case, I will name it "n8n-rg". Now we proceed to create the App Service. At this point, it's important to select the appropriate configuration depending on your needs—for example, whether or not you want to include a database. If you choose to include one, Azure will handle the connections for you, and you can select from various types. In my case, I will proceed without a database. Proceed to configure the instance details. First, select the instance name, the 'Publish' option, and the 'Operating System'. In this case, it is important to choose 'Publish: Container', set the operating system to Linux, and most importantly select the region closest to you or your clients. Service Plan configuration. Here, you should select the plan based on your specific needs. Keep in mind that we are using a PaaS offering, which means that underlying compute resources like CPU and RAM are still being utilized. Depending on the expected workload, you can choose the most appropriate plan. Secondly—and very importantly—consider the features offered by each tier, such as redundancy, backup, autoscaling, custom domains, etc. In my case, I will use the Basic B1 plan. In the Database section, we do not select any option. Remember that this will depend on your specific requirements. In the Container section, under 'Image Source', select 'Other container registries'. For production environments, I recommend using Azure Container Registry (ACR) and pulling the n8n image from there. Now we will configure the Docker Hub options. This step is related to the previous one, as the available options vary depending on the image source. In our case, we will use the public n8n image from Docker Hub, so we select 'Public' and proceed to fill in the required fields: the first being the server, and the second the image name. This step is very important—use the exact same values to avoid issues. In the Networking section, we will select the values as shown in the image. This configuration will depend on your specific use case—particularly whether to enable Virtual Network (VNet) integration or not. VNet integration is typically used when the App Service needs to securely communicate with private resources (such as databases, APIs, or services) that reside within an Azure Virtual Network. Since this is a demo environment, we will leave the default settings without enabling VNet integration. In the 'Monitoring and Security' section, it is essential to enable these features to ensure traceability, observability, and additional security layers. This is considered a minimum requirement in production environments. At the very least, make sure to enable Application Insights by selecting 'Yes'. Finally, click on 'Create' and wait for the deployment process to complete. Now we will 'stop' our Web App, as we need to make some preliminary modifications. To do this, go to the main overview page of the Web App and click on 'Stop'. In the same Web App overview page, navigate through the left-hand panel to the 'Settings' section. Once there, click on it and select 'Environment Variables'. Environment variables are key-value pairs used to configure the behavior of your application without changing the source code. In the case of n8n, they are essential for defining authentication, webhook behavior, port configuration, timezone settings, and more. Environment variables within Azure specifically in Web Apps function the same way as they do outside of Azure. They allow you to configure your application's behavior without modifying the source code. In this case, we will add the following variables required for n8n to operate properly. Note: The variable APP_SERVICE_STORAGE should only be modified by setting it to true. Once the environment variables have been added, proceed to save them by clicking 'Apply' and confirming the changes. A confirmation dialog will appear to finalize the operation. Restart the Web App. This second startup may take longer than usual, typically around 5 to 7 minutes, as the environment initializes with the new configuration. Now, as we can see, the application has loaded successfully, and we can start using our own n8n server hosted on Azure. As you can observe, it references the host configured in the App Service. I hope you found this guide helpful and that it serves as a useful resource for deploying n8n on Azure App Service. If you have any questions or need further clarification, feel free to reach out—I'd be happy to help.Enterprise-Ready and Extensible: Update on the Azure SRE Agent Preview
At Build, we unveiled the Azure SRE Agent with a powerful end-to-end incident handling experience - detecting, diagnosing, mitigating, and handing off issues to development teams. Since then, it’s evolved dramatically in capability, coverage, and enterprise readiness. Designed to streamline incident response, improve uptime, and reduce operational costs, the agent is a pre-built AI assistant that brings intelligent automation to your Azure workloads. During the preview, customers explored features like natural language operations, proactive best practices, incident response, and daily health reports helping shape the updates we’re excited to share today. Before we dive into what’s new, here’s an important update: Billing for all Azure SRE Agent customers will officially begin on September 1, 2025 as previously announced. The billing model includes two components: an always-on flow for continuous monitoring and an active flow for incident mitigation and task execution. Pricing is based on Azure Agent Units (AAUs)—a new metric that standardizes agentic processing across Azure’s growing family of AI agents. Customers can estimate costs using the Azure pricing calculator. Please refer to the billing announcement blog for more information. With billing starting soon, we’re excited to highlight how the Azure SRE Agent has matured since Build. From deeper diagnostics to smarter integrations, the agent is now more capable, secure, and adaptable than ever ready to support enterprise-scale incident response with confidence. Today, the agent is: Secure by design: Operates with read-only permissions and user-approved actions for governance. Diagnostic-rich: Delivers deeper insights across a wider range of Azure services. Seamlessly integrated: Connects with Azure Monitor, PagerDuty, ServiceNow, GitHub, and Azure DevOps. Extensible incident handling: Uses past incident patterns and user-supplied Runbooks to guide response actions. Source Code aware: Performs source code level root cause analysis for pinpoint accuracy. Whether you’re automating incident response or keeping humans in the loop, the agent adapts to your operational style securely and consistently. What’s New Since Build 1. Granular Permissions with Governance Configure the agent with read-only access to Azure resources. When a write operation is needed, it requests explicit user approval. This ensures safe-by-default operations with full auditability. 2. Expanded Azure Service Skills The agent now supports deeper diagnostics and safe operations across: Azure CLI, kubectl and psql CLI: Answers questions and assists with operations across subscriptions, Kubernetes clusters and databases. PostgreSQL: Diagnoses and performs safe maintenance tasks Azure API Management (APIM): Inspects gateway behavior, policies, and runtime signals. Azure Functions, App Service, AKS, ACA: Offers richer diagnostics and operational insights. And with Azure CLI support, it can reason over any Azure service even those not explicitly listed. 3. Incident Management Integrations In addition to Azure Monitor alerts (enabled by default) and PagerDuty, the agent now integrates with ServiceNow for incident intake, updates, and status synchronization. These integrations ensure that incidents are automatically captured, diagnosed, and mitigated quickly. 4. DevOps Loop Closure In addition to GitHub, the agent now supports generating incident reports directly into Azure DevOps work items. These reports can be assigned to coding agents to automatically create pull requests and merge changes after validation. This closes the loop from detection to remediation ensuring that learnings turn into actionable fixes, not just documentation. 5. Extensible Incident handling The agent now supports customizable incident handling by learning from past incidents and applying user-supplied instructions. When similar issues arise, it can identify previously successful resolution steps and reuse them to ensure consistent outcomes. You can also define specific Runbook instructions, allowing the agent to follow your preferred workflows—whether fully automated or with human oversight. 6. Source Code Aware RCA Root cause analysis now includes source code context via connections to Azure DevOps and GitHub. After analyzing logs, metrics, and exceptions, the agent links impacted resources to relevant code and validates suspected causes—pointing to specific files, methods for faster and more confident resolution. What’s in It for You Reduced Toil: Less manual triage and fewer repetitive tasks. Improved Uptime: Faster detection and mitigation keeps services running. Lower MTTR: Faster diagnosis and mitigation. Enterprise-Grade Safety: Read-only permissions + approvals = safe by default. The Azure SRE Agent is built to meet the demands of modern cloud operations - secure, extensible, and ready to scale with your team. Whether you're looking to reduce toil, improve uptime, or close the loop between detection and remediation, the agent is ready to help. Ready to get started? Signup for preview access Azure SRE Agent home page Product overview Pricing Page Pricing Calculator Pricing Blog Agentic DevOps Blog: Evolving software development with GitHub Copilot and AzureKickstart Conditional Access in Microsoft Entra: Free Starter Pack with Policies & Automation
Introduction Conditional Access (CA) is the backbone of Zero Trust in Microsoft Entra ID. It helps you enforce security without compromising productivity. But rolling out CA can feel risky what if you lock out admins or break apps? To make this easier, I’ve created a free starter pack with: Ready-to-use policy templates (JSON) PowerShell scripts for deployment via Microsoft Graph GitHub Actions workflow for automation Safe rollout strategy using report-only mode Why This Matters Block legacy authentication to reduce attack surface. Require MFA for admins to protect privileged accounts. Handle high-risk sign-ins with compliant device + MFA. Validate impact before enforcing using report-only mode. What’s Inside the Starter Pack ✔ Policies Block legacy authentication Require MFA for admin roles High-risk sign-ins → compliant device + MFA Safety-net report-only baseline ✔ Scripts Deploy policies (deploy-conditional-access.ps1) Export existing policies Toggle report-only mode ✔ Automation GitHub Actions workflow for CI/CD deployment ✔ Docs Usage guide Safe rollout checklist How to Use It Download the repo: GitHub Repo: https://github.com/soaeb7007/entra-ca-starter-pack Install Microsoft Graph PowerShell SDK: Install-Module Microsoft.Graph -Scope CurrentUser Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess','Directory.Read.All' Select-MgProfile -Name beta Deploy policies in report-only mode: ./scripts/deploy-conditional-access.ps1 -PolicyPath ./policies -ReportOnly Validate impact in Sign-in logs before enforcing. Safe Rollout Checklist Exclude break-glass accounts, Start with report-only, Validate for 48–72 hours, Roll out to pilot group before org-wide Next Steps Enable report-only mode for new policies. Explore Conditional Access templates in Entra portal. Watch for my next post: “Optimizing Conditional Access for Performance and Security.” What’s your biggest challenge with Conditional Access? Drop it in the comments, I’ll cover the top 3 in my next post.Announcing a flexible, predictable billing model for Azure SRE Agent
Billing for Azure SRE Agent will start on September 1, 2025. Announced at Microsoft Build 2025, Azure SRE Agent is a pre-built AI agent for root cause analysis, uptime improvement, and operational cost reduction. Learn more about the billing model and example scenarios.
[ADO] Work Items custom states
Hello. Wer shifting to ADO as a project management tool (not for software development and delivery, not directly). I'm creating our own custome process (inheriting from Agile) and was wondering if there is any way for us (my team) to have custom workflow states to be created by default instead of havig to do it manually for each work item type we create. This is what we would like to have and has we have some several WI types to create would make our lives easier and possibly future proof it in case we need to make changes (add or edit - through delete+add - more WI). Thank you.
Azure DevOps sometimes doesn't trigger build for GitHub PRs
Hello Community, I have an Azure Pipelines plugin installed on my application's GitHub repo. We should have a CI build trigger for each PR and when those PR merged into specific branches. The issue is that sometimes the build is getting triggered for the PR commits, but when merging this PR to the branch, the build is not triggered, and I have to run it manually.
Built a Real-Time Azure AI + AKS + DevOps Project – Looking for Feedback
Hi everyone, I recently completed a real-time project using Microsoft Azure services to build a cloud-native healthcare monitoring system. The key services used include: Azure AI (Cognitive Services, OpenAI) Azure Kubernetes Service (AKS) Azure DevOps and GitHub Actions Azure Monitor, Key Vault, API Management, and others The project focuses on real-time health risk prediction using simulated sensor data. It's built with containerized microservices, infrastructure as code, and end-to-end automation. GitHub link (with source code and documentation): https://github.com/kavin3021/AI-Driven-Predictive-Healthcare-Ecosystem I would really appreciate your feedback or suggestions to improve the solution. Thank you!Scaling Smart with Azure: Architecture That Works
Hi Tech Community! I’m Zainab, currently based in Abu Dhabi and serving as Vice President of Finance & HR at Hoddz Trends LLC a global tech solutions company headquartered in Arkansas, USA. While I lead on strategy, people, and financials, I also roll up my sleeves when it comes to tech innovation. In this discussion, I want to explore the real-world challenges of scaling systems with Microsoft Azure. From choosing the right architecture to optimizing performance and cost, I’ll be sharing insights drawn from experience and I’d love to hear yours too. Whether you're building from scratch, migrating legacy systems, or refining deployments, let’s talk about what actually works.
