How to Install and Manage Multiple Linux Distros in WSL

WSL fully supports running multiple, completely independent Linux distros side by side — each with its own separate filesystem, packages, and configuration, made possible by how simply a distro is packaged underneath.

Step 1: list currently installed distros

wsl --list --verbose

This shows every currently installed distro, which WSL version (1 or 2) each is running, and which one is currently marked as default.

Step 2: see what additional distros are available to install

wsl --list --online

This lists every distro Microsoft’s WSL platform can install directly, including multiple versions of major distros like Ubuntu, along with Debian, Fedora, and several others.

Step 3: install an additional distro

wsl --install -d Debian

This installs the specified distro alongside any you already have — existing distros are entirely unaffected by installing a new one.

Step 4: launch a specific distro directly

wsl -d Debian

This opens a shell in the specified distro directly, regardless of which one is currently set as default.

Step 5: set a different default distro

wsl --set-default Debian

The default distro is what launches when you run the bare wsl command without specifying -d, or when a tool integrates with “your WSL distro” without letting you choose one explicitly.

Step 6: run a command in a specific distro without opening an interactive shell

wsl -d Debian -- ls -la /home

Useful for scripting scenarios where you need output from a specific distro without launching a full interactive session.

Step 7: understand that each distro is fully independent

Installed packages, configuration files, and running processes in one distro have no effect on any other — this independence is a direct consequence of each distro living in its own separate virtual disk file, not a logical restriction layered on top of shared underlying storage.

Step 7b: give each distro independent networking or systemd configuration if needed

Because /etc/wsl.conf lives inside each distro’s own filesystem, one distro can have systemd enabled while another doesn’t, or one can have automount configured differently from another — configuration decisions made for one distro have no bearing on any other, letting you tune each distro’s behavior specifically for whatever that distro is actually used for.

Step 8: remove a distro you no longer need

wsl --unregister Debian

This permanently deletes the distro’s entire filesystem — export a backup first if there’s any chance you’ll want its contents later.

Why running multiple distros is genuinely useful, and not merely a novelty to show off

Different projects sometimes have different, conflicting toolchain or distro-version requirements — keeping a stable, general-purpose primary distro while spinning up a separate, disposable distro for a project with unusual requirements avoids polluting your main environment, and removing that secondary distro afterward is a single clean command away. This is meaningfully different from trying to keep one distro’s package set clean across several unrelated, conflicting projects by carefully installing and uninstalling packages as you switch context between them — a disposable secondary distro sidesteps that entire juggling act.

Remembering resource limits are shared, not per-distro

Every WSL2 distro you run draws from the same shared virtual machine and the same .wslconfig-configured memory and CPU ceiling — running several distros simultaneously, each with its own memory-hungry workload, competes for that same shared pool rather than each getting an independent allocation. If performance degrades with multiple distros active at once, checking overall vmmem usage against your configured ceiling is more relevant than assuming any single distro is misbehaving.

Naming distros clearly when you install several similar ones

Installing multiple instances of the same base distro (two separate Ubuntu installations for two different projects, for instance) requires giving each a distinct name during installation, since wsl -d <Name> is how you address a specific one afterward. Choosing clear, project-specific names upfront — rather than generic ones you’ll need to remember the purpose of later — pays off the first time you’re switching between several installed distros regularly.

Confirming which distro a given terminal profile or tool actually targets

Terminal applications and IDE integrations that “connect to WSL” generally target whichever distro is currently set as default unless explicitly configured otherwise — if a tool seems to be reaching the wrong distro’s files or environment, checking its specific WSL-target configuration (rather than assuming a bug) is often the actual explanation.

Backing up each distro independently before major changes, using export, remains worthwhile precisely because that same independence means one distro’s problems never automatically threaten another’s data.

Related:

Sources: