On September 29, 2026, Microsoft made WSL Containers (WSLC), a Linux container platform built into Windows Subsystem for Linux (WSL), generally available. You can install it with wsl --update, then use wslc.exe to build container images and to run and manage Linux containers. Microsoft also provides an API for Windows apps to control Linux containers, offered as an official way to develop against WSLC.
But if you understand it only as "Docker-like commands have been added to Windows," you miss what makes this design distinctive.
Microsoft did not simply add a container engine inside the WSL distributions people already use. It built a container runtime in which Windows manages dedicated WSLC sessions, storage, and networking, and which can be tied into enterprise monitoring and policy.
There are now more situations where you can work with Linux containers without Docker Desktop. At the same time, WSLC cannot currently serve as a drop-in replacement for Docker Desktop.
WSL now has a built-in container runtime
WSL Containers was released as a public preview on June 29, 2026, in WSL 2.9.3. At that stage, you had to install the preview build of WSL with wsl --update --pre-release.
With general availability roughly three months later, Microsoft now says WSLC can be used with the regular wsl --update. Both the CLI and the API are offered as official features for using Linux containers on Windows.
The CLI comes with wslc.exe, and there is also an alias, container.exe, that invokes the same commands.
Even in the public preview, it supported building, pulling, and pushing container images, as well as creating and running containers. It could also manage networks and volumes and use GPUs.
By general availability, the following had been added:
wslc container restartto restart a running containerwslc container cpto copy files to and from containerswslc system infoto check the state of the whole runtime- Connecting to and disconnecting from networks
- Real-time display of container events
- Health checks
--mount--stop-timeout, which sets how long to wait before stopping- Changing the storage location of the default session
The other way to use it is the WSL Containers API for Windows apps.
From languages such as C# and C++, you can pull images, create and start containers, and work with standard input/output, file sharing, networking, and GPUs. It is intended for uses such as running part of a Windows app's processing in a Linux environment, or building containers into build and test workflows.
However, not every part of the API has reached the same level of maturity. Microsoft Learn says the projection for C++/WinRT is still in preview and may receive breaking changes.
It is important to distinguish WSLC as a whole becoming generally available from the APIs for every language and development environment becoming stable at the same time.
The way virtual machines are managed differs from regular WSL
What distinguishes WSLC is also reflected in which process manages the virtual machines and container sessions.
As with regular WSL, requests from clients are sent to wslservice.exe, a highly privileged Windows service that can create virtual machines.
In WSLC, however, wslservice.exe does not keep managing the virtual machine itself.
Instead, it launches a child process, wslcsession.exe, that runs with the privileges of the user who made the request. This process handles the work of each session, such as creating containers, sharing directories, and assigning network ports.
Microsoft explains that separating sessions into different processes, and performing actual operations in a process with fewer privileges than wslservice.exe, strengthens isolation and security boundaries between sessions.
A "session" here does not mean a single container.
One WSLC session can contain multiple images, containers, networks, and volumes, and its state is stored in a session-specific VHD.
When created from wslc.exe, the default VHD location is %AppData%\Local\wslc\sessions.
Several storage methods are also available.
To pass a Windows folder to a container, it is shared to the Linux virtual machine via virtiofs and then bind-mounted into the container from there.
If you need a Linux-specific file system or want to limit volume capacity, you can create a VHD-backed volume.
Microsoft says virtiofs is up to about twice as fast at accessing Windows files as the Plan 9 method used previously.
However, the published materials do not disclose the hardware used for the comparison, the specific workloads, absolute transfer speeds, or measurement variance. Nor is it a comparison against Docker Desktop, so it does not mean "WSLC is twice as fast as Docker Desktop."
"Consommé" handles Linux traffic from the Windows side
Networking uses a new mechanism called "Consommé."
Ethernet frames sent from the Linux virtual machine are passed to the Windows side through virtio queues and received by a Windows process running with the privileges of the WSLC session's user.
This process handles:
- Responding to DNS queries
- Relaying TCP/UDP traffic
- Port mapping
The key point is that traffic leaving the Linux side for external destinations is treated as traffic sent from a Windows process belonging to the user who owns the WSLC session.
This makes it easier to maintain compatibility with VPNs, firewalls, and enterprise network settings used on the Windows side.
In other words, Consommé is less a mechanism for simply speeding up container traffic than a design meant to make it easier to integrate Linux container networking with the Windows network stack.
"Pre-release" labels remain after general availability
As of September 30, the day after the announcement, the general availability announcement did not match every document and distribution page Microsoft publishes.
The Windows Developer Blog and the WSLC architecture explanation state that WSL Containers is generally available from September 29 and direct users to the regular wsl --update for installation.
Meanwhile, as of September 30, Microsoft Learn still contains wording saying that WSL 2.9.3 or later, which WSLC requires, is "currently available only as a pre-release," and some pages still point to wsl --update --pre-release.
WSL 2.9.13, published on GitHub on September 25, also still carries a "Pre-release" label.
This does not mean the general availability of WSLC has been withdrawn. Microsoft's own September 29 announcement clearly declares GA.
It is reasonable to assume that, immediately after the product's status changed, some information, such as Learn documentation and GitHub release labels, had not yet been updated.
What matters to users is less the inconsistency itself than which version is actually being delivered to their machines.
The surest approach is to first run:
wsl --update
wsl --version
wslc versionand check which versions of WSL and WSLC were installed in your environment.
Companies that roll out Windows and WSL updates in stages should likewise not assume WSLC is available just because it was announced as generally available; they need to check which version has reached their own update rings.
Docker Desktop-free use has widened, but it is not a complete replacement
For basic uses such as building and running Linux container images and assigning ports and volumes, WSLC alone can be enough in many cases.
As examples of support at general availability, Microsoft cites:
- VS Code Dev Containers
- Aspire
- The VS Code Containers extension
Because the CLI is designed with developers who have used Docker in mind, the burden of relearning basic container operations is small.
However, having Docker-like commands is not the same as being compatible with Docker Engine itself.
The biggest difference is Compose.
Microsoft names Compose support as its top-priority feature to work on after general availability, with the goal of running an existing compose.yaml unchanged via wsl compose up.
In other words, the ability to bring up multiple containers together with Compose was not complete at the time of general availability. No timeline has been given.
Compatibility with the Docker Engine API also calls for caution.
On Microsoft's GitHub, a request for a Docker-compatible API that can be reached through DOCKER_HOST remains unresolved. The post cites reasons why compatibility with the Docker CLI, Compose, Testcontainers, buildx, and others is needed.
This is a feature request from users, not a specification Microsoft has formally promised to support.
Therefore, whether you can migrate from an existing Docker environment should be judged not by whether the CLI command names look similar, but by what mechanisms your project depends on.
Image builds using Dockerfiles, running single containers, and development tools with explicit WSLC support are relatively easy to migrate.
On the other hand, if you use any of the following, you need to check compatibility in your actual projects:
- Docker Compose
- Test tools that assume the Docker socket or the Docker Engine API
- Builds for multiple architectures
- Docker Desktop-specific GUI features or extensions
WSLC has become a strong option distinct from Docker Desktop, but it is not a substitute that can replace an existing Docker environment as is.
For enterprises, integration with Windows management and security matters
For enterprise use, what matters is not only that Linux containers can be started on Windows.
Microsoft is extending WSLC's features so that it can be handled through Windows management and security mechanisms.
In Intune, in addition to settings that enable or disable WSL Containers itself, you can use an allowlist to restrict the registries from which container images can be pulled.
This makes it possible to limit developers from freely pulling images from registries the organization has not approved.
For the WSL plugin for Microsoft Defender for Endpoint (MDE), a mechanism is also provided that captures process, file, and network activity inside WSLC and lets you review it in the Defender portal while preserving its relationship to the Windows host.
However, as of September 30, WSLC support in the MDE plugin is described as being in public preview. The fact that WSLC itself is generally available does not mean all related enterprise security features became GA at the same time.
Being able to see activity is also not the same as being able to detect or prevent every attack.
Microsoft's materials explain that file, process, and network events can be viewed from the WSL plugin and used for alerts, incidents, Advanced Hunting, and more, while also noting that some Defender features are limited in WSL environments.
When enterprises adopt it, they will need to verify in real environments:
- How operations inside containers are recorded in a device's timeline and alerts
- Whether the registry allowlist interferes with existing internal registries or CI/CD environments
- How much storage the per-session VHDs consume
- Whether Consommé works as expected in VPN, proxy, and firewall environments
Whether WSLC can become the standard choice for running Linux containers on Windows will not be decided by the "up to twice as fast file access" figure alone.
Will Compose support that works with an existing compose.yaml unchanged materialize? How will the gap with surrounding tools that assume the Docker Engine API be bridged? Will Microsoft's documentation and the stable channel's labels align with the post-GA state? And will enterprise monitoring and management features be completed as stable releases?
Once those are in place, enterprises will find it easier to treat Linux containers not as a development environment managed separately from Windows, but as a runtime managed within Windows updates, monitoring, and security policy.