What Is WSL2? How to Run Linux on Windows

A quiet war runs on the desktop of a lot of IT people. On one side you like Linux, its terminal and the way its tools behave. On the other you need Windows to earn your living, and Windows is not going anywhere.

For years you had two exits. Dual boot, which means rebooting all day, and you hate rebooting. Or a virtual machine, which works but feels heavy and takes resources you would rather spend somewhere else. Then Microsoft shipped WSL and a third door opened.

My thesis, up front: WSL2 hands you real Linux running on a real kernel, wired into Windows tightly enough that you forget there is a Windows underneath. It is, almost certainly, the best developer tool Microsoft has shipped in a decade.

What is WSL (and what it isn’t)

WSL stands for Windows Subsystem for Linux. It is a subsystem that lets you run a full Linux environment straight inside Windows. Terminal, tools, package manager, the whole set. No separate boot, no reboot, no second machine.

Do not picture an emulator. Do not picture a virtual machine you have to open and configure by hand. From where you sit it behaves like one more app: you open a window, you get your shell, you go to work.

The first version arrived in 2016 and it was a small revolution. For the first time you could keep a native Ubuntu terminal on a Windows machine. It had serious gaps, though. It translated system calls instead of running a real kernel, performance was limited and hardware access was thin. It worked. It did not suit everyone.

What WSL is not: a remote shell, a virtual machine you administer, a toy Linux. It is a real Linux system, with its own filesystem, its own kernel and its own package manager, and it also knows how to speak Windows. That two-way conversation is exactly what makes it useful.

What is WSL2 and how it differs from WSL1

WSL2 was announced in 2019, landed in Windows 10 with version 2004 and changed the whole approach. Instead of translating calls, it runs a real Linux kernel inside a very light virtual machine. Two things fall out of that: full compatibility and performance close to native.

	WSL1	WSL2
How it works	Translates system calls	Real Linux kernel in a light VM
Compatibility	Partial	Full (anything that runs on Linux)
I/O performance	Better on Windows files	Better inside Linux itself
Docker, GPU, systemd	Problematic	Supported
Startup	Instant	An instant (it starts the VM)

The rule you can write down once and forget: today, use WSL2. WSL1 survives in a few narrow cases, like working with files stored on the Windows filesystem and needing every last bit of speed across that boundary. Microsoft keeps the full comparison in its official documentation.

Compatibility is the big one. If a tool runs on Linux, it runs here. No shims, no half-supported commands, no guessing which call will break on you today. Speed is the second. A real kernel moves file-heavy work far closer to what you would see on a bare-metal install, which is why builds and containers stop being a gamble.

How WSL2 works under the hood

Short answer: WSL2 runs a real Linux kernel inside a very light virtual machine that starts in an instant. That VM sits on the Windows hypervisor, the same virtualisation base Hyper-V uses, although you do not need to switch on the Hyper-V role to run it.

Three practical consequences are worth keeping in mind:

• Filesystem. Each distribution lives on its own virtual disk in ext4 format. Your Windows files mount at /mnt/c, but they are not inside Linux. You reach them across a bridge.
• Its own kernel. Microsoft ships and maintains that kernel apart from Windows. You update it with wsl --update, with nothing to reinstall.
• Shared resources. The VM does not reserve a fixed block of memory. It takes what it needs and gives it back as the load changes. Throw heavy work at it and it will grab plenty, which you cap from a .wslconfig file in your user folder.

That last point catches anyone coming from a traditional VM. WSL2 does not set aside a fixed slice of your memory. It asks for it when it needs it. Compile something big or spin up a handful of containers and you will watch the vmmem process climb in Task Manager. If your machine is tight on RAM, put a ceiling on it. A .wslconfig file with a [wsl2] section and values for memory, processors or swap tells Windows how much it can pull (the details are in the advanced settings guide).

The bridge between the two filesystems is the piece most people trip over. Windows and Linux keep their files apart on purpose, and crossing from one side to the other costs you time. Once that lands, you stop blaming WSL for a slow build and start putting the code where it belongs.

