WSL containers reach GA with a wslc CLI and Intune control of registries
Serguey Asael Shinder1 min readMicrosoft has made WSL containers generally available, letting developers build, run and deploy Linux containers on Windows through the Windows Subsystem for Linux itself. The announcement, published on the Windows Developer Blog on 29 September by Logan Iyer, corporate vice president for Windows platform and developer, says it is available after running wsl --update.
There are two ways in. The wslc.exe command-line tool builds, runs and deploys containers, with a built-in alias, container.exe, for familiar container commands. A WSL containers API lets native Windows applications run Linux containers programmatically, which Microsoft pitches for local AI workloads and for running cloud-based containerised applications locally.
New in the GA release are wslc system info for the state of the container environment, wslc network connect and disconnect to attach containers to networks, arbitrary driver options for wslc network create, a --stop-timeout flag including an infinite value, and a configurable storage path for the default session.
The enterprise controls are the larger change. Microsoft Defender for Endpoint's WSL plugin now covers containers, surfacing process, file and network activity and linking it back to the Windows host. Microsoft Intune adds settings to allow or block WSL containers entirely and an allow list that restricts image pulls to approved registries.
The post also lists ecosystem support, including VS Code dev containers, which can use wslc as their default driver, and Aspire.
Why it matters
Running containers on Windows has meant installing a separate container engine and its own virtual machine. A built-in path through WSL, managed by Intune and visible to Defender, gives IT departments a version they can govern, and the registry allow list addresses one of the common objections to developer containers in regulated environments.