Dev Drive on Windows 11: set it up, move npm and pip caches

Dev Drive is a ReFS volume in Windows 11 on which Microsoft Defender scans files in performance mode, after they open rather than before, which speeds up installs and builds that touch thousands of small files. You need Windows 11 build 10.0.22621.2338 or later and at least 50 GB free. Create it under Settings > System > Storage > Advanced storage settings > Disks & volumes, then move your repositories and package caches onto it. Windows 10 does not have it.

Why builds on Windows feel slow

An npm install, a dotnet restore or a large git checkout creates and opens thousands of small files. On an NTFS system drive, Microsoft Defender's real-time protection scans each one as it is opened, synchronously, before the tool gets the file back. That per-file cost is one reason the same build often runs slower on Windows than on Linux.

The traditional fix was a folder exclusion, which turns scanning off for the folder entirely. Dev Drive is Microsoft's supported alternative: a separate volume formatted with ReFS, on which Defender runs in "performance mode" instead of skipping files altogether. You keep scanning, and your build stops waiting for it.

What you need

From Microsoft's Dev Drive documentation:

Requirement	Detail
Windows	Windows 11, build 10.0.22621.2338 or later, any edition
Space	At least 50 GB for the volume
Memory	8 GB minimum, 16 GB recommended (ReFS uses slightly more than NTFS)
Rights	Local administrator to create it
Disk	Not removable or hot-pluggable (USB, external drives), not a dynamic disk, and not C:

Windows 10 does not have it. On a Windows 10 22H2 machine (build 19045), the command that reports Dev Drive status does not exist:

C:\> fsutil devdrv query
devdrv is an invalid parameter.

On a work machine, your administrator may also need to enable Dev Drive through Group Policy before the option appears.

Creating one

Open Settings > System > Storage > Advanced storage settings > Disks & volumes and choose Create dev drive. You get three options:

1. Create new VHD: a virtual disk file on an existing drive. Microsoft recommends VHDX, dynamically expanding. It is the easiest to resize, back up or delete later, at a slight cost in speed.
2. Resize an existing volume: shrink a partition to free at least 50 GB, then format that space as a Dev Drive.
3. Unallocated space: use space that is already free on a disk.

A partition is slightly faster; a VHD is more flexible. For most developers the VHD is the right first try, because deleting it later is just detaching and removing a file.

From an elevated prompt, an existing empty volume can also be formatted directly:

format D: /DevDrv /Q

This erases the volume. There is no in-place conversion: Microsoft is explicit that an existing volume cannot be turned into a Dev Drive with its contents intact, and the designation happens only at format time. Replace D: with the letter you actually mean, and check it twice.

Trust and performance mode

A newly created Dev Drive is marked trusted, and a trusted Dev Drive is the signal for Defender to use performance mode on it. Microsoft's performance mode documentation sums up the difference in two phrases: real-time protection is "open now, scan now"; performance mode is "open now, scan later". The scan still happens, just after the file open completes rather than blocking it.

Two conditions must hold for it to apply:

• Defender is your primary antivirus, with real-time protection on. Performance mode is a mode of real-time protection, so switching real-time protection off does not unlock a faster Dev Drive; it removes the protection performance mode was balancing. Third-party antivirus products do not get performance mode at all.
• The drive is trusted.

Check trust from an elevated prompt:

fsutil devdrv query D:

For the system-wide policy, including whether antivirus filters attach and which extra filters are allowed, run it without a drive letter:

fsutil devdrv query

Whether performance mode is actually on for each volume is shown in the Windows Security app, under Virus & threat protection settings > Manage settings > Dev Drive protection > See volumes.

The trap: moving a VHD loses trust

Trust is stored in the registry of the machine that formatted the drive, not on the drive. Attach the same VHD on another computer and it is treated as an ordinary volume, scanned synchronously, until you mark it trusted there with fsutil devdrv trust D:.

