Since Microsoft added Windows subsystem for Linux to my desktop, I’ve been waiting for container support. Docker Desktop licensing terms keep changing, your Background daemon treats my RAM like a buffetand turns every Windows update into a coin toss. So when the WSL Container preview arrived a couple of weeks ago, I did the only sensible thing.
Okay, maybe that wasn’t entirely sensible. Windows 11 preview builds often have their own problems and I’m not quite ready for them. ditch Docker Desktop for an alternative. But I spent some time identifying what parts of my workflow I could move to wslc.exe, and there are more than I thought. But a week later, I went back and let Docker Desktop eat up my system memory like Pac-Man. Not for bugs, performance, stability or any of the reasons I thought I might; simply for an essential characteristic.
Microsoft nailed the parts everyone complains about
GPU passthrough is also handled transparently
Getting there was its own adventure. wsl --update --pre-release I swore I was up to date, wsl --version showed 2.9.3.0 with the correct kernel, and where.exe wslc It came back empty every time. It turned out that the update had lied about its contents: reinstalling the actual package returned a deployment error insisting that it was “already installed” despite the different contents, and the fix meant deleting an AppX record of all users by their exact name before a clean install took effect. It’s not a wslc bug, just a packaging issue in a preview from a week ago, and I’d rather fight a preview install once than a preview runtime every day.
Once actually running, the CLI is a deliberate imitation of Docker, and that’s a compliment. wslc run --rm -it ubuntu:latest bash does exactly what your muscle memory expects, and it also does wslc build, wslc container psand port publication with -p 8080:80. I didn’t read a single page of documentation for the first two days. Nor is there an always active demon that devours memory; Each session is a new Hyper-V virtual machine that disappears when it ends.
Containers are started as soon as the image is pulled, which is limited only by Internet speed and the slowness of the container repository. This is a lifestyle change as I no longer have to wait for Docker Desktop to decide what it does behind the scenes. And with mirrored network mode, I can use localhost to access those containers without worrying about network IPs.
That’s all well and good, but there’s one feature of the title I hadn’t considered. GPU passthrough for Nvidia GPUs works natively, with a single --gpus all flag that allows nvidia-smi to find my RTX 5090 on the first try. There are no CDI specifications to generate manually, no toolkit to install inside the container. That’s the same driver step that WSL has quietly managed for years, and it was awesome to see on the first day of a preview.
The default PyTorch image does not have Blackwell (sm_120) kernels built in, so although it found my RTX 5090 fine, all CUDA calls failed. The nightly build of cu128 also failed, because pip saw a torch package in the base image and skipped the installation without telling me. you have to add –update -force-reinstall to the rope to fix it, which is worth knowing.
Additionally, Microsoft shipped a container API as a NuGet package for C, C++, and C#, which allows Windows applications to activate Linux containers as part of their own logic. I don’t ship Windows apps, so they aren’t designed for me, but this is a clear indicator that Microsoft isn’t simply cloning Docker Desktop and is instead making containers a primitive Windows platform.
There is a Docker Compose-shaped hole in WSL
Until that is fixed, I can’t use it for everything.
I have a confession here. I didn’t check Docker Compose support before trying to delete Docker Desktop from my system. I should have, because it doesn’t exist in wslc yet. I assumed it would be there because Docker support was all Microsoft’s talk, and my brain filled in the gaps that existed.
WSL containers do not have anything like Docker Compose at this time. No YAML support, no wslc composeno, nothing. That’s the biggest problem for me because my home lab runs on Compose files, from the local AI tool stack to the monitoring systems to the half-dozen essentials that live on my NAS. Each file defines networks, dependencies, storage volumes, and boot order, and Microsoft’s current response is a shrug.
Now, you can manually decompose a Compose file and convert it into PowerShell scripts that contain wslc race commands. I spent an afternoon with Claude explaining how, and although I can’t do it alone, I know the as behind the process. But it’s tedious, it needs to be done for every Compose file, and I didn’t have the courage to do the rest of the dozen or so services I rely on. I’ll revisit it when Microsoft decides to create a compose feature. For now, not even a pillar is missing; it’s a missing foundation for my workflow and in the meantime I’m back to Docker Desktop.
Docker Desktop wins today, but it shouldn’t be comfortable
The gap is closing
So, I’m going to change back, but that doesn’t mean I’m happy about it. Docker Desktop goes back to workstation because my multiservice stacks are in Compose files, and I won’t be translating them to PowerShell scripts and then switching back once Compose support comes to wslc. That’s him only reason I’m changing again: everything else about WSL Containers is better or clearly going in that direction.
And wslc.exe isn’t being uninstalled either, and not for the simple reason that you can’t uninstall it. It’s part of the WSL and you should remove it completely (which I definitely won’t do). It’s already earned a place in my workflow for quick, throwaway containers for testing something in Ubuntu, or GPU experiments that need CUDA from Nvidia. And VS Code’s Dev Containers extension has wslc support in preview, with changes as simple as a configuration field, so the work of developing a single container is handled.
Docker Desktop has one task right now: orchestrating stacks of multiple containers. It’s important work, which is good news for Docker because it’s the only thing standing between it and the recycle bin. Once Microsoft fills that gap, I’ll be able to banish that demon and get my precious RAM allocations back.
