I am Lino
March 26, 2026

WSL: how to get Linux inside Windows without too much drama

Posted on March 26, 2026  •  13 minutes  • 2559 words
Table of contents

There are two types of Windows developers: those who’ve already screamed “why does this work differently on my laptop than on the Linux server?”… and those who don’t know it yet, but they’ll get there.

Windows as a desktop OS is reasonably comfortable: drivers that half-install themselves, games that work (until they crash), Office (sorry, they call it Copitot 365 now), and the resource-devouring horror that is Teams.

As a serious development environment for modern stuff (Docker, Linux tooling, weird scripts, DevOps)… it’s like trying to do surgery with a butter knife. Technically possible, but you will be cursing up a storm.

Odds are, every tutorial you read assumes apt-get, bash, and Linux paths; meanwhile you’re on Windows, wrestling with PowerShell, Git Bash, paths with spaces, and binaries that “almost” work the same way… until they don’t. Then Docker shows up, and suddenly vmmem is eating 16 GB of RAM, the fan sounds like a jet engine, and you start browsing laptops with Ubuntu pre-installed.

That’s where WSL (Windows Subsystem for Linux) comes in: the smartest thing Microsoft has done in the last 40 years — shipping a “real” operating system (Linux) inside Windows, with no dual boot, no heavy VMs, and reasonable integration. WSL2 brings its own Linux kernel and behaves, for pretty much everything that matters to us as developers, like a normal Linux box… with the Windows desktop lurking in the background.

One piece at a time, here’s what I’ll walk you through:

  1. How to install WSL2 without too much pain.
  2. How to turn it into your “real Linux.”
  3. How not to shoot yourself in the foot with shared directories.
  4. How to tame resources, configuration, and sudo.
  5. A handful of WSL commands worth keeping in your back pocket.

1. Installing WSL: from “what is this thing” to “how did I live without it”

On Windows 11 and recent Windows 10, installing WSL stopped being an arcane ritual. Microsoft, in a rare moment of sanity, boiled it down to a single command .

  1. Open Windows Terminal / PowerShell as administrator (right-click Start → “Windows Terminal (Admin)”).
  2. Run:
wsl --install

This command enables the required features, installs WSL, and downloads and installs Ubuntu as the default Linux distribution. 3. Restart when prompted. When you’re back, an Ubuntu window will open asking you to create a Linux username and password. That will be your internal user inside WSL.

If you want a different distro (Debian, Fedora, etc.), first check the list, then install whichever you like:

wsl --list --online      # see available distributions
wsl --install -d Debian  # example

And if it somehow installed as WSL1 and you want WSL2 — which can happen if your Windows isn’t reasonably up to date — Microsoft’s own docs point you to:

wsl --set-version Ubuntu 2

with the name of whichever distro you’re using.

From here, you’ve got a live Linux running inside Windows.

Now let’s make it actually useful.

2. Turning WSL into your main Linux (without quitting Windows)

The first time you see the Ubuntu prompt, do the classic:

sudo apt update && sudo apt upgrade

You’re in real Linux. Install Git, Node, Python, Go, PostgreSQL, Redis, Ansible — whatever you need. The whole point is that many modern tools (Docker, kubectl, Terraform, etc.) work better — or flat-out only exist — on Linux. WSL2 gets you that without giving up your Windows perks — including, of course, the excess memory consumption.

One of the most comfortable setups today is VS Code + Remote - WSL:

In practice, your code lives in Linux, runs in Linux, but you edit it with the same comfortable UI. It’s the recommended workflow in many WSL development guides .

If you use Docker Desktop, the official docs are blunt about it: keep your code in the WSL filesystem and run Docker from there; it’ll save you a lot of performance headaches .

Think of WSL as your local Linux server: that’s where your code, your dev stack, and your services (databases, queues, etc.) live. Windows keeps what it’s good at: desktop, browser, GUI apps, gaming, and the Blue Screen of Death.

3. Shared directories: the love-hate relationship between /home and /mnt/c

Inside WSL, two worlds coexist — and they sometimes clash:

From WSL, you can run:

cd /mnt/c/Users/YourUser/...

and browse anything on C:\. From Windows, you can open File Explorer and go to:

\\wsl$\Ubuntu\home\youruser

and navigate your Linux home like a network share.

Sounds great. Until you start doing heavy I/O operations on /mnt/c from inside WSL2.

3.1. The golden rule: keep your code in Linux

For once, Microsoft and the community (that’s us) actually agree on something:

keep your projects and your code inside the WSL Linux filesystem, not in /mnt/c.

The reason: in WSL2, Linux access to C:\ goes through a sharing layer that’s significantly slower than native access to the Linux virtual disk. There are issues and benchmarks to prove it: operations in /home/user/project are reasonably fast; the same operations in /mnt/c/Users/... can be several times slower .

Docker, for instance, explicitly recommends this approach:

Conversely, things that are purely “Windows” — Office documents, photos, random downloads, viruses — make sense to leave in C:\ and forget about them inside WSL.

3.2. Common problems and how to avoid them

The classic symptoms of abusing /mnt/c include things like endless build times on large projects because disk access is crawling (we’re looking at you, node_modules), or a vmmem process eating up your RAM after heavy operations — especially when lots of reads/writes are crossing the Windows/WSL boundary. And one of the most painful bugs as of this writing: those mysterious line ending issues (CRLF vs LF) and broken file permissions when Git is configured differently on Windows and in WSL.

