Windows 11 has ushered in a significant development, now empowering users to natively build, run, and manage Linux containers directly, bypassing the need for Docker Desktop. Microsoft has named this capability "WSL Containers," and after a thorough hands-on assessment of its public preview with real-world workloads, we're detailing what works seamlessly, what still necessitates Docker, and how you can implement it on your personal computer.
It's crucial not to mistake WSL Containers for a rumored WSL 3; Microsoft explicitly clarified that such a version does not exist. With its recent release as a public preview, we dove in, crafting a custom container image from scratch and putting it through various workflows to gauge its performance and capabilities.
Understanding WSL Container in Windows 11
WSL Container is an integrated feature of the Windows Subsystem for Linux designed to facilitate the creation, execution, and management of Linux containers directly from Windows. This eliminates the requirement for third-party runtimes like Docker Desktop or Podman Desktop. The feature is delivered in two main components:
- The first is wslc.exe, a command-line utility automatically added to your PATH upon updating WSL. Microsoft also provides an alias, `container.exe`, which points to the same binary. Its syntax, with commands such as `wslc run`, `wslc build`, and `wslc container list`, will feel highly familiar to anyone accustomed to Docker.
- The second component is the WSL Container API, distributed as a NuGet package, offering support for C, C++, and C#. This API enables Windows application developers to embed Linux containers directly within their own applications.
Instead of requiring users to install a separate runtime, a Windows application can silently launch a Linux container in the background to execute Linux-specific code, then dismantle it once the task is complete. Microsoft showcased this with Moonray, an open-source Linux rendering engine utilized in films like "The Wild Robot," running within a Windows executable with no discernible indication of Linux involvement.
Each Windows application leveraging this API receives its own Hyper-V-backed virtual machine, providing strong isolation from other applications' containers. Similarly, the CLI flow also gets its dedicated VM. In contrast, Docker Desktop typically runs all containers within a single shared VM, which offers greater resource efficiency.
WSL Containers prioritize a robust isolation boundary between applications over some resource efficiency, positioning it as an enterprise-ready solution by Microsoft.
Regardless, both entry points communicate with the same WSL service that already manages your regular Linux distributions. Internally, the container runtime performing the heavy lifting is Moby, the open-source engine that also powers Docker. It's important to note that WSL Containers isn't reinventing containers but rather providing Windows with a native, first-party interface to them.
Installing WSL Container on Windows 11
Currently, WSL Container is exclusively available through the pre-release channel of WSL. To get `wslc` on your system, you'll need to opt into this channel:
- Launch Windows Terminal or PowerShell with administrator privileges.
- Execute `wsl --update --pre-release` and allow the download process to complete.
- Restart WSL using the `wsl --shutdown` command, then close and reopen your terminal.
- Verify the installation by running `wslc --version`. You should see version number 2.9.3.0, confirming WSL Container is installed.
- To view the complete command reference and confirm the binary's functionality, run `wslc --help`.
In our testing environment, the update completed in under two minutes with a stable internet connection. If `wslc` isn't recognized immediately after the update, try restarting your terminal; if the issue persists, a PC reboot may resolve it. As this is a pre-release feature, some rough edges are expected, with a few developers reporting a "Catastrophic failure, Error code: E_UNEXPECTED" during their initial container runs on Microsoft's devblog. Fortunately, we did not encounter this specific issue.
It's worth noting that a Copilot+ PC isn't necessary to try this feature, as WSL Container ships as a standard WSL component. However, its Hyper-V-backed isolation model relies on modern virtualization support, so a recent CPU with virtualization enabled in the BIOS or UEFI is more critical here than for a typical WSL distro.
Building and Running Containers with `wslc`
Once `wslc` was operational, we bypassed the customary "hello-world" example and moved directly to a more practical scenario: building a custom image from a `Containerfile` and exposing a functional service from it.
First, as a basic check, we interactively pulled and ran a Debian container:
`wslc run -it debian:latest`
Inside the container, executing `uname -a` returned a Linux kernel string linked to WSL2, verifying that we were indeed within a genuine Linux environment, not a mere translation layer.
After detaching with Ctrl+P, Ctrl+Q, we used `wslc ps -a` to list the container by its autogenerated name (e.g., "mossy_sawtooth"), displaying its uptime and current status.
Reattaching was straightforward with `wslc attach mossy_sawtooth`, which dropped us back into the identical shell session.
Next, we authored a `Containerfile`—which functions identically to a Dockerfile—to package a small Linux inspection utility. This tool runs `file`, `exiftool`, and `binutils` against any input provided.
The `Containerfile` content was structured approximately as follows:
FROM python:3.12-slim
RUN apt-get update && \
apt-get install -y --no-install-recommends \
file exiftool binutils bsdmainutils coreutils && \
rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]Building the image required a single command:
`wslc build -t my-linux-inspector .`
The build process efficiently cached its base layers, allowing subsequent rebuilds to finish in seconds rather than minutes. Running `wslc image ls` confirmed the local existence of the image with a recent timestamp.
Subsequently, we launched the container with a port mapping, enabling the Flask server operating within Linux to be accessible from Windows:
`wslc run -d -p 5000:5000 --name inspector my-linux-inspector`
Navigating to `127.0.0.1:5000` in a browser on the Windows side successfully brought up the tool's web interface, without any additional network configuration needed.
This demonstration—a service running on a Linux kernel, reachable via localhost on Windows, and with no third-party software installed—effectively encapsulates the essence of WSL Container.
GPU Access Within a WSL Container
For developers engaged in AI or machine learning, GPU passthrough is often the most critical feature, as it dictates whether a Linux container can leverage the graphics card instead of relying solely on the CPU. WSL Container facilitates this through the `--gpus all` flag, a syntax familiar to Docker users:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \
python -c "import torch; print(torch.cuda.is_available())"Our tests confirmed this functionality, showing a container directly accessing the GPU, then benchmarking a compiled PyTorch model against the same model running in plain eager mode, highlighting a significant performance difference.
WSL Container for Enterprise Environments
Even in its preview stage, Microsoft is positioning WSL Container as enterprise-ready.
The existing WSL plugin for Microsoft Defender for Endpoint now comprehends container events, offering security teams monitoring WSL distros the same level of visibility into containers without requiring separate tools. This particular capability is currently in a private preview phase with its own signup process.
IT administrators can already manage WSL Container via Group Policy and an ADMX policy, with two key features vital for a managed corporate fleet:
- Administrators can control whether users in their organization are permitted to utilize WSL distros, containers, or both.
- Crucially, a frequently requested customer feature, admins can establish an allowlist of approved container registries. This enables companies to restrict image pulls to internal or sanctioned registries, rather than leaving Docker Hub broadly accessible.
We anticipate comprehensive Intune dashboard support for these settings to become available within a few weeks of the preview's release.
Furthermore, VS Code's Dev Containers extension has integrated `wslc` support starting with version 0.462.0-pre-release. Switching to it merely involves opening Dev Container settings, locating the Docker Path field, and changing it to `wslc`, eliminating the need to reinstall extensions or reconfigure existing projects.
Current Limitations of WSL Container
At this juncture, WSL Container does not include any equivalent to Docker Compose. Consequently, multi-service projects that rely on a `compose.yaml` file to orchestrate a database, backend, and cache together are not yet well-suited for this platform. Each container in our tests had to be initiated individually.
A notable omission is the absence of a GUI dashboard or tools akin to Docker Scout for image scanning. Additionally, the extensive plugin ecosystem that Docker Desktop has cultivated over the years is not present here. It's important to understand that WSL Container is not intended to be a direct replacement for Docker Desktop, Podman Desktop, or Rancher Desktop. In fact, these existing tools stand to benefit from the same underlying platform advancements, including the new virtiofs file system, which Microsoft states makes Windows file access twice as fast within containers.
Networking has also seen improvements with an experimental mode called Consomme. This mode routes Linux traffic through the Windows networking stack, an alternative to the older NAT setup, aimed at resolving the long-standing VPN and proxy compatibility issues that have frustrated WSL users. Both virtiofs and Consomme are currently exclusive to WSL Container, though Microsoft has indicated plans to eventually integrate them into regular WSL distros.
Is It Time to Transition from Docker Desktop?
For single containers running a database or a modest service during local development, WSL Container already provides a capable solution without requiring a separate license. However, for projects that demand Compose files, interconnected multi-service architectures, or Docker's rich extension ecosystem, Docker Desktop remains the more comprehensive tool for now.
Microsoft projects general availability for WSL Container in fall 2026. Given how closely the CLI's syntax already mirrors Docker's, many of the missing features appear to be a matter of future implementation rather than fundamental architectural limitations.
If you're already managing Linux container workloads on Windows, running the pre-release build alongside Docker Desktop incurs no cost and allows you to get a head start with WSL Container before it potentially becomes a default choice for many.
Comments