WSL Containers vs Docker Desktop on Windows 11: Is wslc Ready in 2026?

Microsoft's WSL Containers let Windows 11 run real Linux containers with no Docker Desktop in sight — here's what actually works.

If you've been running Docker Desktop on Windows just to get a Linux container up and running, that's no longer the only option. Microsoft has quietly built a native container engine straight into the Windows Subsystem for Linux, called WSL Containers (the command-line tool is wslc). It pulls OCI images, runs them, and manages their lifecycle — all without installing a single third-party runtime.

I spent a week putting wslc through the paces on a real Windows 11 machine: install, benchmarks, GPU containers, networking, VS Code integration, and the Compose gap that's been the biggest complaint since it shipped. Short version — it's genuinely good for day-to-day development work, but there's a RAM-leaking bug and a couple of default behaviors that will trip you up if nobody warns you first. That's what this guide is for.

I'm Mostafa Amaan, and on Valley4Techs I write practical, tested guides on Windows, Linux, and the tools that sit between them. Let's get into it.

WSL Containers vs. Docker Desktop vs. Podman Desktop — Quick Comparison

Before the full breakdown, here's how the three main ways to run Linux containers on Windows stack up against each other right now:

What WSL Containers Actually Is

Picture this: you open a terminal on a fresh Windows 11 install, no Docker Desktop, no Podman, nothing extra downloaded. You type one command, and a few seconds later you're inside a real Linux shell backed by an actual Linux kernel — not a translation layer, not a compatibility shim. That's the entire pitch of WSL Containers, and it's a bigger architectural shift than the name suggests.

WSL Containers — often shortened to wslc or WSLC — is a container runtime Microsoft built directly into the Windows Subsystem for Linux. It shipped as a public preview around Microsoft's Build 2026 event and lives in the pre-release channel of WSL for now. For official reference documentation, check out the official Microsoft WSL documentation. It comes in two pieces:

• The CLI tool. wslc.exe, also aliased as container.exe. Its command syntax deliberately mirrors Docker — wslc run, wslc build, wslc pull — so muscle memory carries over almost completely, aside from a few commands moving to a noun-based structure like wslc container list instead of docker ps.
• The API. A NuGet package with C, C++, and C# bindings, so Windows application developers can quietly spin up a Linux container inside their own app to run Linux-only code, then tear it down, without asking the user to install anything.

The part that matters most for how it behaves day-to-day is the architecture. Docker Desktop runs its engine as a distro inside WSL's single shared utility VM — every container you start lives in that same VM alongside your other WSL distros. WSL Containers does the opposite: every session gets its own brand new, isolated virtual machine, named after your Windows user account. That isolation is the whole reason it exists, and it's also the source of most of the quirks in this guide.

If you're still deciding how deep to go into Windows virtualization in general, our Windows Server 2025 upgrade guide covers Hyper-V changes that feed into how WSL itself runs under the hood.

System Requirements: Windows 11 Editions & Virtualization Prerequisites

Before running out to update your WSL packages, it's crucial to understand the exact Windows build and hardware virtualization requirements. While WSL 2 has become ubiquitous across Windows, WSL Containers introduces distinct requirements due to its per-session lightweight VM architecture.

Windows 11 Home vs. Pro vs. Enterprise

One of the most frequent questions from developers is whether WSL Containers requires a paid Windows 11 Pro or Enterprise license. The short answer is: WSL Containers works on Windows 11 Home, Pro, Enterprise, and Education editions, but the setup prerequisites differ slightly.

• Windows 11 Home: Relies entirely on the Virtual Machine Platform optional feature. You do not need Hyper-V management tools, but hardware virtualization (VT-x or AMD-V) must be enabled in your system motherboard BIOS/UEFI.
• Windows 11 Pro / Enterprise: Uses the native Hyper-V architecture directly. This provides better performance tuning options, such as explicit RAM limits via system policies.

Hardware & Firmware Requirements

Because every wslc command provisions a dedicated micro-VM, your system must meet these baseline hardware specifications:

