WSL Containers Go GA in WSL 3.0.1: wslc Setup, Intune Controls and Compose Limits

It isn't a Docker Desktop replacement for everyone yet, and there's no Compose support. Still, this is the most important change to Linux containers on Windows in a long time.

From Build teaser to GA in four months​

The timeline was quick. At Build on June 2, 2026, Microsoft described WSL containers as "coming soon to public preview." The pitch was a built-in CLI and API, policy-based enablement, control over where images come from, and visibility into running containers. The public preview arrived about four weeks later. In that preview post, Microsoft's command-line team said the feature was only in the pre-release version of WSL as a public preview, and aimed to make it generally available in the upcoming fall of 2026. That target has been met, with a week of September to spare.

GA also means a production go-ahead for app developers. During the preview, the API reference warned that the API was in preview and could have breaking changes, and told developers to evaluate feasibility and only deploy production grade code once the API reached general availability in fall 2026.

Summary: the preview landed in late June and GA arrived on schedule. The main thing GA changes is that you no longer need the pre-release channel.

Which build ships GA​

Microsoft's announcement doesn't give a version number. It just says to run wsl --update or download the latest GitHub release. The WSL GitHub releases page does give one: WSL 3.0.1, published September 29 and marked "Latest," with release notes saying WSLc is generally available. Its changelog includes a pull request that removes references to WSLC being in preview, plus fixes such as stdin support through the SDK and a VM termination timeout raised to 30 seconds.

The version number matters because the preview builds were in the 2.9.x series. Build 2.9.13, released September 25, was still labelled pre-release. During the preview, Microsoft Learn's getting-started tutorial said WSL version 2.9.3 or higher was required, and that the version was only available as a pre-release, so users had to run wsl --update --pre-release. Some of those pages may still show the older pre-release wording for a while. Microsoft now tells users to run plain wsl --update.

Getting started​

• Open PowerShell or Windows Terminal and run wsl --update.
• Check the result with wsl --version. You should see the new 3.x release, or 2.9.3 or later if you stayed on an older build.
• Try a container. Microsoft's own documentation uses this example: wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"
• Try a web server: wslc run -it --rm -d -p 8080:80 --name web nginx. Then run curl localhost:8080, list it with wslc container ps and stop it with wslc container stop web.

If curl returns the Nginx welcome page, it's working. wslc.exe also answers to the alias container.exe. Windows Latest noted during its preview testing that both commands point to the same binary. Because wslc.exe is included with WSL, there's no separate engine to install.

Summary: GA is WSL 3.0.1. You don't need the --pre-release flag anymore. Use wsl --version to confirm what you're running.

What GA adds over the preview​

Microsoft says it spent the preview on three areas: everyday workflows, visibility into what's running, and flexibility at scale. New in the GA release:

The storage path setting will be welcome on laptops with small system drives, because container images take up space quickly. The GitHub changelogs also list many smaller "docker parity" flags, such as --all-tags on pull and push, --digests and --all on image listing, --size on inspect, and Docker-style prune confirmation prompts. The goal is to make it feel like Docker, but it isn't identical. Endjin tested the preview and wrote that if you know Docker, you already mostly know wslc, then added that "mostly" is doing some work in that sentence, having found at least one incompatibility.

Summary: GA fills gaps in lifecycle, networking and observability. It works like Docker in most places, not all of them.

The API: Linux containers as a component of Windows apps​

The API is the less familiar half of the release. It ships in the Microsoft.WSL.Containers NuGet package. According to Microsoft Learn, it lets apps pull, run and interact with containers, including stdin/stdout, file mounts, networking and GPU access. It's built around four objects:

• WslcService: checks that the required WSL components are installed and can install missing ones
• Session: a WSL-backed host that manages images and creates containers, with configurable CPU count and memory
• Container: starts, stops, inspects and deletes containers, and runs extra processes inside them
• Process: reads output, writes to stdin, sends signals and watches exit codes

Microsoft's examples of what this enables include local AI workloads and running cloud-based containerized apps locally. Picture a Windows desktop app that ships a Linux-only inference server or a data-processing tool, and starts it in a container without asking the user to install anything. One caveat: the current documentation says the C++/WinRT projection is in preview and is subject to breaking changes. C# developers are on firmer ground than C++ developers.

Summary: the API is the part competitors don't really have an equivalent for. Check whether your language projection is still marked preview before you build on it.

What IT gets: Intune and Defender​

