A homelab tinkerer, long resigned to Docker Desktop as a necessary evil, tests Microsoft's new wslc containers on a Windows machine and finds a different philosophy at work: each container gets its own virtual machine, trading the shared engine's familiar habits for isolation and consistency rather than raw speed. The result is a tool that fits development work and GPU experiments well, yet still lacks the restart, privilege, and Compose machinery that serious infrastructure demands. It is a reminder that every architecture is a set of tradeoffs, and that the newer design often reveals what th
Windows 11's WSL Containers Can Replace Docker Desktop for Dev Work, but Not Home Lab Services
The container disappears. The VM holding your RAM hostage doesn't.
So the headline finding is that wslc isn't really about speed?
Right. The author expected the speed story from early coverage, but warm starts differed by 60 ms and cold starts were close. What stood out was predictability: six starts within a 224 ms band.
Worth noting that's one machine, one tester, an alpine image. It's a measurement, not a benchmark suite.
And the architecture difference?
Each wslc container gets its own private VM, about 1.5 GB of RAM. Docker Desktop shares WSL's utility VM, and the app itself idles under 200 MB.
The 3.4 GB total includes a fresh shared WSL VM that booted alongside. That's his observation on preview software, so it may change.
Why does the lingering VM matter?
Microsoft says containers should vanish afterward. The container does, but the VM stays, even through a WSL shutdown, until you run wslc system session terminate.
And the author says no wslc command points you to that. That's his claim; I'd want Microsoft's docs to confirm.
So can it replace Docker Desktop?
For his dev containers, GPU work and light Compose use, yes. For services that must stay up, no: no --restart, no --privileged, no --device.
The Compose success came from a community shim, not Microsoft, and it was a two-service test. Whether it holds up for bigger stacks is unknown.
Der Puls
- A preview tool promises to replace a dependable but resented incumbent, and the test begins with that unspoken pressure.
- Each container quietly spawns its own virtual machine, and the memory of those machines lingers even after the container is gone.
- Startup speed claims collapse under measurement, with wslc and Docker Desktop landing nearly identical in timing.
- A stock CUDA image sees an RTX 5090 on the first try, a welcome surprise that makes the GPU case the strongest one.
- Missing restart policies, privileged mode, and native Compose leave the tool stranded in development use, bridged only by a community shim.
- The verdict is a confident yes for personal dev work, with hopes that Microsoft will add a management interface before wider adoption.
A homelab tinkerer, long resigned to Docker Desktop as a necessary evil, tests Microsoft's new wslc containers on a Windows machine and finds a different philosophy at work: each container gets its own virtual machine, trading the shared engine's familiar habits for isolation and consistency rather than raw speed. The result is a tool that fits development work and GPU experiments well, yet still lacks the restart, privilege, and Compose machinery that serious infrastructure demands. It is a reminder that every architecture is a set of tradeoffs, and that the newer design often reveals what the older one quietly hid.
The author runs most of his homelab on LXC containers under Proxmox, but on his Windows machine he still reaches for Docker Desktop, a program he has always tolerated rather than liked. When Microsoft shipped WSL Containers, known as wslc, in a recent WSL pre-release, he wanted to know whether he could finally let Docker Desktop go. He expected a speed contest and a clumsy first attempt from Microsoft. Instead he found a different architecture at work.
The central difference is that wslc gives every container its own private virtual machine, while Docker Desktop runs its engine inside a shared WSL utility VM. That design has a cost. A single wslc container claimed about 1.5 GB of RAM, and the VM outlived the container itself, surviving a manual WSL shutdown until he found a buried command to end the session. One idle prompt, in his tally, came to 3.4 GB.
The speed story did not hold. Early coverage promised sub-second starts, but on the newest build he measured warm and cold starts nearly identical to Docker Desktop, with wslc ahead by only 60 milliseconds. Docker's timing swung with how it had last shut down, while wslc's six starts stayed within a tight 224 millisecond band. Because private VMs inherit nothing, nothing needs repair, and he came to value that consistency over raw speed.
GPU support was the pleasant surprise. Expecting a long fight, he got a stock CUDA image seeing his RTX 5090 with a single flag, on the first try. The card is shared through paravirtualization rather than dedicated passthrough, so VRAM must be budgeted against the Windows desktop.
Infrastructure use is where the gaps show. There is no privileged mode, no device passthrough, and no restart policy, and networking binds to localhost by default, which led to a firewall prompt that looked suspicious. Compose does not work natively. A community shim got a two-service nginx and Postgres stack running with its own network and ordered startup, but Microsoft, he notes, has the underlying pieces and has not yet connected them.
His verdict is a clear yes for his own work: development containers, some GPU experiments, and a few Compose stacks, all light and configuration-free. The remaining complaint is visibility. Docker's VMs appear in a graphical interface whether you look for them or not, while wslc asks you to hunt through the command line. He hopes that is only a preview-stage shortcoming, and that a management interface arrives before the tool is asked to do more.
The author's homelab runs mostly on LXC containers under Proxmox, but when he is testing something on his Windows machine, he reaches for Docker Desktop, a program he has never liked and treats as a necessary evil. So when Microsoft shipped WSL Containers, abbreviated wslc, in the latest WSL pre-release, he set out to learn whether he could drop Docker Desktop for good. He expected a speed test and a clumsy Microsoft implementation. What he found, he writes, was a lesson in a different architecture.
The difference is that wslc builds a new private virtual machine for every container, while Docker Desktop's engine runs as a distro inside WSL's shared utility VM, alongside his Ubuntu install. Docker Desktop itself idles under 200 MB, including its privileged Windows service. A single wslc container, by contrast, creates a new VM named after the user account that takes roughly 1.5 GB of RAM.
That VM also lingers. Microsoft says these containers are meant to disappear when finished. The container does, but the VM holding the memory does not, and it survives a manual WSL shutdown. The only fix is the command wslc system session terminate, which sits three levels deep in the CLI, and nothing in wslc tells you to run it. Booting one container also started a fresh copy of the shared WSL VM and re-registered his Ubuntu distro as running. Total cost for one idle prompt: 3.4 GB of RAM.
The speed claims did not hold up either. Early coverage said wslc starts containers in under a second, against three to eight seconds for Docker Desktop. On the newest version, the author measured no such gap. Using a measure-command harness with alpine, warm and cold, he found wslc ahead by 60 ms warm to warm, a difference no one would feel, and cold starts were similarly close even though wslc boots a whole VM each time. Docker's timing depended on how it had shut down: a clean shutdown meant a return in under three seconds, while a crash took longer because things had to be rebuilt, and the privileged Windows helper requires approving a consent dialog. His six wslc starts all fell within a 224 ms band. Because private VMs inherit nothing, there is nothing to repair, and he concludes that consistency, not raw speed, is the real advantage.
GPU support was the pleasant surprise. He had set aside 15 minutes to see whether CUDA worked or caused enough trouble to warn people off. It took two minutes and worked on the first try. A stock CUDA 12.4 image saw his RTX 5090 with a single --gpus-all flag, with no driver juggling inside the container, even on a CUDA 13.3 host driver. This is GPU paravirtualization rather than exclusive passthrough, so the card's VRAM is shared with the Windows desktop and needs budgeting.
The flag list is where wslc falls short of infrastructure use. There is no --privileged, no --device, and no --restart, so nothing survives a session dying. Networking has a trap too: everything binds to 127.0.0.1 by default, not 0.0.0.0 as in Docker. His nginx test worked only after he published an explicit 0.0.0.0, which triggered a Windows firewall prompt attributed to COM Surrogate, the kind of prompt many people suspect is malware. Docker at least names the source of its firewall exception.
Compose is the other gap. As of version 2.9.3, wslc compose does not work, and the author says there is no working subset despite what other coverage suggests. A community project, wslc-compose, fills in with a thin Python shim. He installed it with pipx and tried a two-service test of nginx plus Postgres, with a depends_on to try to break it. It did not break: he got a project-scoped network, a database that started before the web container, and a deduplicated Alpine base layer shared by both. Running down -v removed the stack and its networking. He notes that Microsoft has already built the networking and volume lifecycles underneath, and cannot say why the top layer is missing.
His verdict is a clear yes for his own use: dev containers, some GPU work, and a few Compose stacks, all fast, light, and configuration-free on the 5090. The remaining complaint is visibility. Docker's VMs show up in a GUI whether you look or not, while finding what wslc is running takes command-line work. He hopes that is just a preview-stage issue and that Microsoft adds a management TUI.
Bemerkenswerte Zitate
Wslc can replace Docker Desktop for dev containers, some GPU work and light Compose use, but lacks restart support and privileged mode for long-running services.— XDA Developers author, paraphrased