Microsoft just made Linux containers a built-in Windows feature. WSL Containers (WSLC) went generally available on September 29, 2026, and if you are a Windows developer who has been running Docker Desktop just to get docker build and docker run working, this is the moment you can finally uninstall it — maybe.
I have been running WSL on my Windows machines since the early days. The promise of Linux tooling without dual-booting or full VMs was real, but the container story was always the awkward part. You either installed Docker Desktop with its always-on daemon eating 1-2 GB of RAM, or you hand-installed Docker Engine inside a WSL distro and prayed the networking worked. WSL Containers is Microsoft’s answer: a daemonless container runtime that ships with WSL itself.
What Actually Shipped
The GA release gives you two things. First, wslc.exe — a command-line tool that pulls, builds, runs, and manages Linux containers. There is also a container.exe alias if you want something that feels more familiar. Second, the WSL Containers API, which lets native Windows apps programmatically launch and control Linux containers. Microsoft is pointing at local AI workloads as a primary use case for the API.
To get it, you run wsl --update. That is it. No separate download, no Docker Desktop installer, no license key. The feature requires WSL 2.9.3 or later, and the current stable release is WSL 3.0.1.
Since the public preview in June, Microsoft added several features that were missing at first: container restart, copying files in and out, health checks, network connect and disconnect commands, real-time container events, mount support, and configurable storage locations. VS Code Dev Containers can use wslc as its default driver, and the VS Code Containers extension and .NET Aspire now support it too.
Why I Care
Here is the honest part. I run Docker Desktop on my main Windows machine. I use it for local development databases, testing deployments, and spinning up isolated environments. The daemon is always there, always consuming memory, always updating itself at the worst possible time.
WSL Containers is different. There is no daemon. The wslc.exe CLI calls a Windows host service that starts a dedicated Hyper-V utility VM on demand and launches each container as a process inside it. When you are not running containers, the memory footprint is effectively zero. When you are, file I/O through VirtioFS is reportedly up to twice as fast as Docker Desktop’s 9p or gRPC-FUSE layer.
For single-container workflows — building an image, running a test database, deploying a microservice — this is genuinely better. Lighter, faster, no background process. The kind of thing that makes you wonder why it took this long.
Where It Falls Short
But I am not uninstalling Docker Desktop yet. WSL Containers has real limitations that matter for daily development.
There is no wslc compose. Multi-service local stacks — the most common Docker Desktop use case — are the least covered. If your project needs a web app, a database, a cache, and a message queue all talking to each other, you are still reaching for Docker Compose.
No Kubernetes. No Swarm. No buildx for multi-platform images. No restart policies — if you want a container to survive a reboot, you need a Windows scheduled task or a wrapper script. No --network host. No generic device passthrough with --device. And no Windows containers — this is Linux-only.
The networking model is also different. WSL Containers routes through the Windows host stack, which means it inherits your VPN, proxy, and firewall settings automatically. That is convenient, but it also means you cannot do the kind of network isolation that Docker’s NAT provides out of the box.
My honest take: WSL Containers is not a Docker Desktop replacement. It is a lighter, built-in alternative for a specific subset of container workflows. And as auditing your AI toolchain for supply chain risks becomes standard practice, having a built-in container runtime from a vendor you already trust simplifies the compliance story. If you mostly build and run single containers, it is excellent. If you rely on Compose stacks, Kubernetes, or the broader Docker ecosystem, you are staying put for now.
What This Means for Windows Development
The bigger story here is that Microsoft is finally treating containers as a first-class Windows feature rather than something you bolt on with third-party tools. IT admins get Intune controls to enable or disable WSL Containers and restrict image pulls to approved registries. That is enterprise-ready in a way that hand-installed Docker Engine never was. For teams running AI workloads, securing your AI deployments becomes even more critical when containers are involved.
For the AI crowd, the API angle is interesting. Running local AI workloads in isolated containers without Docker Desktop overhead is a real use case. GPU passthrough works via the same --gpus flag as Docker, so you can run CUDA workloads inside WSL Containers. If you are already running local models, benchmarking local LLMs with Ollama gives you a baseline to compare against containerized performance.
This is also a philosophical shift. Microsoft’s then-CEO once called Linux a cancer. Now Windows 11 ships with a built-in Linux container runtime. The arc is not lost on me — I wrote about the 1975 code that launched Microsoft and how far the company has come.
Should You Switch?
If you are a Windows developer who uses Docker for simple single-container tasks, try wsl --update and run wslc run hello-world. The learning curve is minimal if you already know Docker commands. The performance gains are real, and the lack of a background daemon is quality-of-life improvement you will notice immediately.
If your workflow depends on Docker Compose, Kubernetes, or the Docker Desktop GUI, wait. Microsoft is clearly investing in this — the feature went from preview to GA in just three months — but the ecosystem gaps are real. Give it another release or two.
For me, I will keep Docker Desktop installed but start reaching for wslc first on single-container tasks. Having a built-in option that does not eat my RAM when idle is worth the switch, even if it is not a full replacement. Sometimes the best tool is not the one that does everything — it is the one that does the thing you actually need, without the overhead you do not.
And honestly, a Windows where wslc is just docker is a Windows I want to develop on.