Hosting Nuxt on Azure App Service (iisnode) with custom Git based deployment (kudu)

..Instructions

Previously this gist had a series of files showing a working setup, but, 
@burkeholland found a much easier way and demonstrates it here:
https://github.com/burkeholland/nuxt-appservice-windows

Essentially, you'll:
1. add a .deployment file to instruct kudu to run `npm install` for you, 
2. leverage npm tasks' `postinstall` hook in package.json to trigger the full nuxt build,
3. add a server.js file in the root that `require`s the default server\index.js file that a nuxt app will already have

Step 3 will be noticed by kudu, which will:
* auto-create you a default web.config for iisnode (if no web.config exists), and 
* use that server.js as the entry point, which you've now redirected over to nuxt's default server.js cleanly

Notes: 
* For step 3, you'll only have a `server\index.js` if you've chosen a server-side framework in the `npm create nuxt-app xyz` setup. 
  I had success with express.
* Don't forget to make sure your Azure app is on a high enough node version for both running AND building. 
  You can now create apps from the portal with a version picker which is nice. 
  Otherwise you'll wanna configure it with the app setting for runtime and in the .deployment config file for kudu/building.

Kudus to Burke! (pun intended)

Looks like is like you say @benmccallum. Today I checked by chance the page on Azure of the nuxt guide; in the web.config example, by the end there is an explanation about defining a set of files to be watch and recyle the server if they change.

Nevertheless, I would ask for further clarification to a NodeJS/Express expert.

Good spot! I guess if you were doing in-memory caching (inside your node app of config files or something) then it makes sense that you'd need to configure watching of those files to restart the app. Since they haven't indicated anything in particular I'd say that nuxt itself doesn't do anything like this or can handle those kinds of filesystem changes. Static assets (those picked up by the static rewrite rule) will cache bust themselves as part of standard IIS if you had static asset caching I imagine (which isn't demonstrated here but should probably be turned on).