Forum Discussion

Gabriel_Naranjo's avatar
Jun 23, 2025

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.

  1. The first step is to create our Resource Group (RG); in my case, I will name it "n8n-rg".

 

  1. 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.
  2. 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.
  3. 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.

 

  1. In the Database section, we do not select any option. Remember that this will depend on your specific requirements.
  2. 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.
  3. 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.
  4. 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.
  5. 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'.

 

  1. Finally, click on 'Create' and wait for the deployment process to complete.
  2. 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'.
  3. 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.

8 Replies

  • JustincyHuang's avatar
    JustincyHuang
    Copper Contributor

    Great for the working lab.

    One thing to mention that the Environment variables in the screenshot should be N8N_PROTOCOL N8N_PORT instead of PORT_N8N and PROTOCOL_N8N

  • Wells2250's avatar
    Wells2250
    Copper Contributor

    Hi Gabriel, thanks for this it works well.  However, ssh doesn't work with this setup (- is there a way to make this work?

  • JoeGC's avatar
    JoeGC
    Copper Contributor

    Hi Gabriel,

    Thanks for an interesting walkthrough. Just one comment. In the Docker Hub section, image and tag,  maybe you could mention that this value should be n8nio/n8n:latest. Leaving out the tag named latest prevented my web app setup from working correctly. 

    Many thanks

     

  • KheangHC's avatar
    KheangHC
    Copper Contributor

    Hi Gabriel,

    I did the same setup on my end in order to test N8N and it works great.

    The only difference is I am using the default DB and I am using the Azure Files mount which seems to work fine.

    Although I am still testing, I haven't noticed any performance issues or file locking issues like some comments I seem to have read.

    Do you assume or expect it is something that can or will happen if I go this route for production?

     

    Also, what about Scaling Out? I know N8N has its own way to support multiple instances (workers) but I was wondering if you guys thought or came up of a way to make use/benefit of the Azure Web App Scale Out feature.

     

    I know I can scale up easily, but scaling out would also be an added benefit, if it worked off the bat.

     

    Thanks for the great doc.

    • Hi, I'm glad my post was useful and helpful. Regarding your question, for production environments you can effectively use horizontal and vertical scaling. Remember that this will depend on the plan you're using. Also, regarding the scaling model, I'm currently testing Container Apps, which also works wonderfully. It offers the scalability you mentioned, both vertically and horizontally, and, above all, is much more economical. I'll be writing a post with this configuration soon.

  • Debasish's avatar
    Debasish
    Copper Contributor

    Hi Gabriel,

    Thank you so much for this! This is by far the simplest and most effective method I’ve come across for deploying n8n.

    I’ve been using a cloud-based subscription and, to be honest, have been paying a bit too much for n8n hosting. I’ve been exploring ways to host it locally on my Azure infrastructure, and this guide gives me exactly what I needed.

    If it’s okay, I had a couple of follow-up questions:

    What’s the benefit of using an App Service along with a separate database in this n8n setup?
    If a new version of the n8n image is released, would I need to redeploy it manually to get the latest update?

    Thanks again for sharing this helpful approach!

  • Debasish's avatar
    Debasish
    Copper Contributor

    Hi Gabriel,

    Thank you so much for this! This is by far the simplest and most effective method I’ve come across for deploying n8n.

    I’ve been using a cloud-based subscription and, to be honest, have been paying a bit too much for n8n hosting. I’ve been exploring ways to host it locally on my Azure infrastructure, and this guide gives me exactly what I needed.

    If it’s okay, I had a couple of follow-up questions:

    What’s the benefit of using an App Service along with a separate database in this n8n setup?
    If a new version of the n8n image is released, would I need to redeploy it manually to get the latest update?

    Thanks again for sharing this helpful approach!

    • Thanks Debasih for you commet. let me explain:
      Using Azure App Service with an external database (such as PostgreSQL) in an n8n deployment allows for a clean separation between the application runtime and data persistence, which is critical for scalability and production grade stability. The App Service handles the container lifecycle and supports auto-scaling, while the external database ensures workflows, credentials, and execution history are retained across restarts and deployments something not possible with n8n’s default SQLite setup. Regarding updates, if you use a fixed image tag (e.g., n8nio/n8n:1.49.0), you must manually update the container to get newer versions. Using the latest tag will automatically pull the newest version on each restart, but this is not recommended in production due to the risk of breaking changes. i hope this is helpful for you. :)

Resources