The short answer
Linux containers are now a native, centrally managed part of Windows: after wsl --update, developers get wslc.exe to build and run containers, and IT gets Intune switches and a registry allowlist to control them. For teams that run cloud and DevOps pipelines on Linux but give engineers Windows laptops, this narrows the gap between the local machine and CI without another licensed desktop tool.
The catch is Docker Compose. Microsoft says wslc compose is the top feature request and is still coming, so multi-service local stacks should not switch yet. Single-container builds, tests and VS Code dev containers can start piloting now.
What did Microsoft ship with WSL Containers?
WSL Containers adds container tooling to the Windows Subsystem for Linux itself. Developers use wslc.exe to build, run and deploy Linux containers, and a container.exe alias keeps muscle memory from other container CLIs working. A WSL containers API lets Windows applications start Linux containers programmatically; Thurrott reports C++ and C#/WinRT bindings.
Compared with the preview, the GA release adds commands to restart containers, copy files in and out, inspect the environment with wslc system info, connect and disconnect networks, and stream live container events. Health checks, a configurable stop timeout, --mount support and a configurable storage path are also in. Microsoft claims up to 2x faster access to Windows files from Linux and introduces a new network mode, consomme, aimed at networking compatibility.
The ecosystem is already wired in. VS Code dev containers can use wslc as their default driver, the VS Code container extension works with it, and .NET Aspire can treat WSL containers as a container runtime, according to Microsoft’s announcement and BleepingComputer’s report.
Can it replace Docker Desktop today?
For part of the workload, yes; for the whole workstation, not yet. Building an image, running a test container or opening a repository in a dev container no longer requires a separate desktop product on Windows. That matters commercially: under Docker’s subscription terms, organizations above 250 employees or $10 million in annual revenue need a paid plan to use Docker Desktop.
The gap is orchestration of local stacks. Many teams start their API, database, queue and cache with one compose.yaml. Microsoft says the goal is for existing Compose files to work unchanged, but that support has not shipped. Local Kubernetes workflows, image signing and registry mirrors also need their own tests before anyone removes an existing tool from a fleet.
What it means for US & EU software teams
First, the container supply chain now starts on a managed endpoint. The Intune registry allowlist lets IT restrict which registries developers can pull from, which closes a common gap: engineers pulling unvetted public images on laptops that also hold source code and cloud credentials. For teams working toward SOC 2 or ISO 27001, an enforced allowlist is easier to evidence than a written policy.
Second, security teams gain visibility they often lacked. Container processes on developer machines were a blind spot for many endpoint tools. With the Defender for Endpoint plugin surfacing process, file and network activity tied to the Windows host, a malicious package running inside a build container becomes an investigable event rather than a gap in the timeline. That is relevant after this year’s wave of npm and extension supply-chain attacks that targeted developer machines.
Third, tool consolidation is now a real budget line. Where a Windows fleet used Docker Desktop mainly for single-container builds and dev containers, the licensing case changes. Where it depends on Compose, Kubernetes integrations or Docker-specific extensions, it does not change yet. Decide per workflow, not per company.
How to pilot it
- Pick one repository. Choose a service that already uses a dev container or a single Dockerfile, and have two or three engineers run it on
wslcfor two weeks. - Enable the registry allowlist first. Point it at your private registry or mirror so the pilot does not normalize direct pulls from public registries.
- Check parity with CI. Build the same image locally and in the pipeline, compare digests and test results, and note any networking or mount differences.
- Measure file-heavy workloads. Test install, build and test times on repositories with many small files, where the 2x file-access claim should show up.
- Hold Compose stacks. Keep existing tooling for multi-service setups and re-test when
wslc composeships.
Frequently asked questions
What are WSL Containers?
WSL Containers is a Windows Subsystem for Linux feature that lets developers build, run and deploy Linux containers directly on Windows. It ships a command-line tool, wslc.exe, with a container.exe alias for familiar container commands, plus an API that Windows applications can call to run Linux containers. Microsoft made it generally available on September 29, 2026, after a public preview earlier in the year.
How do I install WSL Containers?
Microsoft says the feature arrives with a WSL update: run wsl --update, or install the release from the WSL GitHub releases page. After that, wslc.exe is available from the command line. In managed fleets, check first whether IT has enabled the Intune setting that allows WSL containers access.
Does WSL Containers replace Docker Desktop?
Not fully yet. It covers building and running individual containers and already works as the default driver for VS Code dev containers, but Docker Compose support is still on the roadmap; Microsoft calls it the top feature request. Teams whose local stacks depend on compose.yaml should keep their current tool until wslc compose ships and they have tested it.
What enterprise controls come with WSL Containers?
Two Intune settings let administrators allow or block WSL containers and restrict image pulls to an approved registry allowlist. A Microsoft Defender for Endpoint plugin surfaces process, file and network activity from containers, tied to the Windows host, so security teams can investigate container activity without a separate workflow.
Is WSL Containers faster than running containers in a VM?
Microsoft claims up to 2x faster access to Windows files from Linux environments and adds a new network mode, called consomme, for better networking compatibility. These are vendor figures; benchmark your own build and test workloads, especially repositories with many small files, before standardizing on it.
Sources
Windows Developer Blog — WSL containers is now generally available (Logan Iyer, Microsoft)
BleepingComputer — Microsoft is rolling out Linux container support to WSL
Help Net Security — WSL containers are generally available on Windows
Thurrott.com — Microsoft releases WSL Containers for Windows 11