WSL 3.0 Containers: Microsoft's Shot at Docker's Territory

Microsoft wants you to forget Docker Desktop exists

Microsoft announced general availability of WSL 3.0 on September 29, and the headline feature is not a kernel tweak or a filesystem upgrade. It is containers.

The company is now positioning Windows Subsystem for Linux as a full container runtime, directly competing with Docker Desktop — the tool most Windows developers reach for when they need Linux containers. After a public preview that began in June, the --pre-release flag is gone. Run wsl --update or grab the release from GitHub, and you have a working container engine running inside WSL.

This is not a incremental improvement. It is a strategic repositioning.

Why this matters for Windows developers

For years, running containers on Windows meant installing Docker Desktop, paying for a Pro license if your organization crossed the seat threshold, and accepting a Hyper-V or WSL 2 backend that occasionally felt one step removed from the Linux toolchain you were trying to emulate.

WSL containers collapses that distance. The runtime lives inside WSL itself. There is no separate Docker daemon to manage, no licensing gate, no virtual machine layer sitting between your container and the host. The CLI (wslc.exe) and its alias (container.exe) expose commands that mirror Docker’s interface: build, run, restart, cp, network connect and disconnect, health checks, events streaming.

An API layer is also available through the Microsoft.WSL.Containers NuGet package, supporting C, C++, and C#. File mounts, GPU access, standard I/O — all programmatic. A developer building a Windows-native tool that needs to orchestrate Linux containers no longer has to call out to Docker Desktop’s CLI or REST API.

The command set has expanded beyond the preview. wslc system info surfaces environment state. wslc events streams container activity in real time. Networks can be created with custom driver options. Containers now support --stop-timeout (including a value of -1 for indefinite grace periods) and --mount. The default wslc session lets you designate which drive holds container storage — a practical detail that matters when you are running images across multiple volumes.

Enterprise features that signal a serious pitch

Microsoft is not only courting individual developers. The enterprise angle is where this could tip the balance.

Two new Microsoft Intune policies give IT departments control: one governs whether WSL containers can run at all, and the other restricts which container registries images can be pulled from. For organizations that have struggled to enforce Docker Desktop licensing or regulate container image sources, this is a cleaner enforcement model.

Microsoft Defender for Endpoint now has a WSL plugin that tracks container processes, file operations, and network activity — and correlates them with host-side events. Security teams get visibility without deploying a separate container monitoring stack. That is a meaningful reduction in tool sprawl for Windows-heavy shops.

The Japanese dev community is already testing it

The initial reporting of WSL containers emerged from Japanese tech media, and the adoption signal there is notable. Japanese development studios — particularly those in gaming and embedded systems — have historically relied on Docker Desktop for cross-platform container workflows. The licensing costs and the overhead of maintaining a separate Linux VM stack have been persistent friction points.

Community tools are already appearing. Lazywslc and WSL Container Desktop are being built by volunteers. Aspire, the open-source ASP.NET Core application template, now treats WSL containers as a supported runtime. The Container Tools extension for Visual Studio Code has added support, and VS Code’s Dev Containers can now specify wslc as the default driver.

The most requested feature — wslc compose — has not shipped yet. Microsoft says it is the top priority. Docker Compose compatibility is the single thing standing between a smooth migration for most teams and a period of rewriting local development workflows.

Performance upgrades that help beyond containers

WSL 3.0 includes two infrastructure changes that benefit any workload running inside WSL, not just containers.

Virtiofs replaces the older Plan 9 filesystem sharing. Microsoft reports roughly double the throughput for cross-OS file access. For containers that read and write大量 files — build artifacts, database dumps, log rotation — this is a real improvement, not a benchmark curiosity.

Consomme reroutes Linux VM network traffic through user-mode Windows processes instead of going through the virtual network stack. The effect is better compatibility with VPNs and Windows firewalls — tools that have long been a source of frustration for developers running containers on Windows.

These upgrades will benefit WSL distributions and other container platforms running on top of WSL, not just the new native runtime.

What Docker loses

The clear loser in this shift is Docker Desktop’s differentiation on Windows. The product’s strongest selling point was never its technology — it was convenience. Install it, and containers just worked.

WSL containers offers the same convenience at zero licensing cost, with deeper Windows integration and no third-party daemon. Docker Desktop still holds advantages in multi-platform parity, mature Compose implementation, and a large existing base of tooling built around its API. But those advantages shrink fast if wslc compose arrives and delivers parity.

For organizations already paying for Docker Pro or Business licenses, WSL containers offers a path to reduce spend. For new teams, it offers a reason to skip Docker Desktop entirely.

What happens next

The critical question is how long it takes Microsoft to ship wslc compose and how close to Docker Compose compatibility it lands. Compose is the glue that holds most local development workflows together. Without it, WSL containers is a runtime — useful, but incomplete for teams that rely on multi-service stacks defined in YAML.

Microsoft’s track record on developer tooling has improved significantly over the past three years. The VS Code acquisition, the GitHub purchase, the investment in .NET on Linux — all signal a company taking developer experience seriously. WSL containers fits that pattern.

What is less clear is whether Microsoft will open the API enough for the ecosystem to build around it, the way Docker did. The NuGet package and CLI are a start. But the container tooling landscape thrives on extensions, plugins, and integrations — and those require an open interface, not just a well-documented one.

For now, Windows developers who want Linux containers have a credible native option for the first time. Whether it becomes the default depends on what ships next.