WSL Manager

2026-03-0818:0814163github.com

A GUI to quickly manage your WSL2 instances. Contribute to bostrot/wsl2-distro-manager development by creating an account on GitHub.

Show article

Name	Name

English | 简体中文 | Deutsch | Español | 日本語

Preview with Lightmode

WSL Distro Manager is a free and open source app that provides a user-friendly graphical interface for managing Windows Subsystem for Linux (WSL) distributions. With WSL Distro Manager, you can easily install, uninstall, update, backup and restore WSL distros, as well as configure their settings and launch them with a single click. WSL Distro Manager also offers some extra features to enhance your WSL experience, such as sharing Distros between multiple machines, and creating actions to quickly do repetitive tasks. Whether you are a beginner or an expert in WSL, WSL Distro Manager will help you get the most out of it.

Microsoft Store

This app is available on the Microsoft Store.

Direct download

You can get this app with a direct download from the Releases page. The latest version is available as a zip file.

Install via Winget

The winget package is outdated! Please use the Windows Store version instead.

winget install Bostrot.WSLManager

Install via Chocolatey

This package is maintained by the community (@mikeee). It is not an official package.

choco install wsl2-distro-manager

Install a nightly build

The last build can be found as artifacts in the "releaser" workflow or via this link. If you rather prefer an unsigned msix you can also use this link.

Make sure flutter is installed:

flutter config --enable-windows-desktop
flutter upgrade flutter build windows # build it
flutter run -d windows # run it

👤 Eric Trenkel

Website: erictrenkel.com
GitHub: @bostrot
LinkedIn: @erictrenkel

👥 Contributors

Contributions, issues and feature requests are welcome!
Feel free to check the issues page. You can also take a look at the contributing guide.

Give a ⭐️ if this project helped you!

Not found what you were looking for? Check out the Wiki

You can’t perform that action at this time.

Page 2

Name	Name

You can’t perform that action at this time.

Read the original article

Comments

By llm_nerd 2026-03-0821:342 reply

Neat project. Merging the layers of a docker image and setting that as a WSL filesystem is a nice convenience.

I recently realized that 100% of what I use Windows for was as a WSL2 foundation: It had been reduced to being an extremely overbearing and heavyweight host machine for a Linux VM. Nothing in my life was Windows-only anymore, and it was basically just inertia that I even still had it installed.

I'd been a "Windows guy" for decades, had decades of Windows software dev under my belt, even got my MCSE, MCDBA, along with other Microsoft certs, and even wrote for MSDN Magazine. No longer did it have any leverage on my profession at all, which was shocking to me.

The next day I purged Windows from my two main working machines, so now I'm pure Linux and macOS. A few weeks later and I can say it has been a marvelous transition, and cuts out the no longer relevant middleman.

By martinald 2026-03-093:18

It's interesting because I'm the same in so much that I use windows basically as a WSL2 host and not much else. I use a MacOS a lot.

_However_, still find the Linux desktops that I've tried are too buggy. While the hardware support is incredible (compared to Windows out of the box), I constantly hit bugs with fractional scaling on multiple monitors. I'm hopeful that Ubuntu 26.04 may finally iron out the last problems with this. The latest version of Fedora I installed did fix all this but I'm far too used to Debian based OSes.

By binkHN 2026-03-092:18

Right there with you. When Microsoft started pushing Windows 11 over Windows 10, that's when I decided I had enough of my experience being dumbed down. I switched over to Linux, haven't looked back, and couldn't be happier. I still run a Windows virtual machine for those times that I need something native to that operating system, but I should have made the move years ago; Microsoft doesn't care about Windows anymore.

By wongarsu 2026-03-0819:022 reply

The ability to run docker containers as wsl instances looks nifty. A bit more overhead since they now run as a VM instead of a container, but you get the ability to start a shell with Windows terminal or access files with Explorer (and thus every program running in Windows)

By osigurdson 2026-03-0820:273 reply

Perhaps I misunderstand your comment but when you run docker / podman in Windows, you are using WSL / HyperV.

By wongarsu 2026-03-0821:021 reply