Requirements for installing WSL2

Before you touch a single switch, line these up:

• Windows 11 or Windows 10 version 2004 or later (build 19041 and above). On older builds you update first.
• Virtualisation enabled in the BIOS/UEFI. This one sinks more installations than anything else. Leave it off and wsl --install warns you or fails outright. If you cannot find the setting, here is how to enter the BIOS or UEFI.
• Administrator rights and a few free gigabytes for the distribution.
• Optional: Windows Terminal for a decent console, and a compatible GPU if you plan to do compute work.

How to install WSL2 step by step

The steps have been simplified a lot. On Windows 11, or an updated Windows 10, this is the whole job:

1. Open PowerShell as administrator and run:

   wsl --install

   That enables the needed components, installs the kernel and pulls Ubuntu by default.

2. Reboot when it asks.
3. Open the distro from the Start menu. The first time it asks for a Linux username and password (these have nothing to do with your Windows account).
4. Check what you have and which version:

   wsl --list --verbose

   There you see the distros and whether they run on version 2.

Want another distribution (Debian, Fedora, Arch)? List what is available with wsl --list --online and install by name with wsl --install -d Debian. If something is stuck on WSL1, move it to version 2 with wsl --set-version followed by the distro name.

Keep four commands within reach. They save you the usual headaches:

• wsl --status: default version and kernel state.
• wsl --update: updates the kernel without touching the distro.
• wsl --set-default-version 2: every new distro is born on WSL2.
• wsl --shutdown: powers the VM all the way down, handy when something gets stuck.

The one requirement you cannot skip is virtualisation enabled in the BIOS/UEFI. If the install complains about the kernel, Microsoft’s official documentation waits at learn.microsoft.com/windows/wsl, and the full command list is in its basic commands reference.

What you can do with WSL2

• Run Docker natively, backed by the Linux kernel. No strange intermediary layers.
• Use systemd, so the distro’s services start up as they would on a normal Linux.
• Use the GPU for compute and AI workloads with CUDA.
• Open Linux GUI apps on the Windows desktop (WSLg), with no manual X server setup.
• Work with VS Code connected straight to the Linux environment, as if it were local.
• Run databases and development services (PostgreSQL, MySQL, Redis, web servers) inside the distro and treat them like they were on a real Linux server.

The flagship case is development. You raise an environment with the same Python, Node or PHP version as production in seconds, without polluting Windows and without fighting with paths. And since the distro is real Linux, the everyday tools (grep, sed, systemd, containers) behave the same way they do on the server.

If your team already runs containers, this is the line between a demo on your laptop and a workflow you can trust.

GPU, AI and Linux apps with a window

WSL2 is not only a console. WSLg lets you open Linux GUI apps (an editor, a browser, GIMP) in Windows windows, with no manual X11 tunnelling. They land on the desktop with their own icon in the taskbar.

For AI and compute, WSL2 can use the machine’s GPU with CUDA and DirectML. Here is the rule people forget: the graphics driver installs on Windows, and Linux inside WSL2 picks the GPU up from there. Microsoft spells it out in its GPU compute guide. It is one reason many machine learning teams work on Windows with WSL2 instead of keeping a separate Linux box around.

Interoperability: Windows and Linux on the same desktop

This is the part that hooks people: the two systems can call each other. From Linux you run a Windows program, from Windows you run a Linux command, almost without thinking about it.

• From the Linux terminal, /mnt/c is your C: drive, and explorer.exe . opens Windows Explorer in the folder you are standing in.
• From Windows you invoke anything with wsl. Run wsl ls -al and you are running ls inside the distro.
• Tools like code . open VS Code connected to the Linux environment with no extra setup.

The classic warning, and it matters: do not run large projects stored on the Windows drive. The bridge between the two filesystems adds latency, and compiling thousands of small files from /mnt/c hurts. Keep your code inside the Linux filesystem and leave /mnt/c for what truly lives on Windows. It is Microsoft’s own advice in its filesystem guide.

WSL2 networking: its own IP, NAT and localhost

