What does Azure App Service need to run a Node app?

Choose a supported Node.js version and verify how the app starts. App Service supplies the Linux hosting platform. Your project supplies the web process and the settings it needs to run. On the built-in Linux Node.js runtime, App Service supplies a port number in PORT, so your app needs to read process.env.PORT and listen on that port to receive requests.

Before a hosted deployment, identify the subscription and Region, the resource group that contains the app, and the App Service plan that supplies its compute. Record which version of the source is deployed and how its private settings are supplied.

How can you tell whether the app starts with the intended settings?

Use a disposable local copy or work on paper. Before starting it, verify the project folder, Node version and local address. Keep live credentials, databases, files and messages disconnected. Use only dummy settings and stay on paper if you cannot confirm those connections.

Write down the start command
Use the project’s documented command for starting its web process. Give the dummy app a status page and a practice setting named SHOP_LABEL that appears on that page. Use invented labels only.
Start with the first practice setting
Start the disposable copy with “Morning practice” and check that the local status page shows it. Write down the address and expected text.
Restart with a different value
Stop the first copy, then start the same code with “Afternoon practice” and check the new text. On paper, track which code and setting value each test address should use. The exercise should tell you whether the value came from the intended environment.

When does an Azure deployment slot help?

A slot is another running app with its own address on the same App Service plan. Standard, Premium and Isolated plans support slots. The app and its slots share the plan’s capacity. Review the slot’s own access and connections before using its address.

Use a separate test app for an isolated first rehearsal. When a real release uses a slot, check which settings stay with each slot and which travel with the app. During a swap, Azure can apply the destination’s settings to the staging app before the address changes. Confirm the app can start and warm up without writing unexpected data or sending messages.

Swapping the same slots back can return the earlier code to the live address. Keep a separate recovery plan for any connected database and files.

Which Azure charges can continue after stopping the web app?

A paid dedicated App Service plan charges for each computing instance for the time it stays allocated. Stopping the app, or keeping an empty paid plan, can leave those charges in place. Check which apps and slots still use the plan before deciding what to keep.

Estimate the plan using the actual Region, operating system, tier and instance count. Budget separately for a database, file storage, outbound transfer and monitoring that you add. The Free tier is intended for trying the service and has limits.

What can you recover when you restore an Azure web app?

Check what your App Service plan’s backup covers. App content and configuration have their own backup scope. Keep a separate native database backup and a copy of files stored in external or mounted storage.

Keep the source, build and startup instructions and the names of settings the app expects. Use a durable store for customer uploads. Verify the actual deployment’s storage settings before you rely on any file surviving an app replacement.

For a recovery rehearsal, verify an isolated destination and test-only login before restoring sample data. Start a disposable copy of the app and check that the same sample record and file can both open after recovery.