WSL Containers Now Generally Available on Windows

Microsoft has made WSL containers generally available after a public preview. The feature adds a built-in way to build and run Linux containers on Windows through the Windows Subsystem for Linux. It comes with its own command-line tool, an API for Windows applications and management controls for IT teams. For developers who write code on Windows laptops and deploy to Linux servers, this means local container work no longer depends entirely on third-party tools. For the people who manage those laptops, it adds settings that decide which container images are allowed.

What WSL containers are

WSL containers run Linux container workloads on top of WSL, so they use the same Linux kernel integration that WSL distributions already use. There are two parts:

• The wslc.exe CLI, also available under the alias container.exe, for building, running and managing containers from a terminal.
• The WSL containers API, which lets native Windows applications create and manage containers in code. Microsoft mentions local AI workloads and containerised cloud apps as examples.

Microsoft presents this as part of a wider plan to make Windows a good place to build and run Linux workloads, especially as AI and cloud-native tooling increasingly assume Linux.

What the GA release adds

The general availability release fills in much of what was missing from the preview. New and expanded commands include:

Compose support is not included yet. Microsoft says wslc compose is a top priority, with the aim of running existing compose.yaml files unchanged. If your local development stack is defined in a compose file, keep your current tooling for now.

Consommé networking

The most practical change for many users is a new networking mode called Consommé. Container traffic is passed as Ethernet frames to a Windows process that runs under the signed-in user’s account. That process handles DNS, routing and port mapping, so container traffic goes out like traffic from any other Windows application.

This matters because WSL networking has long been a problem behind corporate VPNs and endpoint firewalls. If containers behave like ordinary Windows processes on the network, they should follow the same VPN routes and firewall rules as the rest of the machine. Microsoft also says the new mode can make access to Windows files from Linux up to twice as fast.

Controls for IT administrators

If you manage Windows devices, you now have a say in how this feature is used. Microsoft Intune gets two new settings:

• Allow WSL containers access: turns the feature on or off across managed devices.
• WSL containers registry allow list: limits image pulls to registries you approve, such as your own private registry or a vetted mirror.

The registry allow list is worth setting up early. Pulling arbitrary public images onto company laptops is a real supply-chain risk, and an allow list deals with it without banning containers altogether. Microsoft Defender for Endpoint’s existing WSL plugin also now shows process, file and network activity from containers, so security teams can link container behaviour to the Windows host during an investigation.

Getting started

WSL containers ship as part of WSL itself. Update WSL from PowerShell or Windows Terminal, then check that the container environment is available:

wsl --update
wsl --version
wslc system info

You can also download the latest WSL release from its GitHub repository. A sensible way to evaluate it:

1. Try it on one developer machine with a project you already containerise, and compare build times, file access speed and networking against your current setup.
2. Test from behind your VPN, where the Consommé mode should make the most difference.
3. If you use VS Code, try its dev container integration, which Microsoft lists as supported.
4. Before a wider rollout, decide on the Intune settings: whether the feature is allowed and which registries are on the allow list.
5. Keep compose-based projects on your existing tools until wslc compose is released.

Whichever tool you use on the desktop, the containers end up on Linux servers or in the cloud. Keep base images and image builds the same from laptop to CI to production, so that a container that works locally works when you deploy it.

How TechProvidence can help

TechProvidence helps teams build consistent container workflows: setting up private registries, CI pipelines that build and scan images, and the Linux and AWS servers those containers run on. If you are standardising developer environments or moving workloads into containers, contact us.

Source: Windows Developer Blog