WSL2 is good enough to run a real Linux dev environment on Windows — as long as your files live inside the Linux filesystem, not on /mnt/c. Get that one thing wrong and everything about WSL2 feels slow and half-broken.

Install

wsl --install

One command, from an elevated PowerShell or Command Prompt, on any reasonably current Windows 10/11 install. It installs WSL2, a Linux kernel, and Ubuntu by default. Reboot when it asks.

Pick a specific distro instead of the default:

wsl --install -d Ubuntu-22.04
wsl --list --online     # see what's available

The single most important rule: don’t work on /mnt/c

Windows drives are mounted inside WSL at /mnt/c/, /mnt/d/, and so on. You can cd into /mnt/c/Users/you/projects and work there — and it will be dramatically slower, because every file access crosses the Windows/Linux filesystem boundary, which is not free.

# slow — crosses the 9P filesystem boundary on every read/write
cd /mnt/c/Users/you/projects/myapp
npm install    # can take minutes instead of seconds

# fast — native ext4, inside the WSL2 VM
cd ~/projects/myapp
npm install

Clone your repos into the Linux home directory (~), not onto a Windows path. This one change is responsible for most “WSL2 is slow” complaints.

Port forwarding just works — mostly

A server running inside WSL2 on localhost:3000 is reachable from localhost:3000 in your Windows browser automatically, no config needed, in current WSL2 versions. If it stops working after a Windows update, check:

wsl --shutdown

then restart your terminal. WSL2 runs a lightweight VM, and a stale VM state after sleep/wake or an update is the usual cause of “it was working yesterday.”

File system access from the Windows side

\\wsl$\Ubuntu-22.04\home\you\projects

Type that into Windows Explorer’s address bar to browse your Linux files from Windows — useful for dragging a file in, or opening something in a Windows-only GUI tool. Don’t make this your primary workflow; it’s for occasional access, not daily editing.

VS Code integration

Install the WSL extension, then from inside your WSL terminal:

cd ~/projects/myapp
code .

This opens VS Code running its server inside WSL2 — same model as Remote-SSH, but to your own machine’s Linux subsystem instead of a remote server. Extensions that need to run against your actual project files (linters, language servers) install into the WSL side automatically the first time.

Docker: use WSL2 as the backend, not Hyper-V

In Docker Desktop settings: Settings → General → Use the WSL 2 based engine, and under Resources → WSL Integration, enable your distro explicitly. Docker Desktop’s WSL2 backend is faster and uses less memory than the older Hyper-V backend, but it’s opt-in in older installs — check it’s actually on if builds feel sluggish.

Memory: WSL2 will use more RAM than you expect, by default

WSL2 runs as a real VM and can grow to consume most of your system RAM under sustained load, without giving it back promptly. Cap it in .wslconfig:

# C:\Users\<you>\.wslconfig
[wsl2]
memory=8GB
processors=4

Restart WSL (wsl --shutdown, then reopen a terminal) for this to take effect. Without a cap, a memory-heavy build can make the whole Windows machine feel sluggish, not just the WSL session.

The setup that actually works

Clone into ~, run Docker through the WSL2 backend, edit through VS Code’s WSL extension, and treat /mnt/c as read-only convenience for the occasional file, never as your working directory. Follow that and WSL2 performs close to a real Linux box — treat it like a slow shared drive and it will behave like one.