# WSL Container WSL Container is Microsoft's **built-in Linux container runtime for Windows**: create, run, and manage Linux containers natively, without Docker Desktop or any third-party tooling. Generally available since 29 September 2026, after a public preview in WSL pre-release builds that started in June 2026. The code is open source, in the same `microsoft/WSL` repository as WSL itself. Where classic [[Windows Subsystem for Linux (WSL)]] gives you full Linux distributions, WSL Container adds two things on top: 1. **`wslc.exe`**: a container CLI with Docker-like syntax 2. **A programmatic API** (NuGet package for C, C++, C#) so Windows applications can run Linux containers as an implementation detail, integrated with MSBuild and CMake That second one is the strategically interesting part: a Windows app can now embed Linux-only code by building and running a container at compile time, making containers a language feature of the Windows toolchain rather than a separate ops tool. ## Technical notes - Uses **virtiofs** (about 2x faster file access) and "consomme" networking by default; both ahead of what standard WSL ships - VS Code [[Devcontainers]] supported - Enterprise hooks: Microsoft Defender for Endpoint integration (private preview), Intune management with container-registry allowlists - Current gaps: no USB passthrough, no Docker Compose equivalent ## Architecture Microsoft published an architecture write-up on GA day (Pierre Boulay, Microsoft Command Line blog). WSLC reuses the WSL plumbing, but it changes who owns the virtual machine and who sends the network traffic. ### Session model - Two entry points, one service. `wslc.exe` and Windows apps (which load `wslcsdk.dll` with `LoadLibrary()`) both call `wslservice.exe` over COM. That's the same privileged Windows service classic WSL uses, and it creates the Linux VM through HCS (the Windows Host Compute Service, on top of [[Hyper-V]]) - The service doesn't keep ownership of the VM. It launches a child process, `wslcsession.exe`, which runs as the calling user and does all the session work: creating containers, mounting directories, binding ports - `wslcsession.exe` talks to **moby** inside the Linux VM through a REST API over hvsocket, and moby manages the containers. Moby is the open source engine [[Docker]] is built from, which explains why `wslc` feels so much like `docker` - Why split it like this? Each session lives in its own process, so sessions are isolated from each other. And container operations run with the user's rights, not those of the privileged service ### Storage - **Session VHD**: every session gets its own virtual disk holding its state (images, containers, networks, volumes). With `wslc.exe`, those live in `%AppData%\Local\wslc\sessions` - **Path volumes**: `wslc container run -v C:\path:/volume ...` shares a Windows folder with a container. Under the hood, the session mounts a virtiofs share under `/mnt` in the VM, then bind-mounts it into the container. Volumes are how data survives; the container's scratch space is thrown away when the container is deleted - **virtiofs** is a filesystem designed for sharing files between a hypervisor and a VM. Microsoft says it's about twice as fast as plan9; that's where the "2x" figure comes from - **VHD volumes**: `wslc volume create --driver vhd -o SizeBytes=200000000 my-volume` creates a volume backed by its own VHD (ext4 inside). Use it when a container needs a native Linux filesystem or a hard size limit. Several containers can mount the same volume by name ### Networking (Consommé) - The VM sends all its traffic as Ethernet frames into a virtio queue. A Windows process running as the user reads that queue and provides DNS answers, TCP/UDP routing and port mapping. Inside the VM, container traffic goes through a veth adapter and NAT to `eth0` - That user-level process gives WSLC fine control over things like port mapping and host loopback, while staying inside the Windows networking stack - Outgoing traffic leaves on behalf of the session's owner, as if a regular Windows process sent it. So [[Virtual Private Network (VPN)|VPNs]] and [[Firewall|firewalls]] treat it like any other app, which is what you want on a locked-down corporate laptop ## Why it matters This is Microsoft going after the [[Docker]] Desktop license line item. For teams that only need `docker run`-level workflows on Windows (including sandboxing [[AI Agents]]), the built-in path now exists, with enterprise policy control that Docker Desktop can't match on Windows. Compose-dependent workflows still need Docker or Podman. ## References - [Announcement](https://devblogs.microsoft.com/commandline/wsl-container-is-now-available-for-public-preview/) - [WSLC architecture deep dive](https://devblogs.microsoft.com/commandline/wslc-architecture-deep-dive/) (Pierre Boulay, Microsoft Command Line blog, 29 September 2026) - [General availability announcement](https://blogs.windows.com/windowsdeveloper/2026/09/29/wsl-containers-now-generally-available/) - [Source code (microsoft/WSL)](https://github.com/microsoft/wsl) ## Related - [[Windows Subsystem for Linux (WSL)]]: the substrate - [[Docker]]: what it partially replaces on Windows - [[Docker Sandboxes]]: the agent-sandboxing use case this also serves - [[Docker Desktop]]: the bundle it competes with for `docker run`-style workflows - [[Hyper-V]]: the hypervisor under the utility VM (created through HCS) - [[Containerization]] - [[Microsoft eXecution Container (MXC)]]: lists WSLC as one of its Windows isolation backends