It’s been just over a month since WSL 3.0.1 was released, and it’s already changing the way I run my Linux containers. One distinct feature that caught my interest is the fact that it adds a wslc command that can pull images, run containers, set ports, and even create images from a container file directly from PowerShell or CMD.
The funny thing is that Microsoft itself used to recommend using Docker Desktop in its WSL container tutorial in the past, but now they have moved on to Teaching wslc on the same page as Microsoft Learn. Following these instructions, I set it up on my main PC with a Ryzen 5 7600X and an RTX 4070 Ti Super. To my absolute delight, I had my first container running in less than a minute of starting the update, and I’m now convinced that there’s no simpler way to run containers if you’re using Windows 11. Here’s why, and how.
The entire installation process is one thing
Type wsl –update, and you’re almost done
Setup is remarkably easy and probably as simple as it can be. If you follow the official instructions from Microsoft, setup begins and ends in PowerShell. The first thing you want to do is check if you already have WSL version 3.0.1 or later wsl –versionwhich is possible if you updated it recently. If not, wsl –update It pulls the latest version, and that’s the entire installation process.
If your computer is not equipped with WSL or if your Windows 11 installation is new, you will have to use wsl –install To prepare it first. Everything that happens after that is just verification after setup. You can run wslc version To make sure the new command is live, then run it Run wslc –rm hello-world To pull a small test image and print a greeting from within a Linux container. Believe it or not, that’s literally what it is.
On my computer, the first container printed the greeting in less than 10 seconds after pressing Enter, and that included downloading the image. I’m never asked to sign in, restart my computer, or accept certain licenses, and it’s as seamless as containerization in Windows 11.
The RTX 4070 Ti Super runs like a dream inside the enclosure
The Windows driver I already installed did all the work
My workflow involves working a lot with local LLMs through llama.cpp, and llama.cpp publishes official CUDA container images. The problem is that the inference server in the container is only worth running if it has access to the GPU, because without it, the inference goes back to the CPU, and onto the 7600X processor, which turns the fast response from the form into something that you have to wait three business days for to finish. This is clearly not the experience anyone wants in the field of native AI inference.
The good news about all this is that WSL has been delivering Nvidia GPUs to Linux for years through the same driver that Windows already uses, so there’s no additional Linux driver I have to look for. If you’ve ever used Docker like I did, you’ll already know how to point it to your GPU, because wslc accepts the same –gpus all science. To make sure it works as expected, I ran a small Nvidia CUDA base image with:
wslc run --rm --gpus all nvidia/cuda:12.9.1-base-ubuntu24.04 nvidia-smi Sure enough, it confirmed that the container saw an RTX 4070 Ti Super with 16GB of VRAM and driver version 617.14, which is the same version that Windows 11 reports. On a regular Linux machine, this would involve installing Nvidia’s container toolkit and configuring Docker to use it. Here, I didn’t have to install anything.
When you’ve confirmed that it works, the only thing left to confirm is How well It works. I’ve referenced the official CUDA image of llama.cpp in the Gemma 4 E4B sample file I use on Windows, which is installed directly from my models folder. Both runs used the same Q4_K_M quantization with full GPU offload in the 128K context, with the same prompt, and response of 256 tokens. The original llama.cpp generated between 128 and 132 tokens per second across two runs, while the container generated 124 tokens per second both times. Suffice to say, this is a gap I will never notice.
WLSC doesn’t replace Docker Desktop for me, nor does it have to
The compose feature is missing, and Microsoft is working on a fix
I’m not going to talk about how wslc is better than Docker Desktop, or if I prefer one over the other, especially not at this time, where the build is clearly missing from the picture. Since wslc is still relatively new, it is missing a built-in build runtime, and as such, a comparison like this would be unfair.
It is useful to know that Microsoft has already acknowledged that the build feature is the most requested wslc feature and said that it is what the team is working on next, with the aim of running existing build files without changes. In addition, Docker Desktop also has some other things. It can switch to Windows containers while wslc only runs Linux containers. It’s also free for users like me, and paid plans are only required for large organizations.
Launching a Linux container has never been easier
For single containers, GPU workloads, and flash tests, wslc offers a pipeline to spin up Linux containers in a second, something that many users like myself will appreciate. If you don’t rely on construction, you can’t go wrong with either.
It’s worth knowing that setting up Linux containers is much easier and wslc takes a lot of the initial friction out of the loop. If you need to build today but prefer to skip Docker Desktop, Podman Desktop and Rancher Desktop are other free and open source alternatives that handle build files on top of WSL.
