Windows 11 is now empowering users to natively build, run, and manage Linux containers, fundamentally shifting the paradigm away from a mandatory reliance on Docker Desktop. This significant development, officially termed "WSL Containers" by Microsoft, has just rolled out in public preview. We’ve thoroughly tested this new capability with various real-world scenarios to assess its performance, identify areas where Docker might still be necessary, and provide a guide for getting it operational on your own PC.
It's important to clarify that WSL Container should not be confused with a forthcoming WSL 3; Microsoft previously debunked such rumors. Launched as a public preview, we installed the feature, constructed a custom container image from scratch, and subjected it to multiple workflows to gauge its robustness and utility.
What is WSL Container in Windows 11?
WSL Container is an integrated feature within the Windows Subsystem for Linux (WSL) that enables the direct creation, execution, and management of Linux containers from Windows. Crucially, it achieves this without requiring external third-party runtimes such as Docker Desktop or Podman Desktop. The functionality is delivered through two core components:
- The primary component is wslc.exe, a command-line tool automatically added to your system's PATH upon updating WSL. An alias, `container.exe`, also points to this same binary. Developers familiar with Docker will find the syntax intuitive, as commands like `wslc run`, `wslc build`, and `wslc container list` closely mirror Docker's own structure.
- The second part is a WSL Container API, packaged as a NuGet offering support for C, C++, and C#. This API allows Windows application developers to embed Linux containers directly into their applications. This means a Windows application can seamlessly spin up a Linux container in the background to execute Linux-specific code, then tear it down once the task is complete, without requiring the user to install a separate runtime. Microsoft demonstrated this with Moonray, an open-source Linux rendering engine used in films like "The Wild Robot," running within a Windows executable with no visible indication that Linux was involved.
A key architectural difference lies in isolation: every Windows application leveraging the API is provisioned with its own Hyper-V-backed virtual machine, operating independently of other applications' containers. Similarly, the CLI workflow benefits from its own dedicated VM. In contrast, Docker Desktop typically runs all containers within a single shared virtual machine, which is often more resource-efficient but offers less isolation. WSL Containers prioritize a robust isolation boundary between applications, a design choice that underscores Microsoft’s positioning of this feature as enterprise-ready.
Despite these distinct isolation models, both entry points communicate with the same WSL service that manages your regular Linux distributions. Internally, the container runtime doing the heavy lifting within the Linux VM is Moby, the very open-source engine that powers Docker. This signifies that WSL Containers isn't reinventing containerization but rather providing Windows with a first-party, native gateway to established container technologies.
How to Install WSL Container on Windows 11
Currently, WSL Container is available exclusively through the pre-release channel of WSL. To get started, you'll need to opt into this channel:
- Open Windows Terminal or PowerShell as an administrator.
- Run
wsl --update --pre-releaseand allow the download process to complete.
- Restart WSL using the
wsl --shutdowncommand, then close and reopen your terminal.
- Confirm the installation by running
wslc --version. You should see version number 2.9.3.0, indicating that WSL Container is successfully installed.
- Finally, execute
wslc --helpto display the full command reference and confirm the binary is functional.
On our test machine, the update completed in under two minutes with a stable internet connection. If `wslc` isn't immediately recognized after updating, try restarting your terminal, or if that fails, reboot your PC. Being in a pre-release channel, some rough edges are expected; a few developers have reported an `E_UNEXPECTED` error, though we did not encounter this during our testing. It's worth noting that a Copilot+ PC is not required, but the Hyper-V-backed isolation model necessitates a modern CPU with virtualization enabled in your BIOS or UEFI settings.
Building and Running a Container with wslc
Once `wslc` was operational, we moved beyond basic "hello-world" examples to a more practical use case: building a custom image from a Containerfile and exposing a functional service.
First, as a sanity check, we pulled and ran a Debian container interactively:
wslc run -it debian:latest
Inside the container, executing uname -a yielded a Linux kernel string tied to WSL2, unequivocally confirming that we were operating within a genuine Linux environment rather than a translation layer.
Detaching from the container with Ctrl+P, Ctrl+Q, and then running `wslc ps -a` successfully listed the container by its auto-generated name (e.g., `mossy_sawtooth`), along with its start time and current status.
Reattaching was seamless with wslc attach mossy_sawtooth, dropping us back into the exact same shell.
Next, we created a Containerfile, which functions identically to a Dockerfile, to package a small Linux inspection utility capable of running `file`, `exiftool`, and `binutils` against any input.
The Containerfile looked something like this:
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 it was a straightforward command:
wslc build -t my-linux-inspector .
The build process effectively cached its base layers, allowing subsequent rebuilds to complete in mere seconds. A quick `wslc image ls` command confirmed the local presence of our newly built image with a fresh timestamp.
From there, we initiated the container with a port mapping, enabling the Flask server running inside Linux to be accessed from Windows:
wslc run -d -p 5000:5000 --name inspector my-linux-inspector
Accessing `127.0.0.1:5000` in a browser on the Windows side seamlessly brought up the tool’s web interface, requiring no additional networking setup.
The ability to run a service on a Linux kernel, reachable via `localhost` on Windows, all without any third-party software installations, perfectly encapsulates the power and simplicity of WSL Container.
Testing GPU Access Inside a WSL Container
For developers engaged in AI or machine learning, GPU passthrough is a critical feature, determining whether a Linux container can directly leverage the graphics card rather than being limited to CPU processing. WSL Container seamlessly supports this through the familiar --gpus all flag, mirroring the syntax already known by 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())"A demonstration video illustrates this capability in action: a container directly accessing the GPU, then showcasing a stark performance difference by racing a compiled PyTorch model against the same model in plain eager mode. The performance gap is considerable.
WSL Container for Enterprise Environments
Even in its preview phase, Microsoft is strongly positioning WSL Container as enterprise-ready.
- Microsoft Defender for Endpoint's existing WSL plugin has been enhanced to interpret container events, providing security teams with consistent visibility into container activity without the need for additional specialized tooling. (This specific integration is currently in private preview, requiring a signup).
Furthermore, IT administrators can already manage WSL Container settings via Group Policy and an ADMX policy, with two critical capabilities for enterprise-managed fleets:
- Admins can control whether users within their organization are permitted to utilize WSL distros, containers, or both.
- A highly requested feature: administrators can establish an allowlist of permitted container registries, allowing companies to restrict image pulls to internal or approved repositories, thus preventing unrestricted access to public sources like Docker Hub.
We anticipate comprehensive Intune dashboard support for these settings will follow within weeks of the preview's release.
Developer experience is also being addressed, with VS Code’s Dev Containers extension (starting from version 0.462.0-pre-release) now supporting `wslc`. Integrating it is as simple as updating the Docker Path field in Dev Container settings to `wslc`, eliminating the need to reinstall extensions or reconfigure existing projects.
What is Still Missing from WSL Container?
While WSL Container is a powerful addition, it's still in development and currently lacks certain features. At this stage, it does not include an equivalent to Docker Compose, meaning multi-service projects that rely on `compose.yaml` files to orchestrate components like a database, backend, and cache simultaneously are not yet a good fit. Each container in our tests had to be started individually.
Furthermore, there is currently no graphical user interface (GUI) dashboard, nor features comparable to Docker Scout for image scanning. The extensive plugin ecosystem that Docker Desktop has cultivated over the years also does not exist 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, though these tools are expected to benefit from the same underlying platform improvements.
Speaking of improvements, the platform has seen significant work in areas like networking and file system performance. An experimental mode called Consomme has been introduced for networking, which routes Linux traffic through the Windows networking stack, aiming to resolve long-standing VPN and proxy compatibility issues that have plagued WSL users. Additionally, the new `virtiofs` file system promises to double the speed of Windows file access inside containers. Both `virtiofs` and Consomme are currently exclusive to WSL Container, though Microsoft has indicated plans to eventually bring them to regular WSL distros.
Should You Switch from Docker Desktop Yet?
For specific use cases, such as running a single container for a database or a small service during local development, WSL Container is already a capable solution that eliminates the need for a separate Docker Desktop license. However, for projects that require Compose files, multiple interconnected services, or leverage Docker’s extensive extension ecosystem, Docker Desktop remains the more comprehensive and mature tool for the time being.
Microsoft aims for WSL Container's general availability in Fall 2026. Given the close alignment of its CLI syntax with Docker's, many of the current missing functionalities are likely to be addressed in future updates. If you're already running Linux container workloads on Windows, experimenting with the pre-release build alongside Docker Desktop is a zero-cost way to gain early insight and be prepared for when WSL Container potentially becomes the preferred option.
Comments