Running Linux on Windows 11 With WSL

WSL (Windows Subsystem for Linux) lets you run Linux natively within Windows 11 — not in a virtual machine with overhead and complex configuration, but as an integrated environment where Linux terminals, Linux tools, and Linux file systems run alongside Windows applications. For developers, data scientists, sysadmins, and anyone who needs Linux tooling on a Windows machine: it removes the “dual boot or VM” dilemma entirely. This fits into the wider topic we cover in our Complete Guide to Windows 11.

WSL2 (the current version) runs a genuine Linux kernel in a lightweight virtual machine managed by Windows. The result: near-native Linux performance for most workloads, full system call compatibility, and seamless integration with the Windows filesystem.

Installing WSL

The simplest installation: Admin Command Prompt or PowerShell → wsl --install → press Enter. This installs WSL2 with Ubuntu as the default distribution, enables the required Windows features, and restarts the machine. After restart: Ubuntu opens automatically to complete initial setup (create a Linux username and password).

That’s the complete basic installation. The username and password you create are for the Linux environment specifically — separate from your Windows account. They’re used for sudo (administrator commands in Linux) and for Linux authentication.

Choosing a Linux distribution

Ubuntu is the default and the most widely-used for WSL, with the broadest community support and package availability. But WSL supports multiple distributions, installable alongside each other:

• wsl --install -d Ubuntu (Ubuntu, most common)
• wsl --install -d Debian (more minimal than Ubuntu)
• wsl --install -d kali-linux (Kali Linux for security work)
• wsl --install -d openSUSE-42
• wsl --install -d Fedora-Remix-for-WSL

wsl --list --online shows all available distributions. You can run multiple distributions simultaneously — switch between them by specifying the distribution name when opening a shell.

Using WSL — the daily workflow

Open a Linux terminal: Windows Terminal → click the dropdown arrow in the title bar → your distribution name appears as an option. Or: Win+R → wsl → opens the default distribution. The terminal is a full bash (or zsh, etc.) shell with access to all Linux commands.

Inside the WSL terminal: use Linux as you would on a native Linux machine. sudo apt update && sudo apt upgrade to update packages. Install development tools with apt. Run Python scripts, Node.js applications, shell scripts, databases, or any Linux-native software.

Accessing Windows files from Linux: the Windows drives are mounted at /mnt/c/, /mnt/d/, etc. Navigate to Windows Documents: cd /mnt/c/Users/YourUsername/Documents. Linux commands (grep, sed, awk, find, etc.) can process Windows files at these paths.

Accessing Linux files from Windows: File Explorer → navigation pane → “Linux” → your distribution’s name → the Linux filesystem. Drag and drop files between Windows and Linux. Edit Linux files in Windows apps (VS Code, etc.) and they update immediately in the Linux environment.

VS Code and WSL integration

Visual Studio Code has native WSL support via the “Remote – WSL” extension (or the WSL extension in newer VS Code versions). In the WSL terminal: navigate to a project directory → type code . → VS Code opens in Windows with the project files loaded from the Linux filesystem. The VS Code terminal runs inside WSL; extensions that need Linux tools (Python, Node.js, Docker) run in the Linux environment rather than Windows.

This setup is the primary reason WSL has become essential for web development: running a Linux development environment (exact match to most production servers) while using Windows GUI tools (VS Code, browsers, design applications). No VM, no performance overhead, no file synchronisation complexity.

Our guide on Windows 11 virtualization settings covers Hyper-V and virtualization settings that WSL2 depends on, and our guide on Task Manager covers monitoring WSL’s resource usage as a Windows process. For comprehensive WSL documentation including network configuration, systemd support, and GPU compute access, Microsoft’s WSL documentation covers the full feature set and advanced configuration options.

Docker with WSL

Docker Desktop on Windows uses WSL2 as its backend — the Docker engine runs inside WSL, providing near-native Linux container performance without a full VM. Install Docker Desktop → it automatically configures WSL2 integration. Containers run in the WSL environment; Docker commands work from both Windows (PowerShell) and Linux (WSL terminal) contexts.

The WSL integration for Docker is more efficient than the Hyper-V backend Docker Desktop used previously. Container startup is faster, resource usage is lower, and the integration between containers and the WSL filesystem is smoother. If Docker Desktop is configured for Hyper-V backend: Settings → Resources → WSL Integration → switch to WSL2 backend for better performance.

GPU compute in WSL

WSL2 supports GPU access for compute workloads — CUDA for NVIDIA GPUs, ROCm for AMD, and DirectML for cross-vendor compute. This means ML/AI training workloads, video encoding using GPU compute, and other GPU-accelerated Linux tools run in WSL without needing a separate Linux machine.

Setup for NVIDIA CUDA: install the CUDA toolkit inside WSL (sudo apt install nvidia-cuda-toolkit) after installing NVIDIA drivers on the Windows side. The drivers are the Windows drivers — no separate Linux GPU driver installation is needed in WSL. The GPU is available to both Windows and WSL workloads simultaneously.

Common WSL commands

WSL resource limits

WSL2 uses a lightweight VM that by default can use up to 50% of total system RAM and all processor cores. On machines with 32GB+ RAM, WSL might consume up to 16GB if a demanding workload runs inside it. Configure limits by creating a .wslconfig file in %userprofile%:

[wsl2]
memory=8GB
processors=4
swap=4GB

Save the file → wsl --shutdown → restart WSL. These limits prevent WSL from consuming all available memory during demanding ML training or compilation workloads, leaving resources for other Windows applications running simultaneously.

WSL is one of the most impactful features in Windows 11 for technical users. The ability to run Linux tools, containers, and development environments natively alongside Windows without VMs or dual boot fundamentally changes what a Windows machine can do. For developers who previously maintained separate Linux machines or complex VM setups: WSL often provides what they actually needed from those configurations, with considerably less overhead.