This is the part of the announcement enterprise admins will care about. There are two Intune settings:

• Allow WSL containers access: turns the whole feature on or off.
• WSL containers registry allow list: limits image pulls to approved registries.

The allow list addresses a problem security teams have had for years: developers pulling any image from any public registry. When the preview launched, Windows Latest reported that registry allow-listing was a setting that, per Microsoft, came up constantly in customer requests, so a company can restrict pulls to an internal or approved registry instead of leaving Docker Hub wide open.

On the Defender side, MDE's existing WSL plugin now covers containers. It shows process, file and network activity from WSL containers and ties it back to the Windows host, so analysts don't need a separate workflow. That's visibility and investigation, not a guarantee that malicious container activity gets blocked. Microsoft's announcement doesn't cover licensing, exact policy paths or enforcement details, so check the WSL enterprise documentation before you roll this out.

Summary: you can turn it on or off, allow-list registries and investigate container activity in Defender. Plan the rollout carefully before relying on these controls.

Ecosystem, performance and the missing Compose piece​

Microsoft lists several integrations:

• VS Code dev containers can use wslc as the default driver. During the preview, Help Net Security said setup needed one change: open the dev container settings, find the Docker Path field, and set it to wslc.
• Aspire can use WSL containers as a first-class container runtime.
• The popular VS Code container extension now supports wslc.
• Community tools: Lazywslc (a terminal dashboard), WSL Container Desktop (a WinUI 3 app that also manages k3s Kubernetes and registries) and WSLc remote (a wrapper for running wslc from inside WSL distros).

Microsoft also claims wslc delivers "up to 2x" faster access to Windows files from Linux. It gives no baseline, workload or measurement method, so take it as a vendor figure for now. There's also a new consomme network mode for container workflows, which Microsoft says improves compatibility across developer and enterprise scenarios. At preview launch, Microsoft said these changes were enabled just in WSL container for now because they touch mission-critical paths like file system access and network, with WSL-wide enablement planned for the future. The low-level improvements also benefit other tools: Docker Desktop, Podman Desktop and Rancher Desktop build on WSL and will benefit from these platform changes.

Then there's Compose. Microsoft says Compose support is the most requested WSLc feature and its next focus. The goal is for compose up to work with existing compose.yaml files unchanged. Work has started, but there's no date. If your local setup is a Compose file with a database, a cache, an API and a frontend, you'll need to wait or run services by hand. A July analysis by SmartScope recommended that teams that depend heavily on docker compose should test before planning any replacement. That advice still holds after GA.

Summary: the integrations are ready and the performance claims are promising but not independently verified. The lack of Compose is the biggest limitation for multi-service projects.

Should you switch?​

Here's how I'd break it down:

• Solo developers running one or two containers: try it. It's free, built in and works like Docker in most places.
• Teams using Compose: keep your current tools for now and test wslc on the side.
• Windows app developers who need Linux components: the API is the reason to look at this. C# is the safer choice for now.
• Enterprise IT: the Intune allow list and Defender visibility give you real governance options, but test enforcement before you rely on it.

Microsoft wants WSL to grow from a developer convenience into what it calls a "strategic execution platform" for AI and cloud-native workloads. With GA, it's past the preview stage, but it isn't finished. Compose support will be the next big test.

Update: Microsoft details WSL containers’ session isolation and storage (September 29, 2026)​

In a separate architecture deep dive published September 29, Microsoft explains a security distinction behind WSL containers. The privileged wslservice.exe creates the virtual machine but does not keep ownership of it. Instead, a wslcsession.exe process runs on behalf of the calling user and handles operations such as creating containers, mounting directories and binding ports. Microsoft says this separates sessions into different processes and keeps those operations out of the more privileged service.

The post also clarifies where data lives. Each session has its own virtual hard disk containing its images, containers, networks and volumes; for wslc.exe, Microsoft says those disks are stored under %AppData%\Local\wslc\sessions. Containers can mount Windows paths through virtiofs, or use a VHD-backed volume when they need a native Linux filesystem or a volume size limit. That distinction matters when choosing storage for workloads that need persistent data.

Microsoft further explains that the new Consommé networking model sends virtual-machine traffic through a Windows process running as the session’s user. According to Microsoft, this makes container traffic behave more like traffic from a regular Windows process when it encounters VPNs and firewalls. Admins should still test their own network policies and port-mapping workflows rather than assume identical behavior across environments.