1. Hardware Virtualization Enabled: CPU-level virtualization (Intel VT-x or AMD-V) must be toggled ON in your BIOS/UEFI settings. If you haven't configured hardware virtualization before, read our complete guide on BIOS vs UEFI setup and virtualization settings.
2. Windows 11 Version: Windows 11 22H2, 23H2, or 24H2 (Build 22621 or higher). WSL Containers is not available on legacy Windows 10 builds.
3. Minimum RAM: 16 GB of system memory is strongly recommended. While 8 GB systems can launch single containers, the per-session VM memory footprint can quickly cause swap paging on low-memory rigs.

How to Install WSL Containers on Windows 11

This whole process took me under two minutes on a decent connection. WSL Containers currently ships only in the pre-release channel, so you need to opt into that first.

1. Open Windows Terminal or PowerShell as Administrator. Right-click the Start button and choose "Terminal (Admin)."
2. Switch to the pre-release channel and update:

   wsl --update --pre-release

3. Restart WSL so the update takes effect:

   wsl --shutdown

   Close and reopen your terminal after this.
4. Confirm the install:

   wslc --version

   A version number of 2.9.3.0 or newer confirms WSL Containers is in place.
5. Check the command reference:

   wslc --help

   If it lists commands and usage, you're ready to pull an image.
6. Run your first container:

   wslc run -it debian bash

   Once you're inside, run uname -a. Seeing a WSL2 Linux kernel string back confirms you're in a genuine Linux environment, not an emulated one.

Figure 1: Updating to the WSL pre-release channel and verifying wslc v2.9.3.0 installation in Windows Terminal.

The Speed Claims Don't Match What I Actually Measured

When wslc first started making the rounds, the number everyone repeated was that it starts containers in under a second, versus three to eight seconds for Docker Desktop. I wanted to see that gap for myself, so I ran both through a scripted benchmark harness using the same lightweight Alpine image, warm and cold, back to back. From my own testing on the current preview build, that gap simply isn't there anymore.

Warm-to-warm, wslc wins by roughly 60 milliseconds — not something any human will actually feel while working. Cold-to-cold, the two were close enough to call it a wash. The only place Docker Desktop really fell behind was when it hadn't shut down cleanly: a crash or force-kill made its next start noticeably slower, partly because its privileged Windows helper service needs a fresh consent prompt.

What impressed me more than the raw numbers was consistency. Every wslc start I logged landed inside a tight 224-millisecond band, no matter how the previous session ended. That makes sense once you remember each session gets a brand new private VM — there's no accumulated state to repair or clean up, so there's nothing that can slow a fresh boot down. If you care about predictable startup time in a CI script more than shaving off milliseconds, that consistency matters more than the benchmark headline number.

The RAM Leak Bug & How to Fix It Automatically via .wslconfig

This is the part I'd genuinely flag before anyone installs this on a machine they care about. Microsoft's documentation says containers are supposed to clean up after themselves once you're done with them. In my testing, the container itself does disappear — but the private VM that was hosting it does not. It survives even a manual wsl --shutdown, quietly holding onto roughly 1.5 GB of RAM per session.

Figure 2: Windows Task Manager revealing 3.4 GB of RAM consumed by orphaned WSL session VMs (vmmemWSL).

wslc system session terminate

It compounds fast, too. Booting a single wslc container in my testing also spun up a fresh copy of the shared WSL utility VM and re-registered my existing Ubuntu distro as "running," even though I hadn't touched it. That's around 3.4 GB of RAM consumed by what looked, on the surface, like one idle terminal prompt. On a machine with 16 GB of RAM, that's not a rounding error — it's a meaningful chunk of your headroom disappearing silently.

Permanent Fix: Auto-Reclaiming Memory via .wslconfig

Relying on manual session termination commands is error-prone. Fortunately, you can prevent WSL Containers from devouring system RAM by creating a global configuration file in your Windows user directory.

