NUXT seems to be dominating the Server Side rendering scene in the VueJS ecosystem, it’s the hottest new buzzword in the framework. But have you ever tried to deploy it? Chances are if you’ve landed here you were just as confused, lost and desperate for answers as I was.

The documentation on the site is not that great when it comes to deployment, especially for Azure. They basically just throw you a web.config and let you fend for yourself. Other resources online seemed to suggest that the easiest way to deploy to azure was using the VS Code extension, and although that might do the job it’s not super great for continuous deployment and automated build pipelines. After trying the VS Code extension for myself on my own project, it did not work, and I was back to square 1 trying to deploy this nuxt app.

What you’ll need

  1. Azure Dev Ops Project (Where your NUXT app repository will be hosted)
  2. NUXT universal app (^@nuxt/2.0.0)
  3. Azure Linux App Service Plan
  4. Azure Linux Web App

In order to deploy your universal NUXT app to azure, you’ll need an Azure Linux web app service. This means you’ll also need a Linux app service plan to put the web app on. Linux is the preferred app service kind for Node applications, and I found it to be easier than trying to configure a Windows IIS app service.

You’ll also need an Azure Dev Ops (ADO) project that holds your NUXT application repository, and within that project, we will set up our build and release pipelines that will continuously deploy our application to our app service.

Configuring your Web App

As long as you selected the Linux Web App (which is the default) when you were creating your Azure App Plan and Service, the only other configuration you need is to set some properties under your Web App Configuration section.

Add two configuration properties on your web app under Application Settings for HOST and NODE_ENV.

NODE_ENV: production

That’s it, those are the only two things you have to add, you should also just make sure that under General Settings you selected a stack of Node.js, and have selected the correct version of Node, likely this should just be LTS. I’m using 10.14 on my own stack.

Configure ADO Build Pipeline

In ADO, on the left side navigation drawer, select the blue rocket and head to “Pipelines”. Go ahead and create a new pipeline. Make sure you select Use the classic editor without YAML (unless you actually know how to YAML, then translate what I say to YAML) when you click New Pipeline at the top right. On the next page, you should be able to select your source, your code will be in an ADO repository under the same project, so select the correct repository for your NUXT application, as well as, select the branch you want to deploy. On the next step, go ahead and just select the Empty job at the top, no need to use a template since we’ll only have 5 tasks.

Pipeline Tasks

The first task should be defaulted to “Agent Job 1” / Run on agent. This will just be whatever agent you want to build your application with, it shouldn’t make a huge difference, I usually just let it run on the Azure Hosted. This will likely also be inherited from the pipeline config, so you might not need to change anything.

With the “plus” icon on the left window pane list, go ahead and add a new task, in the search box type “npm” and add the “npm” task that should be the first result.

you can rename the task to whatever you like, I like to make mine a bit descriptive, so this task will be “npm install” and under the command section of your npm task, just select install. You don’t need to select anything under “working folder that contains package.json” that will be determined by ADO. Click the “plus” add icon again and add another npm task. This time the npm task name will be “npm build” and under command, select custom and in “run commands and arguments” just type run build.

The next task we want to add is a “Copy Files” and we will set the display name for this to be “Copy Files to: $(Build.ArtifactStagingDirectory)”. Your source folder should be set to $(System.DefaultWorkingDirectory), and you’ll want to set your contents section to include the following





the target directory should be $(Build.ArtifactStagingDirectory).

Next, add an “Archive Files” task, and set the root folder to $(Build.ArtifactStagingDirectory), select an archive type of zip, and set archive file to create to $(Build.ArtifactStagingDirectory)/ Check the box for “replace existing archive”.

The last task we need is the “Publish build artifacts”. The path to publish should be $(Build.ArtifactStagingDirectory)/, the artifact name will be drop, and the publish location will be Azure pipelines.

When you’re all done your build pipeline should have these tasks configured as directed above. and we are ready to move on to the release pipeline to deploy our code on Azure.

Configure ADO Release Pipeline

