For years the recipe for running Linux containers on Windows has been the same: install Docker Desktop, accept whatever its license terms are this quarter, and let it park a small VM in your RAM like a caravan on your front lawn. Or go the Podman route and explain to every tutorial on the internet why your commands look slightly different.
Microsoft has now quietly shipped a third option: none of the above. The new WSL Containers preview teaches WSL itself to run Linux containers, no Docker Desktop, no Podman Desktop, no Rancher Desktop. Just Windows, doing the thing directly. And somewhere at Docker headquarters, someone just looked at the enterprise revenue spreadsheet and quietly closed the laptop. More on that later.
Getting it
The whole setup is one command, which by Windows standards is suspicious:
wsl --update --pre-release
wsl --shutdown
wslc --versionThat pulls the pre-release WSL (2.9.3 or later; the version check answers wslc 2.9.4.0 at the time of writing), and you get a new binary called wslc.exe. There is also a container.exe alias, presumably for people who feel wslc is not enough typing.
If pre-release channels make you nervous, the same builds are on the WSL GitHub releases page. But let’s be honest, if you’re reading a post about a preview feature, you were going to install it anyway.
Does it work?
I tried it. It works.
That’s a shorter paragraph than my usual debugging stories, and I’m as surprised as you are. wslc run behaves the way your fingers expect: the syntax is the familiar Docker dialect, so wslc run -it debian:latest drops you into a real Debian with a real Linux kernel, ports map with -p, images build from a plain old Containerfile with wslc build, and wslc ps -a lists your containers like it has been doing this for years. Basic container runs just worked for me on the first try, which is not a sentence I write often about preview software.
GPU support is in there too, with the --gpus flag. A word of warning about Microsoft’s own launch example, which runs the PyTorch image with no command at all: it pulls a few gigabytes, starts a shell with no terminal attached, exits immediately, and --rm tidies away the evidence. The world’s quietest benchmark. Give it something to actually do:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available())"If that prints True, the container sees your GPU. Mine printed True and then the name of my GTX 1080 Ti, a card old enough to be surprised anyone still asks it to do AI things. And for the traditionalists, the full nvidia-smi ritual works too, via a much smaller image:
wslc run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smiFri Jul 24 00:04:23 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 535.98.01 Driver Version: 536.99 CUDA Version: 12.2 |
|----------------------------------+--------------------+---------------------+
| GPU Name Persistence-M | Bus-Id Disp.A| Volatile Uncorr. ECC|
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage| GPU-Util Compute M.|
|==================================+====================+=====================|
| 0 NVIDIA GeForce GTX 1080 Ti On| 00000000:01:00.0 On| N/A|
| 20% 37C P8 16W / 250W | 1290MiB / 11264MiB | 3% Default|
+----------------------------------+--------------------+---------------------+The same table you’d get on bare-metal Linux, except here the Linux is a disposable VM inside Windows and the card apparently hasn’t noticed. CUDA passthrough confirmed, on the first try. I haven’t thrown a proper workload at it yet, but reports from people who have say the difference to CPU-only inference is, as expected, not subtle.
The interesting part is under the hood
This is not just Docker with the serial numbers filed off. Docker Desktop runs all your containers inside one shared utility VM. WSL Containers gives each container its own lightweight Hyper-V backed VM. That trades a bit of resource efficiency for a hard isolation boundary between containers, which tells you exactly who Microsoft built this for: the same enterprise IT departments that currently break out in hives when a developer says the word “Docker”.
The enterprise tells are everywhere. There’s Group Policy support for allowlisting container registries, so the company can make sure you only pull blessed images from the internal registry. Intune support is promised shortly, and Defender for Endpoint monitoring of containers is in private preview. Anyone who has ever lived inside corporately managed Windows can already picture the ticket queue.
The preview also debuts some genuinely nice plumbing: a new virtiofs file sharing mode that Microsoft claims doubles the speed of Windows file access, an experimental networking mode called Consomme (yes, like the soup) that relays traffic through the Windows network stack so VPNs and proxies stop being a daily ambush, and smarter memory reclaim that actually gives unused RAM back to the host. For now these live only in WSL Containers, with a rollout to regular WSL distros planned later.
VS Code, without the whale
The part that makes this practical for daily work: the Dev Containers extension can use it. In the pre-release version of the extension (0.462.0 or later), you point the “Docker Path” setting at wslc and your devcontainers open against WSL Containers instead of Docker. One settings field and Docker Desktop is suddenly optional.
What’s missing
It’s a preview and it shows. Missing at the moment:
- USB passthrough. No
--deviceor--privilegedflags at all, so anything that talks to real hardware stays in your current setup. - Compose. No multi-container orchestration, every container starts by hand.
- A GUI. There is no dashboard,
wslcis all you get. - Image scanning. Nothing like Docker Scout built in.
If your daily driver is a docker-compose.yml with nine services, this is not your migration week.
Docker losing money and fast
Here’s the angle nobody in the launch coverage seems to dwell on. Big IT companies buy Docker Desktop licenses the way other people buy printer paper: in bulk, without looking too hard at the unit price. Except the unit price is 24 dollars per user per month for Docker Business, and once you multiply that by an enterprise worth of developers, the whale is eating a very respectable yearly sum.
Now picture this feature graduating from preview, getting its promised Intune packaging, and showing up in Company Portal next to the other blessed apps. Free, built into Windows, with registry allowlists IT can manage through the GPOs it already loves. At that point it stops being a hobbyist alternative and becomes a procurement conversation, the kind where someone in a meeting asks why the company pays for a thing Windows now does for free, and nobody has a good answer.
It’s not there yet, and not only because of the preview label. Two things stand between this and the average corporate laptop. The first is virtualization policy. On a physical machine the container VMs run as siblings under the host hypervisor, so ordinary virtualization support is enough, but on VDI you need nested virtualization, which is usually disabled, and plenty of IT departments restrict virtualization features on general principle anyway. The second, and bigger one, is security tooling. Microsoft’s own Defender for Endpoint monitoring for WSL containers is still in private preview, and as far as I can tell the third-party EDR agents, your CrowdStrikes and friends, don’t have an answer for it yet. No EDR visibility means no corporate rollout, full stop.
Both problems are solvable, and Microsoft is visibly solving them in exactly the order an enterprise sales team would: policy controls first, security integrations next. When that story is complete and this lands in the standard corporate image, Docker the company loses the easiest recurring revenue it ever had, the enterprise seats that exist mostly because Windows had no built-in alternative.
So who is this for?
If you’re a hobbyist happy with Docker Desktop, nothing here forces your hand this year. But if you ever wanted containers on Windows without a third-party stack, or you’re the IT department that wants hard isolation and allowlists, this is the most native answer so far. General availability is aimed at fall 2026, and I suspect the license renewal spreadsheets will notice.
My basic containers run fine, the GPU answers roll call, and a proper workload benchmark is sitting on the todo list where such things go to mature. Maybe I’ll get to it one of these evenings, if the calendar allows, which historically it does not.