Microsoft goes further: the Dev Drive designation, trust and filter policies are all stored per machine, and it does not recommend moving a VHD to another machine and carrying on using it as a Dev Drive. Microsoft advises caution about granting trust after creation, for the obvious reason: you are vouching for whatever is already on it.

Do not strip the antivirus filter

fsutil devdrv enable /disallowAv detaches antivirus filters from every Dev Drive on the machine. Microsoft's own documentation flags it with a bold caution, and it is the folder exclusion problem again at volume scale: files on the drive are no longer scanned at all. Performance mode exists so you do not have to make that trade.

What to put on it

Microsoft's guidance: source repositories, package caches, and build output. Not applications. Visual Studio, the .NET SDK, the Windows SDK and similar tools should stay on C:. Tools installed on C: read and build files on the Dev Drive without any change.

Repositories

Clone new work to the Dev Drive, for example D:\src. For an existing repository, a fresh clone is cleaner than copying the folder, because it leaves behind nothing that was only ever local. Copy across any ignored files you need, such as .env, by hand.

Package caches

By default, every package manager keeps its global download cache on C:, which means every restore still goes through a synchronously scanned volume even when the project is on the Dev Drive. Moving the caches is where most of the benefit lives. Microsoft lists an environment variable for each:

Tool	Variable	Example value	Old location to move
npm	npm_config_cache	D:\packages\npm	%LocalAppData%\npm-cache or %AppData%\npm-cache
pip	PIP_CACHE_DIR	D:\packages\pip	%LocalAppData%\pip\Cache
NuGet	NUGET_PACKAGES	D:\<user>\.nuget\packages	%UserProfile%\.nuget\packages
Cargo	CARGO_HOME	D:\packages\cargo	%UserProfile%\.cargo
Maven	MAVEN_OPTS	-Dmaven.repo.local=D:\packages\maven	%UserProfile%\.m2\repository
Gradle	GRADLE_USER_HOME	D:\packages\gradle	%UserProfile%\.gradle
vcpkg	VCPKG_DEFAULT_BINARY_CACHE	D:\packages\vcpkg	%LocalAppData%\vcpkg\archives or %AppData%\vcpkg\archives

Before changing anything, ask the tools where their caches are now. Both commands only read:

npm config get cache
python -m pip cache dir

On one Windows machine with npm 11, the npm cache was under %LocalAppData%, which is the Windows default npm's config reference gives, not the %AppData% path older guides assume. Check rather than guess.

Then create the folders and set the variables. setx without /M sets them for your user; Microsoft's examples use setx /M, which writes the machine-wide environment and so needs an elevated prompt:

mkdir D:\packages\npm D:\packages\pip
setx npm_config_cache D:\packages\npm
setx PIP_CACHE_DIR D:\packages\pip

For NuGet, Microsoft prefers globalPackagesFolder in a nuget.config over the NUGET_PACKAGES variable, because the variable overrides every repository's own setting.

The trap: nothing changes until you restart the shell

setx writes the variable to the registry, and it is available in future command windows only. The prompt you ran it in, every other open terminal and your editor's integrated terminal keep the old values, so the next npm install still fills the old cache and it looks as though the change did nothing.

Close them all, restart the editor itself (its terminal inherits the editor's environment), open a new terminal, and run npm config get cache again to confirm the new path before you move the old cache's contents across. Microsoft notes that a reboot is sometimes needed.

Moving the old contents is optional: caches regenerate, so letting the next install fill the new folder works too. Point each tool at the new folder with its variable rather than symlinking the old path; if you script it from Git Bash, ln -s copies instead of linking and still exits 0.

What it will not speed up

• WSL. A Linux distribution reading files from a Dev Drive crosses into the Windows file system and gets no benefit. Keep WSL projects inside the WSL file system. ReFS also does not support WSL's metadata mount option, so Linux permissions are not preserved on these files.
• Anything on C:. The system drive cannot be a Dev Drive, and performance mode leaves scanning on every other volume unchanged.
• Defender's own CPU use. If MsMpEng.exe is busy, Microsoft points to Defender's Performance Analyzer rather than to performance mode.