On the left navigation drawer under the blue rocket, select “Releases”, then click the New dropdown and select “New release pipeline”. This will open up a panel on the right, either select or search for Azure App Service Deployment and apply.

The stage name doesn’t matter and you can rename it to whatever you like. “Stage 1” is fine, or you could name it “Deploy” up to you. On the left, click Add an artifact, keep the source type to the default “Build”, and then with the select dropdown select the build pipeline we just created above. You’ll want to leave the default version to “Latest” and you can change the source alias to whatever you want, but I just leave mine set to whatever ADO populates the field with. Be sure to also check the “Lightning Bolt” icon that will come up once you have selected your artifact, as this will be the trigger for enabling your continous deployment when the pipeline detects a new build.

After setting your artifact, click the “1 job, 1 task” under the “Stage 1” in your stages section.

All you have left to configure is the form fields for selecting your Azure subscription, and the Linux app service under that subscription that you created to deploy your NUXT app. For the “Startup command” you can leave it blank as the startup command by default on a Linux Node app is npm start, which will call our start script in the package.json to serve NUXT.

After selecting your subscription, and service, click the “Deploy Azure App Service” task, and under Post Deployment Action select inline script and in the script section just type npm install. This will ensure that once you have deployed your application files, the packages needed to serve your app will be installed on the Azure app service.

Once all of those fields have been configured, you can go ahead and deploy your NUXT app to azure with ADO CI/CD pipelines.

Save & Queue

After you’ve configured these, go ahead and manually build your project, and let the pipeline deploy your NUXT app to Azure! That’s it, you’re app should now be live for the world to see. Hopefully, this quick guide walked you through the steps needed to deploy a NUXT app to Azure as the resources I found online were not great and or incomplete.

Post Deploy Issues

Nuxt could at some point decide that it doesn’t want to deploy or release successfully anymore. If that ever becomes the case, here is a list of problems and potential solutions.

Release Failed
Check the release logs, if the release failed, it is very likely that it failed at the Run post-deployment script step. If this happens, you can try logging into the Kudu advanced tools bash console on the azure app service and wipe the node_modules and package-lock.json files with rm -rf node_modules && rm -rf package-lock.json from within the site/wwwroot directory.

* * be careful when deleting your package-lock.json, you may run into the problem where you deployment versions are later than your local versions and things are working locally but not in production.

After completing this step, try to release again, with a fresh wwwroot, the post deployment npm install script should not run into any issues.

If the release continues to fail, and you cannot remove the node_modules directory due to Directory not empty errors, delete the app service and recreate it. After the app service has been recreated, try a fresh release.

Application Error 🙁
If you released the app and it claims it was successful, but when you go to the URL and see an application error page, log into the azure app service, and under Diagnose and solve problems check the application logs for errors for nuxt failed to start. It should show you what is failing, and you can work from there to resolve.

This could also occur if your app service is missing the HOST configuration value


Todd Matthews · May 20, 2020 at 2:51 pm

I struggled with this for days! This article helped a bunch. Thank you for sharing it. In the end, I couldn’t get my default SSR Nuxt app working till I also added `server/**` to the contents to be copied in Azure Pipelines.

Dalius · November 10, 2020 at 1:01 pm

Thanks a lot! I deployed it with yarn. But when yarn install runs after deployment it takes very long time, I mean like 15min+ on kudu. What could be the issue?

    Dalius · November 10, 2020 at 1:02 pm

    Yarn version in pipeline is 1.22 and in kudu it is 1.17, maybe that could be the issue. Or does it depend on app service plan? Because mine is free at the moment

    Michael Kranker · November 10, 2020 at 1:11 pm

    Awesome, glad you could get your app deployed!

    I wouldn’t be too worried about the module install, the particular app I was working with at the time would regularly take at least 9mins plus, and even then would still sometimes fail and require the node_modules to be purged completely.

    There are a lot of things that could factor into that, but as long as it succeeds eventually that’s what counts.

Leave a Reply

Your email address will not be published. Required fields are marked *