The fix for minimizing — not eliminating — these headaches is straightforward: keep your code and serious tooling inside the distro (e.g., /home/youruser/dev), let Windows handle its own business, and fall back to \\wsl$ only when you absolutely need it.

Do that and you’ve already dodged 80% of the performance horror stories.

4. Taming resources, fine-tuning, and sudo

Up to here, WSL “works.” Now let’s tighten things up so it doesn’t chew through your system resources, blow up your PATH, or ask for your password every 30 seconds.

4.1. Capping WSL resource usage (RAM, CPU, swap)

By default, WSL2 is pretty generous with resources: it tries to use what it needs and give memory back when it can… but sometimes that means vmmem goes haywire and takes forever to come back down.

Microsoft documents an official way to control this: the .wslconfig file in your Windows user directory.

From Windows (not from WSL), create or edit:

C:\Users\<YourUser>\.wslconfig

For example:

# These options apply to all WSL 2 distributions
[wsl2]
# Cap the VM memory at 4 GB (you can use GB or MB)
memory=4GB

# Use two virtual processors
processors=2

# Set 8 GB of swap (default is 25% of RAM)
swap=8GB

# Path to the swap file (default is %USERPROFILE%\AppData\Local\Temp\swap.vhdx)
swapfile=C:\\temp\\wsl-swap.vhdx

Save the file, then shut down WSL so it picks up the changes:

wsl --shutdown

Next time you start your distro, WSL2 will respect those limits. It’s a great way to stop your laptop from spinning up like it’s about to take off every time you spin up a couple of containers.

4.2. Configuring the distro from the inside: /etc/wsl.conf

In addition to .wslconfig (which affects the “engine” globally), each Linux distro can have its own WSL configuration in /etc/wsl.conf.

From inside WSL, open or create the file:

sudo nano /etc/wsl.conf

For example, you might put something like this:

[interop]
# Prevents WSL from automatically appending the Windows PATH to the Linux PATH.
# Useful if you don't want a thousand Windows paths mixed in with your Linux binaries.
appendWindowsPath = false

[user]
# Default user when the distro starts
default = YourLinuxUser

[boot]
# Command to run when a new WSL instance starts.
# In this example, it starts the Docker service inside the distro.
command = service docker start

The [interop] section controls how Windows things (executables, PATH) integrate into WSL. With appendWindowsPath = false, your PATH will be “purer” Linux, with less noise from Windows paths. It’s the most impactful setting for keeping Windows junk out of your Linux environment.

The [user] section saves you from surprises if you ever switch users: it guarantees the right one starts every time.

And the [boot] section lets you launch services automatically when WSL starts — handy if you want Docker, sshd, or anything else to come up without having to remember to start it manually.

After editing, again:

wsl --shutdown

So that on next startup, WSL reads the new wsl.conf.

4.3. Using sudo without typing your password every two minutes

By default, your Linux user in WSL is usually a member of the sudo group, but it’ll ask for a password when you run sudo something. Some people like it that way; others, in development environments, would rather skip the typing.

If you want sudo group members to run any command without a password prompt, you need to tweak the sudoers configuration.

From inside the distro:

sudo visudo

This opens the sudo configuration file safely (with syntax checking). Find the line that usually reads:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

And change it to:

# Allow members of group sudo to execute any command without a password
%sudo   ALL=(ALL:ALL) NOPASSWD: ALL

Save and exit (in visudo with nano, that’s Ctrl+O, Enter, Ctrl+X).

Then shut down and restart WSL to be safe:

wsl --shutdown

From then on, any user in the sudo group can use sudo without being asked for a password.

In a production environment this has serious implications; in your local dev setup, it saves you from repetitive strain injury and the general irritation of typing your password over and over.

5. Four wsl commands that save you more often than you’d think

Even if you normally get into WSL through the Ubuntu icon or VS Code, it’s worth knowing the wsl command in Windows. Microsoft has been expanding it quite a bit.

Here are the ones worth knowing:

wsl --shutdown

The equivalent of “reboot the server” when something’s gone sideways.

wsl -l -v

You’ll see something like: Ubuntu Stopped 2 → Ubuntu distro, stopped, WSL version 2.

wsl -d Ubuntu
wsl -d Debian

Handy if you’ve installed several and don’t want to open the default.

wsl -e bash -lc "ls -la"

or simply:

wsl ls

This is gold for Windows automation scripts that need to call into Linux tools.

With these four, WSL stops being “that thing that opens by itself when I launch Ubuntu” and becomes a service you actually control: you shut it down, spin it up, cap it, update it… just like you would any serious environment.

Epilogue: Windows for suffering, WSL for everything else

Windows can still be your daily driver — a lot of the time you don’t have a choice, especially in old-school corporate environments — but it doesn’t have to be where you do your real development work.

With WSL2, you can treat the subsystem as your private Linux server inside your laptop, using the same shell, paths, and commands as in production, the same family of tools your CI/CD pipelines use, and the same way to install and start services as on your real servers.

Does it have its quirks? Of course: the /mnt/c situation, the RAM consumption if you don’t cap it, the occasional bug.

But with a reasonable .wslconfig, a dialed-in /etc/wsl.conf, code living in /home, and four wsl commands in your head, you go from “Windows is driving me insane” to “I can finally get something done.”

And that, technically speaking, is what we call a genuine quality-of-life upgrade.

Quick glossary

Quick definitions for those who skipped three paragraphs and are now completely lost.

Sources and references

Like any good WSL tutorial: official docs, Reddit threads with 40 replies, and a few sleepless debugging nights.

Follow me

I write and share opinions about technology, software development and whatever crosses my mind.