running docker on windows runs docker in wsl (which is a HyperV guest). The project offers running docker images as wsl instance (which is a HyperV guest), no docker involved

By llm_nerd 2026-03-0821:111 reply

You said - "A bit more overhead since they now run as a VM instead of a container"

To which osigurdson seemed to be noting that WSL2 itself is a VM (meaning if you launch 1 or 100 WSL2 instances, a single Linux VM will be spun up), and when you run docker, it runs using exactly that same VM (optionally, though it's the default now to just use WSL2's backend).

Can you clarify what you meant by "A bit more overhead"? Running a container via docker or directly via WSL2 will use the same underlying VM, and there will only be that one VM regardless of the number of WSL2 or docker instances.

By wongarsu 2026-03-0821:591 reply

For a single container the difference depends on your exact setup. I typically run docker in the same WSL instance as my other wsl stuff, so starting a single docker container adds 0 additional VMs, while starting the container as a wsl instance will add one VM. If you use the "docker for windows" package you may be adding a VM just for running docker, depending on your setup.

Once you start the second container the difference becomes more obvious: running $N containers in docker uses one VM with one linux kernel, no matter how many containers you add. Running $N containers as separate WSL instances runs $N VMs and $N linux kernels. That's the "bit more overhead" I was referring to

By llm_nerd 2026-03-0822:141 reply

"Running $N containers as separate WSL instances runs $N VMs and $N linux kernels."

But it doesn't, and this is what I'm disagreeing with.

If you instantiate WSL2, it launches a Linux VM. A single Linux VM. If you then run Docker with WSL2 integration (the default and hugely recommended), it uses that Linux VM as its VM as well, so you're still at 1 VM.

If you run 100 WSL2 instances, they will all use that single Linux VM, each doing namespacing for isolation with their own filesystems. If you run 100 Docker instances, they will all use that single Linux VM.

If you run 100 WSL instances, and 100 Docker instances (assuming, again, WSL2 integration which is the default), they will all be using that single Linux VM.

By Jenk 2026-03-0823:583 reply

Every time you run `wsl --install <distro>` you are creating a new VM. Every time you run `wsl --unregister <instance id or name/>` your are removing a VM.

It is these two operations at the heart of OP's app.

By super256 2026-03-094:221 reply

No, this is wrong.

WSL2 distributions share the same Linux kernel. They only get their own root filesystem with a Linux userland (/bin, /usr, /lib etc), and some WSL config meta data. This is then stored as a virtual disk image (which is probably where your belief comes from). But the kernel runs in a single utility VM. The distros share that kernel instance and they are separated via namespaces only.

This makes running multiple WSL2 distributions in parallel very performant btw, as there is no world switch.

By Jenk 2026-03-099:26

I stand corrected. It makes sense that it is a chroot/rootfs rather than fully independent VMs.

re: side-by-side running, I always get socket and/port port problems when doing that. Without having looked into it at all I figure it is NAT collisions.

By mappu 2026-03-094:28

This is not true - it's actually all the same VM if you check hcsdiag.

WSL2 distros only use Linux namespaces, same as docker, and the WSL2 --system distro can see PIDs from all running WSL2 distros.

By llm_nerd 2026-03-090:371 reply

Okay, are you guys using wrong terminology? Are you talking about a filesystem image as a "VM", because that would not be correct. A "Virtual HD" (VHD) is not a VM. Do you think a WSL2 distro instance is a "VM" because it's persistent? Did you know Docker containers can be persistent as well, people just choose as a best practice not to use it like that? Does that make them magical VMs?

WSL2 has a single VM running as the process vmmem (or vmmemWSL in the newest versions). This is the single Linux kernel that will be shared by every WSL2 instance. It will also be the instance that hosts Docker containers as well. I mean, I'm just echoing myself and apologies for the repetition, but this is just easily confirmed, utter factual truth.

A rootfs is not a VM. WSL2 and containers have different nuances about their filesystem and isolation (WSL2 instances is aware of other instances, for instance, as a design aspect, and WSL2 persists rootfs changes while docker as a best practices does not), but they're more alike than different. And they share little in common with something like VirtualBox or vmware, which actually isolate every such system as VMs.

