WSL Containers GA: Run Linux Containers on Windows Without Docker Desktop

XDA's Abhinav Raj tried it on his main desktop, a Ryzen 5 7600X with an RTX 4070 Ti Super. He says his first container was running within a minute of starting the update. Microsoft's documentation backs up the core of that. It also adds a few details the "one command" headline leaves out, plus some settings that IT admins should look at before developers start publishing ports.

What shipped, and when​

Microsoft made WSL containers generally available on September 29, 2026. The feature adds the command-line tool wslc.exe to the Windows Subsystem for Linux (WSL), so you can build and run Linux containers on Windows without Docker Desktop. According to Hardware Busters, the feature shipped on September 29 as part of WSL 3.0.1, and it turns the Windows Subsystem for Linux from something that runs distributions into something that also builds and runs Linux containers by itself. Existing WSL users pick it up with a plain wsl --update.

The project had a short public life before GA. Heise reports that Microsoft introduced WSL Containers at the Build 2026 conference in early June. The first public preview was released on June 29 with WSL 2.9.3.

The GA release has two parts. Microsoft's Windows Developer Blog announcement, written by Logan Iyer, Corporate Vice President of Windows Platform + Developer, describes:

• The wslc.exe CLI, for building, running and deploying Linux containers. Microsoft also includes container.exe as an alias, so you can use more familiar container commands.
• The WSL containers API, which Windows applications can use to run Linux containers in code. Microsoft's Learn documentation says it ships in the Microsoft.WSL.Containers NuGet package, with C# and C++/WinRT projections. Microsoft labels the C++/WinRT projection as preview and subject to breaking changes.

GA also added a batch of commands. Microsoft lists wslc container restart, wslc container cp for copying files in and out, wslc system info, network connect and disconnect, the real-time wslc events stream, container health checks, --mount and --stop-timeout on create and run, and a configurable storage path for the default session.

Section summary: WSL containers are a shipping, supported part of WSL, not an experiment. Existing WSL users get them through the normal update channel.

The "one command" setup, step by step​

The headline is accurate for anyone who already runs WSL. Here is the full sequence from Microsoft's "Get started with WSL container" tutorial, run in PowerShell:

1. Check your version: wsl --version
2. Update if needed: wsl --update
3. Confirm the CLI exists: wslc version
4. Run a test container: wslc run --rm hello-world

According to Microsoft, wslc.exe comes with WSL, so there's no separate engine to install. The hello-world image is pulled automatically if it isn't already on the machine. If it works, you'll see a "Hello" message.

One correction to the XDA piece. Raj tells readers to check for WSL 3.0.1 or later, but Microsoft Learn lists a lower minimum: WSL containers need WSL 2.9.3 or higher. Version 3.0.1 is the GA release, so it's a sensible thing to update to. It just isn't the documented floor. The 4sysops guide agrees, noting that WSL containers give you a built-in Docker-style CLI, installed with wsl –update on WSL 2.9.3 or later.

At the time of writing, the WSL GitHub releases page lists 3.0.3 (October 9) as the latest stable build and 3.0.4 (October 20) as a pre-release. A plain wsl --update puts you on a current GA build.

There's a second caveat for fresh Windows 11 installs. Raj notes, and Microsoft's tutorial confirms, that WSL has to be installed first with wsl --install. On a new machine, "one command" is really "install WSL, then update it." That's still short, but it isn't one command.

Raj says his test container printed its greeting in under 10 seconds, image download included. He also says he never had to sign in, reboot or accept a license. That's one user's experience. Your network speed will change the timing, and so will the second caveat below.

Managed PCs: SmartScope's write-up warns that managed devices may also have organizational restrictions. If wslc is missing or fails on a work laptop, check whether your admin has turned the feature off before you start troubleshooting.

Beyond hello-world: what you can actually do​

Microsoft's tutorial goes further than the smoke test. It shows a web server with a published port:

wslc run -d --rm -p 8080:80 --name web nginx
curl localhost:8080
wslc container list
wslc exec web cat /etc/os-release
wslc container stop web

Because the container was started with --rm, it's removed automatically when it stops. The tutorial also walks through building a Django app from a Containerfile with wslc build -t helloworld-django . and then opening it at localhost:8000 in a Windows browser.

The same documentation lists troubleshooting and cleanup commands:

If the background VM is still holding memory after you're done, a Microsoft-side reply on the preview blog pointed users to wslc.exe system session terminate. Microsoft's settings documentation also says an idle session shuts itself down after a timeout, which defaults to 30 seconds.

GPU containers: what worked for one tester​

This is where Raj's test gets interesting. He runs local LLMs with llama.cpp, and a containerized inference server only makes sense if it can reach the GPU. He used the same --gpus all flag that Docker users already know:

wslc run --rm --gpus all nvidia/cuda:12.9.1-base-ubuntu24.04 nvidia-smi

He reports that nvidia-smi inside the container showed his RTX 4070 Ti Super with 16GB of VRAM and driver 617.14, matching what Windows reports. He didn't have to set up the NVIDIA Container Toolkit the way he would on a bare-metal Linux machine.

He then ran a short benchmark. He ran his Gemma 4 E4B model (Q4_K_M quantization, full GPU offload, 128K context, the same prompt, a 256-token reply) natively and inside llama.cpp's official CUDA container. Native runs gave 128–132 tokens per second over two runs. The container gave 124 tokens per second both times.

Those numbers are useful, but they're limited:

• They come from one machine, one model and two runs each. They aren't general performance figures.
• Microsoft's own GPU example is different. Its June preview post used a CUDA PyTorch image with --gpus all and checked torch.cuda.is_available(). So GPU passthrough is a documented, intended feature, not a happy accident.
• Microsoft's CUDA-on-WSL documentation says you need the NVIDIA CUDA-enabled driver for WSL on the Windows side, plus a WSL kernel of 5.10.43.3 or higher. You can check the kernel with wsl cat /proc/version. "The Windows driver did all the work" is true only if that driver is the right one and up to date.

AMD and Intel GPU owners should note that both Raj's test and Microsoft's demo used NVIDIA CUDA. Neither one tells you anything about other GPU stacks.

Section summary: GPU containers work and are officially demonstrated. A single reviewer's single-digit performance gap is encouraging, but don't treat it as a benchmark.

Settings admins and power users should know​

Here's what you won't learn from the hello-world test. wslc doesn't read your .wslconfig. Microsoft's container settings documentation says the CLI uses its own per-user file at %LOCALAPPDATA%\wslc\settings.yaml. Run wslc settings to create and open it, and wslc settings reset to restore the commented-out defaults.

Two warnings from Microsoft's docs:

• Port exposure: by default, published ports bind only to localhost. Setting defaultBindingAddress to 0.0.0.0 exposes them on every host interface. Treat that as a deliberate security decision, not a fix for "my coworker can't see my test server."
• Storage moves aren't migrations: changing storagePath after a session exists doesn't move your images. It creates a new, empty session at the new location.

Session settings take effect when a session starts. Run wslc system session terminate to apply changes right away.

Enterprise controls​

Microsoft is pitching this as more than a developer tool. The GA release adds container support to WSL's existing Intune and Microsoft Defender for Endpoint integrations. Intune gets two new settings: one to allow or block WSL containers entirely, and a registry allow list that limits which registries images can be pulled from. Microsoft says the MDE plugin can show process, file and network activity from WSL containers and link it back to the Windows host.

For IT teams, this answers a long-standing question: how do you control which Linux images get onto company endpoints? A registry allow list gives you a policy lever, which a developer quietly installing a third-party container stack doesn't.

The Compose gap, and how wslc compares with Docker Desktop​

Raj doesn't call wslc a Docker Desktop replacement, and he's right not to. The biggest missing piece is Compose. Microsoft's GA post calls Compose the top feature request and says the goal is for existing compose.yaml files to work unchanged. That's a stated goal on the roadmap, with no ship date. 4sysops reaches the same conclusion: without Compose support, teams with multi-container setups will likely keep their current tools for now.

There's also a platform difference. Raj points out that Docker Desktop can switch to Windows containers, while Microsoft's documentation describes wslc only in terms of Linux containers.

For people who need Compose today but would rather skip Docker Desktop, Raj suggests Podman Desktop or Rancher Desktop. That's his recommendation, and we haven't independently checked their current Compose support. Microsoft itself mentioned both tools, alongside Docker Desktop, in its preview post as container tools that build on WSL and will benefit from the same platform improvements.

Those improvements are worth knowing about. Microsoft says the wslc path brings up to 2x faster access to Windows files from Linux and a new "consommé" networking mode meant to improve compatibility with VPNs and enterprise networks. According to Microsoft, these changes are on by default for WSL containers first, with plans to bring them to regular WSL distributions later.

Should you switch?​

A quick decision guide, based on the documented features and Raj's experience:

• Single containers, quick tests, GPU inference experiments: try wslc. Setup is minimal and there's nothing else to install.
• Multi-container Compose stacks: keep what you have until wslc compose actually ships.
• Windows containers: wslc isn't the tool for these.
• Managed fleets: check the Intune settings before developers adopt it, and decide on the port-binding policy in advance.

Microsoft's own Learn tutorial, which XDA notes used to point readers to Docker Desktop, now teaches wslc. That says a lot about where Microsoft thinks Linux containers on Windows should start. Docker Desktop isn't going anywhere, but it's no longer the default first step.