Ever since Microsoft added Windows Subsystem for Linux to my desktop, I’ve been waiting for container support. Docker Desktop’s licensing terms keep changing, its background daemon treats my RAM like a buffet, and it turns every Windows update into a coin flip. So when the WSL Container preview landed a couple of weeks ago, I did the only sensible thing.
Okay, maybe it wasn’t a completely sensible thing. Preview builds of Windows 11 often have their own issues, and I’m not quite ready to ditch Docker Desktop for an alternative. But I did spend some time identifying which parts of my workflow I could move to wslc.exe, and there are more than I thought. But a week later, I’m back, letting Docker Desktop eat up my system memory like Pac-Man. Not because of bugs, performance, stability, or any of the reasons I thought I might; simply because of one essential feature.
Microsoft nailed the parts everyone complains about
GPU pass-through is handled transparently as well
Getting there was its own adventure. wsl --update --pre-release swore I was current, wsl --version showed 2.9.3.0 with the right kernel, and where.exe wslc came back empty every time. Turned out the update had lied about its contents: reinstalling the real package threw a deployment error insisting it was “already installed” despite different contents, and the fix meant tearing out an all-users AppX registration by its exact name before a clean install would take effect. Not a wslc bug, just a packaging problem in a week-old preview, and I’d rather fight a rough install once than a rough runtime every day.
Once it actually ran, the CLI is a deliberate Docker mimic, and that’s a compliment. wslc run --rm -it ubuntu:latest bash does exactly what your muscle memory expects, and so do wslc build, wslc container ps, and port publishing with -p 8080:80. I didn’t read a single page of documentation for the first two days. There’s no always-on daemon gobbling memory either; each session is a new Hyper-V VM that goes away when you’re done.
Containers start as soon as the image is pulled, which is limited only by your internet speed and how slow your container repo is. That’s a lifestyle change, as I no longer have to wait for Docker Desktop to decide whatever it does behind the scenes. And with the mirrored network mode, I can use localhost to access those containers without worrying about network IPs.
That’s all cool, but there’s a headline feature that I hadn’t considered. The GPU pass-through for Nvidia GPUs works natively, with a single --gpus all flag that lets nvidia-smi find my RTX 5090 on the first try. No CDI spec to hand-generate, no toolkit to install inside the container. That’s the same driver pass-through that WSL has quietly handled for years, and it was awesome to see on day one of a preview.
PyTorch’s default image doesn’t have Blackwell (sm_120) kernels built-in, so while it found my RTX 5090 fine, every CUDA call failed. The nightly cu128 build failed as well, because pip saw a torch package sitting in the base image and skipped the install without telling me. You have to add –upgrade -force-reinstall to the string to fix it, which is worth knowing.
Also, Microsoft shipped a container API as a NuGet package for C, C++, and C#, which lets Windows apps spin up Linux containers as part of their own logic. I don’t ship Windows apps, so it’s not designed for me, but this is a clear indicator that Microsoft isn’t purely cloning Docker Desktop and is instead making containers a Windows platform primitive.
There is a Docker Compose-shaped hole in WSL
Until that’s fixed, I can’t use it for everything
I have a confession here. I didn’t check for Docker Compose support before I tried to wipe Docker Desktop from my system. I should have, because it doesn’t exist in wslc, yet. I assumed it would be there because Docker compatibility was the whole pitch from Microsoft, and my brain filled in gaps that existed.
WSL containers have nothing resembling Docker Compose right now. No YAML support, no wslc compose up, no nothing. That’s the biggest problem for me because my home lab runs on Compose files, from the local AI tooling stack to the monitoring systems, and the half-dozen essentials that live on my NAS. Every file defines networks, dependencies, storage volumes, and startup order, and Microsoft’s current answer is a shrug.
Now, you can manually decompose a Compose file and turn it into PowerShell scripts containing wslc run commands. I spent an evening with Claude explaining how, and while I can’t do it on my own, I know the how behind the process. But it’s tedious, needs doing for every Compose file, and I didn’t have the heart to do the rest of the dozen services I rely on. I’ll revisit that when Microsoft decides to build a Compose feature. For now, it’s not even a missing pillar; it’s a missing foundation for my workflow, and I’m back on Docker Desktop for the interim.
Docker Desktop wins today, but it shouldn’t get comfortable
The gap is closing
So, I’m switching back, but that doesn’t mean I’m happy about it. Docker Desktop goes back on the workstation because my multi-service stacks live in Compose files, and I’m not translating those into PowerShell scripts and then switching back once Compose support arrives in wslc. That’s the only reason I’m switching back: everything else about WSL Containers is either better or clearly heading that way.
And wslc.exe isn’t being uninstalled either, and not for the simple reason that you can’t uninstall it. It’s part of WSL, and you have to remove the entire thing (which I’m definitely not doing). It’s already earned a place in my workflow for quick throwaway containers to test something in Ubuntu, or GPU experiments that need Nvidia’s CUDA. And VS Code’s Dev Containers extension has wslc support in pre-release, with switching as simple as one settings field, so single-container dev work is handled.
Docker Desktop has one job right now: orchestrating multi-container stacks. It’s an important job, 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 can banish that daemon and reclaim my precious RAM allocations.
