Microsoft Ships WSL Containers to Replace Docker Desktop on Windows
Microsoft shipped a built-in Linux container runtime for Windows, with a CLI, native API, and GPU support, bypassing Docker Desktop entirely.
- Microsoft moved WSL Containers to general availability, shipped via
wsl --updatein WSL 3.0.1. - New wslc.exe CLI uses Docker-style commands, with
container.exeas a built-in alias. - Native Windows API ships as the Microsoft.WSL.Containers NuGet package for C#, C++, and C.
- GPU passthrough, file mounts, health checks, events, and up to 2x faster Windows file access from Linux.
- Intune settings and Defender for Endpoint integration add enterprise controls over containers and registries.
- Docker Compose support (
wsl compose up) is in development but not yet shipped.
Microsoft has released WSL Containers for general availability in WSL 3.0.1. The feature gives Windows developers a first-party way to build, run, and publish Linux containers without installing Docker Desktop or configuring Docker Engine inside a WSL distribution. Install it with wsl --update.
The release has two interfaces: wslc.exe, a Docker-style command-line tool, and the WSL Containers API for applications that need to manage Linux workloads from native Windows code.
WSL gets its own container stack
Developers familiar with Docker will recognize the CLI structure. The executable also supports the container.exe alias, while commands such as wslc run, wslc build, and wslc container list follow Docker-style syntax.
wslc run --rm -it ubuntu:latest
wslc build -t myapp .
wslc container listMicrosoft describes the syntax as Docker-based, but Compose support remains under development. Existing automation should therefore be tested against wslc before migration.
Windows applications can access the API through the Microsoft.WSL.Containers NuGet package. It supports C, C#, and C++, with C# and C++/WinRT projections for managing container lifecycles, standard input and output, file mounts, networking, and GPU access. A native Windows application can use these interfaces to launch a containerized Linux service and communicate with it directly.
| Interface | Primary use | Status |
|---|---|---|
wslc.exe |
Interactive and scripted container workflows | Generally available |
| WSL Containers API | Embedding container management in Windows applications | Generally available |
| C++/WinRT projection | Calling the API from C++/WinRT | Preview; breaking changes remain possible |
The status distinction matters for teams setting compatibility guarantees. WSLC has reached general availability, while Microsoft Learn still labels the C++/WinRT projection as preview.
GA closes the preview gaps
The preview already supported image builds, pulls and pushes, networks, volumes, and GPU access. The general-availability release adds several capabilities needed for routine development and automation:
- Container restarts and configurable stop timeouts
- File copying into and out of containers
- Health checks and real-time container events
- Network connection and disconnection
- Additional mount support and configurable storage
- The
wslc eventscommand --mountand--stop-timeoutoptions for create and run operations
Microsoft also reports up to twice the performance when Linux environments access files stored on Windows. The exact gain will depend on the workload, storage pattern, and host configuration.
Managed-device controls now include two Microsoft Intune policies. Administrators can disable WSL Containers across enrolled devices or restrict image pulls to an approved registry list. Microsoft Defender for Endpoint integration is included as well.
Each user gets an isolated session
WSLC changes how WSL assigns responsibility for container operations. The system service, wslservice.exe, creates a child process named wslcsession.exe instead of retaining ownership of the virtual machine. That child process runs as the calling user and handles container creation, directory mounts, port binding, and other session operations.
Running those operations in a dedicated user process limits the privileges available to the container session and scopes activity to the account that invoked it. This design is relevant on multi-user development machines and CI runners, where a shared system-level daemon can complicate isolation and access control.
Windows apps can launch GPU-backed Linux
Microsoft is targeting local AI execution and cloud-to-local container workflows. With GPU passthrough, a .NET or C++ Windows application can start a CUDA-enabled Linux container through the API, avoiding a separate Docker Desktop installation or a manually configured WSL distribution.
This model suits Windows software that wraps a Linux inference server, agent sandbox, or data-processing pipeline. The host application can manage the container lifecycle while the Linux component retains its existing dependencies and runtime environment.
Editor and framework integrations are also available. VS Code Dev Containers can select wslc as its driver, the VS Code Containers extension can manage WSLC sessions, and .NET Aspire can use WSL Containers as a runtime.
Compose remains the main gap
Multi-container orchestration still requires another tool or a temporary workaround. Microsoft is developing wsl compose up and intends it to consume existing compose.yaml files without modification, but the company has not announced a release date.
Developers can install WSL 3.0.1 with wsl --update or download the latest GitHub release. Microsoft’s architecture deep dive covers the session model and API design in more detail.
Comments