Open Notepad or VS Code, create a file named .wslconfig in your Windows user home folder (e.g., C:\Users\<YourUsername>\.wslconfig), and add the following optimization block:

[wsl2]
# Cap memory usage so orphaned session VMs cannot consume your entire host RAM
memory=8GB

# Automatically reclaim unused cached memory back to Windows 11 host
autoMemoryReclaim=dropcache

# Limit CPU core allocation for background VMs
processors=4

# Limit swap space
swap=4GB

Key setting: autoMemoryReclaim=dropcache forces WSL2 to continuously return unused Linux page cache memory back to the Windows host operating system. After saving the file, execute wsl --shutdown once to apply the changes globally.

GPU Acceleration: The One Thing That Just Worked

GPU passthrough inside containers is usually where things fall apart, especially with Nvidia driver versions that don't quite line up. I budgeted a generous 15 minutes to either get it working or collect enough evidence to tell people to skip it entirely. It took two minutes, and it worked the first time.

A stock CUDA 12.4 image detected an RTX 5090 immediately with a single --gpus all flag — no manual driver installation inside the container required. It even worked against a newer CUDA 13.3 host driver, which is the kind of version mismatch that normally causes headaches. If you want to understand the foundational differences between GPU compute layers and dedicated processors, check our breakdown on CPU vs GPU vs APU architectures.

Figure 3: Instant CUDA GPU detection inside a wslc container using the single --gpus all flag.

Keep in mind this is GPU paravirtualization, not exclusive passthrough, so the total VRAM you see is shared with whatever else is running on your Windows desktop at the same time. Budget accordingly if you're running anything else GPU-heavy in parallel.

Where the GPU story gets less rosy is the surrounding flag set. As of this preview, wslc is missing --privileged, --device, and --restart. Nothing you run survives the session ending — which is fine for a quick training or inference test, but a dealbreaker if you wanted to keep a GPU-backed service running long-term.

The Networking Default That Will Confuse You

Here's a change that cost me twenty minutes of troubleshooting before I found the cause. Docker Desktop binds published ports to 0.0.0.0 by default, meaning the service is reachable from anywhere on the machine. WSL Containers binds to 127.0.0.1 instead — loopback only. If you're used to Docker's behavior, your test container will look like it silently refuses connections, even though it's running fine.

The fix is to publish the port explicitly:

wslc run -p 0.0.0.0:8080:80 nginx

Integrating WSL Containers with VS Code and Dev Containers

For modern software engineering workflows, container support is only as good as its IDE integration. Most developers running Windows rely heavily on Visual Studio Code alongside the official Dev Containers extension (formerly Remote - Containers).

The Socket Disconnect: Docker Daemon vs. wslc CLI

