Docker and WSL on Windows

How Docker Desktop uses the Windows Subsystem for Linux, why file location affects performance, and a simple beginner workflow.

Docker Beginner 7 min read
Updated 2026-04-12

The relationship in plain language

On Windows, Linux containers need a Linux kernel to run. Docker Desktop provides that kernel through the Windows Subsystem for Linux version 2 (WSL 2). When you start Docker Desktop, it launches a lightweight Linux environment inside WSL 2 and runs the Docker engine there.

From your Windows terminal or PowerShell, the Docker CLI communicates with that Linux-side engine transparently. You type the same commands as on Linux or macOS.

Why file location matters

WSL 2 has two separate filesystems: the Linux filesystem and the mounted Windows filesystem (accessible under /mnt/c). When Docker reads or writes files from the Windows side (/mnt/c/Users/...), it must cross the boundary between the two filesystems. This translation is noticeably slower for workloads with many small file reads, such as Node.js or Python projects.

The practical rule is simple: store your project files in the WSL Linux filesystem (for example ~/projects inside WSL) and open them from the WSL terminal. Docker performance is then the same as on native Linux.

You can still use VS Code on Windows. With the Remote - WSL extension, VS Code opens files from the Linux filesystem while editing them in the normal Windows window.

A practical beginner workflow

wsl --install                   # install WSL 2 (Windows 10/11, run once)
wsl -l -v                       # list distributions and their WSL version
docker version                  # verify Docker engine is reachable from WSL
docker context ls               # see which Docker context is active

Start Docker Desktop, open a WSL terminal, and run your Docker commands from there. Keep all project files under your WSL home directory. You will avoid the performance issues and the Dockerfile paths will be identical to examples written for Linux.