Azure → Virtual Machine Scale Sets

Question

Azure → Virtual Machine Scale Sets

Subhash Chand 0

Hello Microsoft Community Team,

I am currently running multiple applications on Azure Virtual Machine Scale Sets (VMSS) and would like guidance on industry best practices for managing deployments.

Current Setup

I have 12 different projects running on a VMSS.

The VMSS is created from a custom image (captured from a parent VM).

New VM instances are provisioned only from this image .

Some projects require:

npm install

  `npm run build`
  
     Others are already built and only need runtime execution.

Problem Statement

I push code updates daily. My current concern is:

Do I need to create a new VM image every day after each code change?

If not, what is the recommended way to:

Deploy frequent code updates

  Handle different build requirements across multiple projects
  
     Keep VMSS instances consistent and scalable

Questions

What is the recommended industry approach for handling frequent deployments on VMSS?
Should VM images be treated as:
- Immutable base images (OS + runtime only), or
- Fully baked images including application code?
How should I manage multiple Node.js projects with different build steps on the same VMSS?
Hello Microsoft Community Team, I am currently running multiple applications on Azure Virtual Machine Scale Sets (VMSS) and would like guidance on industry best practices for managing deployments.
Current Setup
- I have 12 different projects running on a VMSS.
- The VMSS is created from a custom image (captured from a parent VM).
- New VM instances are provisioned only from this image.
- Some projects require:
- npm install
- npm run build
- Others are already built and only need runtime execution.
Problem Statement
I push code updates daily.
My current concern is:
- Do I need to create a new VM image every day after each code change?
- If not, what is the recommended way to:
- Deploy frequent code updates
- Handle different build requirements across multiple projects
- Keep VMSS instances consistent and scalable
Questions
1. What is the recommended industry approach for handling frequent deployments on VMSS?
2. Should VM images be treated as:
  - Immutable base images (OS + runtime only), or
  - Fully baked images including application code?
3. How should I manage multiple Node.js projects with different build steps on the same VMSS?

FYI i am not using docker and k8

Marcin Policht 77,030 Reputation points MVP Volunteer Moderator

2026-01-22T12:12:08.3066667+00:00

In an Azure VMSS–based model without Docker or Kubernetes, the recommendation is generally to separate concerns between infrastructure and application deployment, and to avoid rebuilding VM images for every code change.In most mature setups, VM images are treated as immutable base images that contain only the operating system, security hardening, monitoring agents, and language runtimes such as Node.js. These images change infrequently, typically only when you need OS patching, runtime upgrades, or baseline configuration changes. Rebuilding an image daily for application code changes is considered an anti-pattern because it slows down delivery, increases operational overhead, and couples infrastructure lifecycle to application lifecycle.

For frequent deployments, application code is usually deployed after the VM instances are provisioned. On VMSS this is commonly done through a CI/CD pipeline that targets the scale set. Azure DevOps or GitHub Actions can connect to the VMSS and push code updates using mechanisms such as a Custom Script Extension, Run Command, or a configuration management tool. In this approach, new code is copied to the instances, dependencies are installed, build steps are executed if needed, and the application process is restarted, all without recreating the VM image.

For Node.js projects with different build requirements, the recommended approach is to move build steps out of the VMSS whenever possible. Projects that require npm install and npm run build should ideally be built in the CI pipeline, producing build artifacts such as compiled JavaScript, bundled assets, or a dist directory. These artifacts are then deployed to the VMSS instances. This avoids running heavy build workloads on every VM instance and ensures consistency across the scale set. Projects that are already built can be deployed directly as runtime artifacts.

A common pattern is to standardize a deployment script that runs on each VM instance and knows how to handle multiple applications. For example, the script can pull versioned artifacts from Azure Blob Storage, Azure Artifacts, or another artifact repository, place them in predefined directories, install production-only dependencies if required, and restart the relevant Node.js services using a process manager such as PM2 or systemd. This keeps all instances consistent while allowing different applications to follow different build paths upstream.

To maintain consistency and scalability, you should avoid manually changing individual VM instances. All changes should be driven through automation so that scale-out events result in new instances that automatically configure themselves to the current application version. This usually means embedding a bootstrap script in the VMSS model that runs on provisioning and then re-running deployment scripts whenever a new release is pushed.

I tend to also separate applications by VMSS rather than running many unrelated projects on the same scale set. While not strictly required, this improves isolation, allows independent scaling, and simplifies deployments. If that is not feasible, consider using a strong conventions around directory layout, ports, service management, and deployment scripts.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

1 answer

Your answer

Answer 1

@Subhash Chand You do not need to create a new VM image every day we can suggest using the image as a stable base and deploy app changes via automation on top of the VMSS - https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app

Do I need a new image per code change - Microsoft shows two main options for VMSS app deployment:

custom image with app preinstalled, or
base image + install or update scripts orextensions

Always Use VMSS with immutable base images: OS, security hardening, monitoring agents, Node.js runtimes and common tools.

Deploy app versions through automated mechanisms - Create and deploy VM Application - https://learn.microsoft.com/en-us/azure/virtual-machines/vm-applications-how-to?tabs=TAR%2Ccli1%2Ccli2%2Crest3%2Crest4
Custom Script Extension to download and install/update the app.
VM Applications to package the app, upload to Storage, and assign that VM Application version to the VMSS. Use VMSS upgrade policy to roll changes through instances, combined with health checks.

Immutable vs fully baked images - Both are valid and the choice is about cadence and complexity.

Immutable base image (OS and runtime only)
Image updated when OS,Node,runtime,baseline changes.
App code delivered via scripts,extensions,VM Applications.
This is best when you deploy code often and want fast iterations without image churn.

Fully baked image (OS and app)

CI pipeline builds app, creates/validates an image (e.g., Packer), then VMSS upgrades to this image. Very fast scale-out, simple runtime, and easy rollback by switching to previous image version.
This is best when you want strict immutability and can afford an image build pipeline per release.
For your daily pushes, 12 apps, no containers scenario, base image + app deployment (extensions/VM Applications) is typically more practical

For deploying of frequent updates to multiple Node.js apps

Build Node.js projects in CI (npm install, npm run build, tests), then publish artifacts (zip/tar with compiled JS and minimal node_modules) to Storage or artifact reposiory.

For VMSS: Always use Custom Script Extension configuration (JSON) that pulls the right artifact version and swaps symlink or folder, then restarts services or define a VM Application version that contains payload + install/update scripts and assign it to the VMSS application Profile. - https://docs.azure.cn/en-us/virtual-machines/extensions/custom-script-linux

Then, reapply extension or update VM Application version when you deploy a new build. VMSS then updates instances according to the upgrade policy - https://docs.azure.cn/en-us/virtual-machine-scale-sets/tutorial-install-apps-cli

For handling different build requirements (12 projects) - Standardize runtimes on the base image and install all required Node.js versions and shared tools (pm2, systemd units, reverse proxy) in the image - https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/

Keep per-project logic in scripts:

One bootstrap script that, for each project, downloads its artifact, applies config, and restarts that project’s service.
Services defined per app (systemd units or pm2 processes) so you don’t restart everything for one change.
Projects that only need “runtime execution” just get their pre-built artifact; projects that need a build step get it done in CI, not on the VM.

Himanshu Shekhar 3,375 Reputation points Microsoft External Staff Moderator

2026-01-29T01:15:27.84+00:00

@Subhash Chand Just checking if provided response was helpful! please let me know if you have any queries.

Share via

Azure → Virtual Machine Scale Sets

Current Setup

Problem Statement

Questions

Current Setup

Problem Statement

Questions

1 answer

Your answer