WSL2 does not share the Windows network as it is. The virtual machine brings up its own interface and its own IP addresses, behind a NAT. In practice the distro can be a client (browse, clone repos, call APIs) with no trouble at all. If you want something outside to reach a service inside Linux, you open the path yourself: port forwarding, firewall rules or mirrored networking mode.

Day to day you barely notice. On recent versions localhost works in both directions, so a dev server running on port 3000 inside WSL2 opens as localhost:3000 in the Windows browser. If you need full control (IPv6, VPNs, complex networks), there is mirrored networking mode, which replicates the Windows interfaces inside WSL2. The details shift with the version, so read the WSL networking documentation before you start editing adapters.

And if the port is fine but the network still feels flaky, the diagnosis never changes: measure before you touch. A service that comes in fits and starts is usually a stability problem. Bandwidth rarely has anything to do with it.

If you have ever hand-mapped ports just to open a dev server in your browser, you know how much setup that used to cost. Here it is one line of configuration, or none at all.

WSL2 limitations

WSL2 is excellent. It is not magic. These are the limits worth knowing before you move your whole workflow across:

• It is not a production environment. It is built for the developer’s desktop. To serve traffic, native Linux or a well-managed VM is still the sensible call.
• It consumes resources. The VM grows with the load, and on low-memory laptops you feel it. .wslconfig helps. It does not work miracles.
• Cross-filesystem access is slow. Moving or compiling large volumes between Windows and Linux costs you. Keep each thing in its own filesystem.
• It is not a full desktop. Even though WSLg opens GUI apps, do not expect a session manager, system themes or a distro desktop as such.
• It depends on versions. Features like systemd, WSLg or mirrored networking arrived in specific versions of WSL and Windows. On older machines, the experience changes.

WSL2, a virtual machine or dual boot

“It depends” is the honest answer. It can also be made concrete:

• WSL2 if you need Linux every day without giving up Windows: development, containers, the command line, network tools. The best balance of the three.
• A virtual machine if you need a full Linux desktop, another guest operating system or strong isolation between environments.
• Dual boot if you need the absolute performance of the hardware, with no layers in between, for gaming or very heavy workloads.

Pick the lightest tool that clears the job. Most people who move to WSL2 never go back to the other two.

Frequently asked questions

Is WSL2 a virtual machine?

Inside, yes. It uses a very light virtual machine with a real Linux kernel. The difference is the integration. It is wired into Windows so tightly that it behaves like one more app, without you having to manage it like a traditional VM.

Is WSL2 free?

Yes. WSL ships with Windows and the distributions download free from the store or from the command line. No extra licence.

What is the difference between WSL1 and WSL2?

WSL1 translated system calls and offered partial compatibility. WSL2 runs a real Linux kernel, with full compatibility and better support for Docker, GPU and systemd. Outside a few specific cases, use WSL2.

Can I use WSL2 in production?

For development, yes, and it is common. For production servers, native Linux is the sensible choice. WSL2 is designed as a desktop working environment. It was never meant to carry production traffic.

How do I access Windows files from WSL2?

Your drives mount under /mnt/. For example, /mnt/c is the C: drive. You can read, copy and run from there, but for large projects keep the code inside the Linux filesystem and leave /mnt/c for what lives on Windows.

How much memory does WSL2 use, and how do I cap it?

By default usage is dynamic. The VM takes memory as it needs it and can end up using a good part of what you have. You cap it with a .wslconfig file in your user folder and a [wsl2] section (for example, memory=8GB), applied on restart with wsl --shutdown.

The bottom line

WSL2 solved a problem a lot of us carried for years: having to pick between Windows and Linux. It is not perfect. The VM adds a layer and performance with Windows files can sting. Even so, it is the most convenient deal on the table today for anyone who lives in both worlds.

Where does all this come from? Here is the history of operating systems, and to understand the other side, what Solaris was, the Unix that ruled before Linux ate the world.

So open PowerShell this afternoon and run the one command. Ten minutes from now you will know whether WSL2 fits the way you work, and that is a cheap test with a large payoff.