Microsoft's WSL Containers Kill Docker Desktop's Grip on Windows Dev

Introduced at Microsoft Build 2026, WSL containers bring Linux container development directly into Windows through WSL, providing a built-in, enterprise-ready way to create, run, and manage Linux containers without requiring additional third-party tooling. The feature just hit public preview in WSL 2.9.3, and it ships two things developers have wanted for a long time: a Docker-compatible CLI that runs from any Windows terminal, and a native API so Windows apps can embed Linux containers in their own logic.

The problem it solves

For years, running Linux containers on Windows meant relying on third-party tooling, with Docker Desktop as the dominant intermediary. That added abstraction, licensing complexity, and resource overhead. The community workaround , installing Docker Engine directly inside a WSL distro , works, but it means managing a Linux daemon, keeping it running, and losing the clean Windows-native integration that most teams actually want. WSL containers collapse that stack.

Two new pieces: a CLI and an API

The WSL container feature has two major components: a CLI called wslc.exe to build, run, and interact with Linux containers, and a WSL container API allowing Windows app developers to use Linux containers as part of their app logic.

When you update to the latest WSL version, you get a new binary on your path: wslc.exe. You can use it for your full Linux container development workflows, including running, debugging, and testing. The CLI has a familiar format, meaning you can use your existing muscle memory when running Linux containers. There is also a built-in alias container.exe which just runs wslc.exe, so you can use either command.

GPU support works out of the box. Throw --gpus all on a PyTorch container and CUDA just works, no convoluted config required. That is huge for anyone doing local AI development on Windows , you can finally train or run inference inside a clean container without wrestling with drivers.

On the API side, Windows applications can now directly use containers as part of their application logic. WSL ships a NuGet package available at nuget.org and on the WSL releases page, with support for C, C++, and C#. The API connects to MSBuild and CMake, so a few lines in a project file fold the container build and deploy steps into an application's own build.

Under the hood: isolation and performance

WSL containers do not run in your standard WSL distributions. Instead, every application and CLI session spawns its own lightweight Hyper-V utility VM in the background, which reduces the chances of one app snooping on the container of another. This per-session isolation is a meaningful security upgrade over the shared-daemon model Docker uses.

The team also shipped three platform-level improvements that underpin the whole feature:

• A new default file system, virtiofs, makes Windows file access twice as fast.
• A new default networking mode, consomme, relays Linux network traffic through Windows so Linux applications inherit the host's networking environment, security policies, and enterprise integrations.
• Memory reclaim improvements return unused memory to the Windows host on a steady schedule, releasing it once the Linux VM stops needing it.

These changes touch file system access and networking, so they run in WSL containers for the present, with broader rollout to WSL planned for the future. Notably, Docker Desktop, Podman, and Rancher Desktop are not going anywhere , Microsoft clarifies that these tools will also benefit from the low-level changes brought by WSLC.

Enterprise and VS Code integration

The existing Microsoft Defender for Endpoint plugin for WSL now reads Linux container events, giving the same security coverage across distributions and containers. On the management side, admins can control which container registries are allowed in their organization via GPO and ADMX policy today, with Intune dashboard support coming in the next few weeks.

VS Code Dev Containers gained wslc support in release 0.462.0-pre-release. The setup needs one change: open the dev container settings, find the Docker Path field, and set it to wslc.

What it is good at , and where to be careful

The practical use-cases where WSLC shines today:

• Local AI/ML workloads with GPU passthrough (PyTorch, CUDA)
• Running cloud-native apps locally without a Docker daemon
• Embedding Linux containers inside native Windows apps via the C/C++/C# API
• Reusing Linux-specific code in a Windows build pipeline
• Isolated, per-session container environments for security-conscious teams

If your workflow cannot tolerate breaking changes, changed behavior, incomplete documentation, or support ambiguity, WSLC is not ready to be your only container path. Docker Compose compatibility, a full enterprise support matrix, and production hardening are still gaps to watch. The better move is selective adoption: test WSLC for local Linux-container workflows, keep Docker Desktop where teams depend on mature tooling, and wait for GA before making it a standard enterprise baseline.

How to get started

Getting the preview takes a single command:

wsl --update --pre-release
wslc version
wslc run --rm hello-world

From there, GPU workloads, image management, and port forwarding all work with familiar syntax. The official docs have in-depth guides and sample code, and the GitHub samples repo has ready-to-clone projects for the C/C++/C# API.

The bigger picture

The preview turns WSL from a compatibility layer and developer convenience into something closer to a first-party Linux container substrate for Windows. Microsoft is not merely smoothing the path for Docker Desktop users; it is trying to own more of the developer workflow that has historically leaked out of Windows. It is a first-party attempt to make Linux containers feel like a native Windows capability. If Microsoft can turn this preview into a stable, governable, fast default, the next generation of Windows development setups may spend less time explaining how to get Linux containers working and more time assuming they already do.

Microsoft aims to make this feature generally available in the upcoming fall of 2026. It is free , no licensing fees, no paid tier. Feedback goes to the WSL GitHub repo.