Windows Native Linux Containers Arrive: Can WSL Containers Replace Docker?

Clarification: This Is Not WSL 3

Microsoft announced WSL Containers at Build 2026, entering public preview in late June. Product manager Craig Loewen explicitly clarified that this is not "WSL 3" — there is no WSL 3. Instead, WSL Containers is a new capability layer built on top of the existing WSL 2 infrastructure. It does not replace your installed distributions, configurations, or data; it simply adds container build, run, and debug capabilities directly into WSL.

Previously, running Linux containers on Windows required Docker Desktop or Podman. Now WSL itself provides those capabilities natively.

wslc.exe: Docker-Compatible CLI

After updating to the WSL pre-release version, a new wslc.exe binary appears in PATH, with an alias container.exe. The command syntax deliberately mirrors Docker to preserve existing muscle memory.

Examples from the official blog demonstrate the similarity:

wslc run -d --name=webtop -e PUID=1000 -e TZ=Etc/UTC -p 3000:3000 lscr.io/linuxserver/webtop:ubuntu-kde

Parameters such as -d (detached), -e (environment variables), and -p (port mapping) work identically to docker run. Images are pulled directly from public registries.

For AI/ML workloads, GPU passthrough works with --gpus all:

wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available())"

A noted gotcha: wslc start hello-world fails with "Catastrophic failure" because start only resumes stopped containers, while run pulls images and creates containers — matching Docker semantics but with a rough error message in preview.

Container API for Windows Applications

Beyond the CLI, Microsoft released a NuGet package supporting C, C++, and C# that lets native Windows applications create, run, and manage Linux containers programmatically. Three primary use cases:

Reuse Linux-only code : Legacy code that only compiles on Linux no longer requires a separate build machine.

Localize cloud applications : Run cloud-deployed containers locally with identical environments.

Resource isolation : Confine a Linux process's access to host resources within a container.

Integration with MSBuild and CMake allows container build and deploy steps to become part of the standard compilation pipeline with just a few lines of project configuration.

Craig Loewen confirmed in blog comments that the WSL Container API will support production use, moving beyond the previous "development and testing only" guidance for WSL.

Underlying Improvements: 2x File Speed, New Network Mode, Memory Reclamation

Three core WSL upgrades accompany the container feature, benefiting all WSL users:

virtiofs as default filesystem for WSL Containers : Windows file access speed doubles, addressing the long-standing "/mnt/c" performance pain point.

New default network mode "consomme" : Linux network traffic relays through the Windows side, improving compatibility with VPNs, proxies, and corporate network policies — historically a major WSL networking headache.

Improved memory reclamation : Unused memory in the Linux VM is gradually and stably returned to the Windows host, mitigating the "vmmem only grows" complaint.

⚠️ These changes currently only activate by default within WSL Containers; Microsoft plans to roll them out to standard WSL later.

Microsoft emphasized that third-party tools built on WSL — Docker Desktop, Podman Desktop, Rancher Desktop — will also benefit from these lower-level improvements.

Reality Check: Too Early to Uninstall Docker

Despite the promise, the preview has concrete gaps that prevent it from replacing Docker for most workflows:

No docker compose support : The most-requested feature in official blog comments; Craig Loewen acknowledged it as "highest demand" and said they are researching the best implementation.

No USB passthrough : --device and --privileged flags have no equivalent in wslc yet, blocking hardware development board workflows.

Network edge cases : Users report containers can reach LAN machines but cannot access web services running on the Windows host itself.

Ecosystem catching up : VS Code Dev Containers added wslc support in pre-release 0.462.0 (by setting "Docker Path" to wslc), but full GA integration remains.

Recommendation: Experiment with wslc, but keep Docker as the primary workflow through at least 2026.

Enterprise Angle: Security and Governance Built In

Enterprise readiness features launched alongside the preview:

Security monitoring : Microsoft Defender for Endpoint's WSL plugin now monitors container security events, currently in public preview.

Unified management via GPO/Intune : IT can control which WSL distributions or containers are allowed, and configure image registry allowlists — directly addressing the compliance question of "which images may be pulled."

This combination signals Microsoft's intent to make IT departments comfortable enabling WSL Containers on corporate devices.

Quick Start: Three Commands

wsl --update --pre-release   # Upgrade to pre-release (2.9.3+)
wsl --shutdown               # Restart WSL, reopen terminal
wslc --version               # Verify 2.9.3.0

Then run a test container. Verified working on ARM devices (e.g., Surface).

Side note: Craig Loewen built a community TUI tool called lazywslc in his spare time, available on GitHub — a sign of internal investment.

Target GA timeline: Fall 2026, likely aligning with a major Windows update.

Implications for Ubuntu on WSL

Canonical VP Jon Seager previously predicted Ubuntu on WSL would surpass native Linux installs. WSL Containers reinforces that trajectory: containers are the heart of developer workflows, and when Windows runs Linux containers well, the "Windows desktop + Ubuntu toolchain" combination becomes exponentially stickier — no context switching between meeting/docs on Windows and build/deploy in Ubuntu. The first distro most users install in WSL remains Ubuntu.

Bottom Line

WSL Containers isn't trying to kill Docker; it's making "container" a Windows built-in capability — analogous to browsers bundling PDF readers. Third-party tools will persist, but for most users, the day of not needing a separate container runtime is approaching.

For developers before fall 2026: treat wslc as a secondary container toolkit; let Docker hold the primary line.