Behavior of _del_node_modules

This post will touch on the directory “_del_node_modules”

Overview

In some App Service Logs, with a App Service Linux - Node.js “Blessed” image (not a custom image, eg. Web App for Containers), you may see a reference to a directory named _del_node_modules.

This directory is created on startup through logic defined in the Node.js Blessed Image’s container entrypoint and startup behavior. You can see the logic invoked to create it if App Service Logs are enabled, and if you look in default_docker.log.

2026-01-30T21:06:43.8273864Z export NODE_PATH="/node_modules":$NODE_PATH
2026-01-30T21:06:43.8273897Z export PATH=/node_modules/.bin:$PATH
2026-01-30T21:06:43.8273929Z if [ -d node_modules ]; then
2026-01-30T21:06:43.8273962Z     mv -f node_modules _del_node_modules || true
2026-01-30T21:06:43.8273993Z fi
2026-01-30T21:06:43.8274023Z 
2026-01-30T21:06:43.8274065Z if [ -d /node_modules ]; then
2026-01-30T21:06:43.8274098Z     ln -sfn /node_modules ./node_modules 
2026-01-30T21:06:43.8274130Z fi
2026-01-30T21:06:43.8274162Z 
2026-01-30T21:06:43.8274192Z echo "Done."
2026-01-30T21:06:43.8274224Z node server.js

Call outs about this directory

• It is essentially transparent. During deployments, or, mostly any node_modules related aspects, this should not be touched or worried about. This doesn’t directly affect the application.
• This directory has the same package versions as the ones referenced in your package.json and also the node_modules being used by your application. In some cases, if you have a cloud security scanner, it may flag _del_node_modules as having outdated versions.
  • You can SSH into the application container and look at the package.json for your packages in either /node_modules, /home/site/wwwroot/node_modules, or _del_node_modules and cross compare these
  • If there is a scenario where _del_node_modules is being flagged as having an older version of packages. Delete the directory, restart, and then redeploy. However, you should ensure the applications package.json (or package-lock.json, yarn.lock) should NOT be the one to contain the package version causing this to be flagged in the first place.
    • Testing with build automation enabled (Oryx) and without (which nowadays most sites will use the same node_module compression logic that Oryx uses as called out in Improved Node.js Deployment Performance on Azure App Service) shows that _del_node_modules and node_modules will have mirroring package versions

The only directory, in most cases, that you should share about, is the ones described in here: Improved Node.js Deployment Performance on Azure App Service.