Systemd in WSL

Recent WSL versions include systemd support — the service manager used by most modern Linux distributions. With systemd enabled, services like nginx, Apache, PostgreSQL, Redis, and others start automatically and run as system services, just as they do on a native Linux server. This makes WSL significantly more useful for running server-like environments locally.

Enable systemd: open the WSL distribution → edit /etc/wsl.conf:

[boot]
systemd=true

Save → wsl --shutdown → restart WSL. Now systemctl start nginx and similar commands work. Services started with systemctl persist through WSL session restarts (though not through Windows reboots unless WSL is configured to start automatically).

WSL networking

WSL2 has its own virtual network interface with a dynamic IP address that changes between WSL sessions. Applications in WSL are accessible from Windows via localhost for most cases — a web server running on port 3000 in WSL is accessible at localhost:3000 in the Windows browser. This works due to WSL’s automatic port forwarding from its virtual network to localhost.

For accessing WSL from other devices on the same network: the WSL IP address is needed (run hostname -I inside WSL). On Windows 11 22H2 and later: WSL2 supports a mirrored networking mode that gives WSL the same IP as the Windows host, simplifying cross-device access. Enable: .wslconfig → [wsl2] → add networkingMode=mirrored.

WSL for data science and Python

Python on WSL provides the Linux-native Python environment many data science tools (PyTorch, TensorFlow, certain Jupyter configurations) run most reliably on. Running Python workflows in WSL avoids the “works on Linux, breaks on Windows” issues that some packages have — particularly those with compiled C extensions or Linux-specific dependencies.

Jupyter notebooks in WSL are accessible in the Windows browser: start jupyter lab or jupyter notebook in WSL → the URL output includes localhost:8888 (or similar) → paste into any Windows browser → Jupyter runs in Linux with full access to Linux-native packages while displaying in the Windows browser.

Backing up and moving WSL distributions

WSL distributions can be exported and imported — useful for backing up a configured environment or moving it to another machine. Export: wsl --export Ubuntu ubuntu-backup.tar → creates an archive of the entire distribution. Import to the same or different machine: wsl --import Ubuntu C:WSLUbuntu ubuntu-backup.tar.

This also allows creating multiple copies of the same base distribution with different configurations — useful for isolating different projects or testing different tool versions without conflicting. Export a known-good base Ubuntu setup → import as “Ubuntu-Python311” for a Python 3.11 project and “Ubuntu-Python312” for a 3.12 project. Each runs independently with no version conflicts.

WSL represents a genuine convergence of Linux and Windows development environments that was implausible even five years ago. The ability to run Docker containers, GPU compute workloads, systemd services, and standard Linux CLI tools directly on Windows — with full filesystem integration, VS Code support, and near-native performance — covers the most common reasons developers maintained separate Linux machines. For the Windows-primary developer: WSL makes the question “should I switch to Linux?” far less pressing than it used to be, because the tools that drove that question now run inside Windows.

WSL and Windows Terminal integration

Windows Terminal (the modern terminal application in Windows 11) integrates WSL natively. Each installed WSL distribution appears as a profile in Windows Terminal’s tab dropdown. Customise appearance per profile: Windows Terminal Settings → each distribution → font, colour scheme, starting directory, and other appearance settings independently.

The starting directory for a WSL profile defaults to the Windows user home (/mnt/c/Users/…). For most development work: change it to ~ (the Linux home directory) in profile settings. Projects stored in the Linux filesystem rather than /mnt/c/ have significantly better I/O performance — file operations in the native Linux filesystem are considerably faster than across the WSL filesystem bridge to Windows drives.

Performance considerations

WSL2 I/O performance for files differs significantly based on where files are stored:

• Linux filesystem (/home/…, inside WSL): native-speed Linux I/O — fast, comparable to a native Linux machine
• Windows filesystem (/mnt/c/, /mnt/d/): slower — accessing Windows files from Linux goes through a filesystem bridge that adds overhead

For performance-sensitive development: keep project files in the Linux filesystem (~/ or /home/…) and access them in VS Code via the Remote WSL extension. Windows files at /mnt/c/ are accessible but slower — use this path for reading configuration files or accessing documents, not for storing Git repositories or compiled code. This distinction in file location makes a noticeable difference for large repositories with many small files (node_modules, .git directories).

WSL is the most developer-focused feature in Windows 11 and probably the one with the highest practical impact for technical users. Whether you’re running Python scripts, managing containers, developing web applications, or just want access to Linux command-line tools without leaving Windows: WSL provides all of it without additional hardware, without OS reinstallation, and with less overhead than a VM. The wsl --install command is the starting point; the depth of what’s possible from there extends as far as Linux itself does.

Getting started quickly — first 15 minutes with WSL

For someone who just installed WSL and wants to get useful work done immediately:

1. Update the package list and installed packages: sudo apt update && sudo apt upgrade -y
2. Install common development tools in one command: sudo apt install build-essential git curl wget -y
3. Install a specific language runtime — Python 3: sudo apt install python3 python3-pip -y
4. Verify Git configuration: git config --global user.name "Your Name" and git config --global user.email "[email protected]"
5. Install the VS Code WSL extension → open any project with code .

This 5-step setup gives you a functional development environment with build tools, Git, Python, and VS Code integration in about 5 minutes. From here: install language-specific tools (nvm for Node.js, pyenv for Python version management, Rust via rustup) as needed for specific projects. WSL starts small and adds tools incrementally as projects demand them — the same way a Linux developer would configure a new machine. Our guide on Windows 11 Hyper-V covers an adjacent issue.