Quick fix: Dev Drive uses ReFS and requires Windows 11 22H2 or later. Shrink the C: drive in Disk Management to free space, then use Settings → System → For developers → Dev Drive to create a new Dev Drive on the unallocated space. Allocate at least 50 GB; ideal size is 100–200 GB depending on workload.

Dev Drive is Windows 11’s ReFS-based volume optimized for developer workloads — it disables Defender real-time scanning on dev folders, uses copy-on-write semantics for fast clones, and provides better I/O for source code repositories and build artifacts. The catch is provisioning: you need either unallocated space, a separate drive, or a virtual disk file. The first time setting it up isn’t obvious.

Symptom: You want to create a Dev Drive on Windows 11 for faster developer workflows.
Affects: Windows 11 22H2 or later, Pro/Home/Enterprise.
Fix time: 30 minutes.

Why Dev Drive matters and what makes it different

Dev Drive trades some general-purpose features (no compression like NTFS, less Windows-feature compatibility) for build performance: faster file operations on large directory trees, copy-on-write for clones, and an opt-out of Defender real-time scanning per-directory. For a typical Node/Python/Go/.NET project with thousands of small files, Dev Drive can cut build times 20–40% compared to an NTFS volume on the same SSD.

The volume must use ReFS, must be at least 50 GB, and must be created via the Settings flow (not just formatted ReFS through Disk Management). The Settings flow sets the Defender opt-out flag and other developer-specific defaults.

Method 1: Shrink C: and create a Dev Drive on unallocated space

Back up important data on C: as a precaution.
Open Disk Management (diskmgmt.msc).
Right-click your C: volume and choose Shrink Volume.
In the Enter the amount of space to shrink in MB field, enter at least 102400 (100 GB). Larger if your code archives are bigger.
Click Shrink. Wait for the operation. C: is now smaller; you have unallocated space.
Open Settings → System → For developers → Dev Drive.
Click Create new Dev Drive.
Choose Create new VHD if you prefer a virtual disk (smaller footprint, easy to remove later) or Resize existing volume if you want to use the unallocated space.
If using unallocated space, the wizard formats it as ReFS with Dev Drive optimizations.
Assign a drive letter (commonly D: or W: for “work”).
Complete the wizard. Drive is ready for use.

The drive appears in File Explorer as a normal volume. Behind the scenes, it has the Dev Drive flag set.

Method 2: Create a Dev Drive as a VHD instead of resizing

For cases where you can’t shrink C: easily, use a virtual disk file.

In Settings → For developers → Dev Drive, click Create new Dev Drive.
Choose Create new VHD.
Enter size (e.g., 100 GB) and the VHD file location. Pick a fast SSD for the underlying file.
Set the VHD type to Dynamically expanding — this allocates only what’s used, growing as needed.
Wait for the wizard to format the VHD with ReFS and Dev Drive flags.
The VHD mounts as a drive letter automatically. Use as normal.
To detach later: right-click the drive in This PC → Eject, or in Disk Management.

VHD-based Dev Drives are portable — copy the .vhdx file to another PC and attach there. Slight performance overhead compared to a native partition but minor.

Method 3: Move existing dev folders to the Dev Drive

Once you have a Dev Drive, move dev work to it for the speed benefit.

Plan a directory structure on the new drive (e.g., D:\dev\projects, D:\dev\packages).
For each project: close all editors and tools using it, then move the folder using File Explorer or robocopy to preserve permissions.
Update tool configurations: VS Code workspaces, Git repos with new paths, package managers (npm cache, pip cache).
For Node.js, set the global npm cache to the Dev Drive: npm config set cache D:\dev\npm-cache --global.
For Python: pip config set global.cache-dir D:\dev\pip-cache.
For dotnet: dotnet nuget locals all --clear; mklink /D “%UserProfile%\.nuget\packages” “D:\dev\nuget-packages”.
Run a build. Compare elapsed time to before.

Most developers see noticeable improvement on Node.js / front-end projects with many small files. For monolithic C++ projects with few large files, the benefit is smaller.

How to verify the fix worked

Open Settings → System → For developers → Dev Drive. Your drive is listed with size and free space.
Open File Explorer → This PC. Right-click the drive and choose Properties. File system reads ReFS.
Run fsutil fsinfo refsinfo D: — reports ReFS version and Dev Drive flag.
Build a known-slow project on the Dev Drive vs C:. Build time on Dev Drive is faster.

If none of these work

If Dev Drive doesn’t appear in Settings, you’re on a Windows 11 build that doesn’t support it — update to 22H2 or later. For Home edition where the option is present but creation fails, ensure the optional ReFS feature is installed (see “ReFS Drives Show as RAW” article for the feature installer). For users with TPM-bound BitLocker on the system drive, shrinking C: may temporarily disable BitLocker; ensure you have the recovery key before resizing. For older laptops with limited SSDs, consider using a portable SSD as the Dev Drive instead of shrinking the internal one — performance is still good and you keep the OS drive intact.

Bottom line: Dev Drive is a one-time setup that pays back on every build. Shrink C: or create a VHD, then provision via Settings to get the Defender opt-out and ReFS optimizations. Move package caches and project folders for the full speed benefit.