By default, the VS Code Dev Containers extension expects a standard Unix socket (/var/run/docker.sock or named pipe //./pipe/docker_engine) controlled by a persistent background daemon. Because WSL Containers uses a daemonless model where each session spins up an isolated private VM, VS Code will fail to auto-detect wslc out of the box.

Figure 4: Configuring VS Code Dev Containers settings to point to the wslc executable path.

How to Configure VS Code for wslc

You can bridge this gap by customizing your VS Code user settings to target the wslc.exe executable path:

1. Open VS Code Settings (Ctrl + ,).
2. Search for dev.containers.dockerPath.
3. Set the executable path explicitly to: wslc.exe or container.exe.
4. In your project's .devcontainer/devcontainer.json file, ensure you set "overrideCommand": true to allow wslc to control shell execution.

While this setup enables interactive dev container sessions, keep in mind that multi-container dev environments (such as devcontainers referencing Compose files) will still require the community shim covered in the next section.

No Native Compose Support Yet — But the Community Filled the Gap

This is the single biggest reason people go back to Docker Desktop after trying wslc. As of version 2.9.3, there's no wslc compose command, and there's no partial version either — multi-container orchestration through a single YAML file just isn't built yet. It's currently the most-requested item on the official microsoft/WSL GitHub repository, without a milestone attached as of mid-2026.

What surprised me is that the underlying plumbing — networking and volume lifecycles — is already there. Microsoft simply hasn't shipped the top-level Compose command to drive it. A community project called wslc-compose takes advantage of that gap with a lightweight Python shim that translates Compose files into the individual wslc commands needed to run them.

I installed it through pipx and pointed it at a two-service test stack — nginx and Postgres, with a depends_on entry specifically to see if it would trip up the ordering. It didn't. I ended up with a project-scoped network, the database starting before the web container, and a shared Alpine base layer deduplicated between the two. Running down -v tore the whole stack back down cleanly, networking included. It's not an official solution, and it won't get the same long-term support guarantees, but it's functional enough to use today if Compose is a dealbreaker for you.

Deep Dive: WSL Containers vs. Podman Desktop for Enterprise

For developers seeking to bypass Docker Desktop's enterprise licensing model (which requires paid subscriptions for companies with over 250 employees or $10M in revenue), both WSL Containers and Red Hat's Podman Desktop present attractive free options. However, their security architectures and runtime behaviors diverge fundamentally. You can review the official Podman Desktop documentation to explore its enterprise toolset.

Architecture: Rootless Podman vs. Isolated WSLC Micro-VMs

• Podman Desktop: Uses a rootless, daemonless container model inside a single shared WSL machine. Containers run under unprivileged user namespaces, eliminating the security risk of a compromised root daemon on your system.
• WSL Containers (wslc): Isolates container sessions at the hypervisor level by placing each session inside its own lightweight Hyper-V Micro-VM. While inside the VM you operate with root privileges, the hypervisor boundary keeps host Windows memory isolated.

Which Free Alternative Should You Choose?

5 Mistakes People Make Trying WSL Containers for the First Time

1. Never running the terminate command or setting .wslconfig. Orphaned session VMs are the single biggest source of "why is my RAM full" complaints with wslc right now. Either configure autoMemoryReclaim or make wslc system session terminate a routine habit.
2. Assuming ports behave like Docker. Publishing without an explicit 0.0.0.0 binding leaves your service reachable only from inside the same machine, which looks exactly like a broken container from the outside.
3. Expecting Compose files to work out of the box. They won't yet. Either install the community shim or restructure your workflow around individual wslc run commands.
4. Treating persistent services like they'll survive a reboot. With no --restart flag, anything you run disappears the moment the session ends. This isn't the right tool yet for a self-hosted service you want running 24/7 — for that, stick with Docker Desktop, Podman, or a proper hypervisor setup like the one in our best self-hosted apps for Proxmox guide.
5. Panicking at the COM Surrogate firewall prompt. It's expected behavior tied to wslc's networking stack, not malware — though I understand why it looks alarming the first time you see it.

So, Should You Replace Docker Desktop With It?

For day-to-day development — dev containers, quick one-off tests, GPU experiments — my answer is yes, it's genuinely ready. It's fast enough that the difference from Docker Desktop doesn't matter in practice, it's lighter on the parts of the system that don't involve orphaned VMs, and GPU support worked better than I expected from preview software.

For anything you want running unattended — a home-lab service, a small self-hosted app, anything that needs to survive a reboot — it isn't there yet. No restart policies and no native Compose support are hard blockers for that use case, and the RAM-leak bug makes it a poor fit for a machine you're not actively watching. If your workloads lean toward long-running services rather than active development, our VMware vs. Proxmox comparison is a better starting point than any Windows-native container tool right now.

The other real gap is visibility. Docker Desktop puts every container in front of you in a GUI whether you look for it or not. WSL Containers keeps everything behind the command line, so you need to actively run wslc ps -a to know what's using your resources. That's likely a preview-software gap rather than a permanent design choice, and a management UI wouldn't be surprising down the line — but until then, get comfortable with the CLI.

If you're newer to the Linux side of this equation entirely, our guide on what to do after installing Linux and our breakdown of switching between Windows and Linux are both good next stops before you go deeper into containers.

Frequently Asked Questions