Again, sigh, if you install 10 WSL2 "distros", you will have 10 rootfs overlays on your drive, and 10 persistence VHD files. When you run these the VM they all run under in the shared vmmem instance, which is the single utility Linux VM.

By opello 2026-03-090:461 reply

Is there a way to visualize this on a running system or some documentation that describes it? I'm not familiar with the plumbing here but did try to find some documentation.

By llm_nerd 2026-03-091:001 reply

I've done a lot of in-depth WSL2 work, so I'm just aware of its particulars, but to cite some documentation-

https://learn.microsoft.com/en-us/windows/wsl/about

"WSL 2 uses virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM). Linux distributions run as isolated containers inside of the WSL 2 managed VM. Linux distributions running via WSL 2 will share the same network namespace, device tree (other than /dev/pts), CPU/Kernel/Memory/Swap, /init binary, but have their own PID namespace, Mount namespace, User namespace, Cgroup namespace, and init process."

(under "What is WSL2"?)

https://www.docker.com/blog/new-docker-desktop-wsl2-backend/

"WSL 2 runs all distros in the same utility VM, sharing the same Kernel."

If you run multiple distros take a look at the process manager and find the single vmmem or vmmemWSL (newer versions have the latter). That single instance is all of the instances, and all of the docker containers you might be running as well, each with namespace isolation (with WSL2 having intentional bridging between them for convenience). Visualise it by doing something intensive in any of them and seeing the single process react, because that's the single utility VM responsible for all of them. Further while starting up the first WSL2 instance or Docker container is expensive, requiring the initialisation of all of the resources for the utility VM and the memory to support it, subsequent iterations are much less expensive.

By opello 2026-03-091:231 reply

Thanks, it wasn't out of doubt that I asked, but it seemed having a reference to point at would help resolve the contention. The Docker blog post covered a lot more detail, even about WSL2, which was really informative and I hadn't seen.

I wonder exactly how much work "container" is doing in that Microsoft blog post's description, because it doesn't seem like it's the same kind of environment as a runc or containerd container?

I also wasn't quite sure how much detail to infer from the behavior of vmmemWSL or vmcompute.exe, because my casual understanding is that there's some adaptation layer that handles mapping Linux calls to Windows calls. It seems reasonable to allow for process mapping or accounting shenanigans for any number of good reasons.

By llm_nerd 2026-03-091:33

>there's some adaptation layer that handles mapping Linux calls to Windows calls

This was how WSL1 functioned. It used a shim layer, and honestly it was pretty neat for a lot of the basic stuff. It fell apart if you were doing more complex/advanced stuff, however, as there were many missing cases and exceptions.

WSL2 instead uses that utility VM, with a couple of special Microsoft kernel drivers to interact with the host system.

By smallerize 2026-03-0820:36

The linked project includes a very different way to launch docker containers.

By ghosty141 2026-03-098:551 reply

Just FYI you can also run a windows docker natively in windows without using WSL or any linux component. But that's more of a niche usecase.

By andix 2026-03-0911:18

I haven't heard anyone talk about Windows containers in years, and that was actually a good thing. Let's just pretend they never existed.

By Chris2048 2026-03-0820:46

How does this compare to running the containers in one of the WSL VMs? Can't you do all the same things via the host VM?

By lukax 2026-03-0819:072 reply

Looks nice but still a bit sad that Flutter is used instead of something native given that they don't need the app to be cross-platform.

Well, even Microsoft uses React Native for a lot of Windows-only apps.

By pjmlp 2026-03-097:48

The React Native reason is called C++/WinRT, the teams that internally rioted against C++/CX and came up with C++/WinRT (now in maintenance, go figure), never cared one single second about the Visual Studio experience (using C++/CX was similar to the Delphi/VB like experience from C++ Builder), that everyone else was losing.

Thus React Native is the only alternative left those teams had to have some kind of nice GUI design experience alongside C++/WinRT, when using WinAppSDK, think Qt with QML/C++.

