Superfast Installing Code Push Server in a Windows Web App

Variable Name

Variable Value

AZURE_STORAGE_ACCOUNT

<Storage Account name you've copied from step 4>

AZURE_STORAGE_ACCESS_KEY

<Storage Account key you've copied from step 4>

SERVER_URL

<https:// + Web app FQDN you've copied from step 2>

e.g., https://az-7135-app.azurewebsites.net

CORS_ORIGIN

<https:// + Web app FQDN you've copied from step 2>

e.g., https://az-7135-app.azurewebsites.net

LOGGING

false

File name

Change

Reason

.env

Please setup AZURE_STORAGE_ACCOUNT, AZURE_STORAGE_ACCESS_KEY, and SERVER_URL follow step 4

From Official Tutorial Bicep Template

web.config

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <system.webServer>

    <handlers>

      <add name="iisnode" path="server.js" verb="*" modules="iisnode" />

    </handlers>

    <rewrite>

      <rules>

        <rule name="NodeJsApp" stopProcessing="true">

          <match url=".*" />

          <action type="Rewrite" url="server.js" />

        </rule>

      </rules>

    </rewrite>

    <iisnode

      loggingEnabled="false"

      debuggingEnabled="true"

      devErrorsEnabled="true"

    />

  </system.webServer>

</configuration>

When using a Windows App, the HTTP server is IIS. As a reverse proxy, IIS needs to forward incoming requests to another web server running on the same machine—in this case, node.exe.

Due to several path limitations in web.config (such as not supporting nested directories for the entry point), the server.js file must reside in the same directory as web.config. Since the original project uses bin/script/server.js as the entry point, which cannot be directly referenced here, you need to create a new server.js file in the root directory as a wrapper to forward execution.

The iisnode section in web.config is useful for debugging purposes. However, it requires the debugging settings described below to work correctly. Once debugging is complete, this section can be safely removed.

server.js

// Wrapper to launch actual entry point

require("./bin/script/server.js");

Same as above

script/server.ts

  //const port: number = Number(process.env.API_PORT) || Number(process.env.PORT) || defaultPort;

  const port: number = process.env.API_PORT || process.env.PORT || defaultPort;

All traffic in Windows Web Apps is routed through IIS to node.exe, so the actual listening port is not a traditional number but a system-generated internal pipe (e.g., \\.\pipe\dff22378-aeb3-4ede-8d1e-7c1e1bdc0c46). Therefore, adjustments are needed to align with this architecture.

package.json

Before: "main": "./script/server.js",

After: "main": "server.js",

Before: "start": "node ./bin/script/server.js",

After: "start": "node server.js",

Before: "start:env": "node -r dotenv/config server.js dotenv_config_path=.env dotenv_config_silent=true",

After: "start:env": "node -r dotenv/config server.js dotenv_config_path=.env dotenv_config_silent=true",

Before: "build": "tsc && shx cp -r ./script/views ./bin/script",

After: "build": "npm install typescript --save-dev && tsc && shx cp -r ./script/views ./bin/script",

Like web.config, we change most entry points to use a root-level server.js instead of a path with nested folders.

Additionally, note that the Oryx build process differs between Windows and Linux Web Apps. On Windows, the build step only runs npm install and npm run start, but not npm run build. Also, the underlying OS doesn’t come with TypeScript pre-installed. This causes npm run build to fail unless adjusted.

To resolve this, modify the build script to include TypeScript installation. After deployment, you must also manually run npm run build once using the Kudu interface.