Agree on the Flutter comment.

By Defenestresque 2026-03-0820:203 reply

I'm glad I'm not alone in missing native apps. I get that it's easier to code a note-taking Electron app, but every time I look at a Linux terminal app written in JavaScript it makes me want to cry.

I know I'm beating a dead HN horse here, but how the hell is it possible that megabytes of embedded JavaScript in websites, to the point that LinkedIn uses about half the RAM I had for my first computer loading 32 MB of JavaScript files. Jjira loads 50 (!) MB of javascript, enough to include the uncompressed version of War and Peace 16 times. That's the size of a full installation of the entire Windows 95 operating system. GitLab's static landing page is 13MB of JavaScript, larger than that of Twitter.

What the hell are we doing here? Why can I spin up a 100 MHz, 8MB RAM VM with a hard drive size that's 1/16th of your entry level MacBook's RAM and have apps open immediately? I understand some backsliding as things get more high level, but a website loading 50 megabytes of JavaScript, to me, is like a bright neon sign that screams "something has gone wrong terribly here". Obviously programs, websites and operating systems have become incredibly more complex but your $200 A-series Samsung phone has about 8 cores at 2.2 GHz each. A $200 processor when Windows 95 was released had one core at 0.1GHz. making the processing power about 164x faster. Keep in mind this $200 includes a fully functioning computer in the palm of your hand. The actual CPU part for a midrange phone like the Samsung A15 5G is the Dimension 6100+, which costs all of $25 bucks.

There must be some sort of balance between ease of prototyping, creating and deploying an application without bundling it with Electron or building websites that use tens of megabytes of a scripting language for seemingly nothing. Especially when we can see that a fast, usable website (see this very website or the blogs of many of the people who post here, compared to Reddit for your average medium or substack blog).

How the hell do we fix this? The customers clearly don't want this bloat, companies clearly shouldn't want it either (see research that indicates users exposed to a 200 millisecond load delay on Google, performed 0.2-0.6% fewer searches, and effect that remained even when the artificial delay was removed. This was replicated by Microsoft, Amazon and others. It's frequently brought up that Amazon has said that every 100 milliseconds of page load time cost them 1% in sales, though it's hard to find definitive attribution to this), programmers should hopefully not want to create crappy websites just like mechanics should hopefully not want to install brake pads that squeal every time the user breaks.

This got way longer than the two sentences I expected the post to be, so my apologies.

[1] https://tonsky.me/blog/js-bloat/ [2] Velocity and the Bottom Line, Shurman and Brutlag

By wiseowise 2026-03-0914:05

> The customers clearly don't want this bloat, companies clearly shouldn't want it either

Both of these statements are false. If this was really the case, then competing company/dev could implement native counterpart and just siphon all the users – I've only seen this happen with CLI tools (e.g. esbuild, rollup, uv, etc.)

By aclatuts 2026-03-0917:11

Most of the JS bloat comes from really aggressive analytics, error tracking, and a/b testing. Not many developers are willing or given approval to remove these features up for smaller bundle sizes.

By ai-psychopath 2026-03-0820:472 reply

> The customers clearly don't want this bloat,

citation needed. the customers clearly want it, for example most programmers chose VS Code over a native app

By 306bobby 2026-03-093:032 reply

If there was a vs code native alternative that was parity, that might not be a case. That's apples and oranges

By krapht 2026-03-093:442 reply

Sublime Text? Sure, doesn't have the long tail of extensions, but surely most people don't need those. The biggest issue with ST being the fact that it costs money...

By wiseowise 2026-03-0911:51

> The biggest issue with ST

The biggest issue is that it’s not open source.

By pjmlp 2026-03-097:51

And we don't want to pay for tools, while expecting to be paid ourselves, rigth?

By xd1936 2026-03-0910:50

Zed?

By pjmlp 2026-03-097:50

I did not chose VSCode, I only touch it, because there are SDKs whose programmers decided only to support VSCode as Electron fans.

Thus I begrudgingly use VSCode when forced to do so, otherwise I use the IDEs of each OS vendor.