WSL Containers Explained: Why Windows Subsystem for Linux Is a Developer Tool, Not a Linux Replacement

What Microsoft said WSL was for in 2016​

WSL containers is the latest chapter, but the story starts earlier. On March 30, 2016, Microsoft introduced "Bash on Ubuntu on Windows." It said developers had told the company that working with open-source tools on Windows was often a struggle. Microsoft's response was to build the Windows Subsystem for Linux and run a genuine Ubuntu user-mode image from Canonical on top of it. Those details come from the Windows Developer Blog post.

That announcement set clear limits:

• It called the feature a developer toolset for writing and building code, not a server platform for hosting websites or running server infrastructure.
• It was explicitly a beta, with gaps expected.
• At that stage, Bash and Linux tools could not interact with Windows applications, and the reverse was also true. Microsoft's example was that you couldn't run Notepad from Bash.

A July 2016 Microsoft developer post described WSL in similar terms. It said the feature let Windows developers use the Linux ecosystem alongside their existing tools, without booting another OS or a VM. It called WSL "by developers, for developers" and said it aimed to reduce daily friction. It also said WSL isn't a Linux server or a full Linux client.

Microsoft's current FAQ is consistent with this. It says WSL is primarily a tool for developers, especially web developers, open-source contributors and people deploying to Linux servers. It describes WSL as aimed at the inner development loop.

WSL 2: a deeper integration, not a desktop swap​

Microsoft Learn says the main differences between WSL 1 and WSL 2 are a real Linux kernel in a managed VM, full system-call compatibility, and cross-OS file performance. Microsoft builds the WSL 2 kernel from the latest stable branch of the kernel.org source, and the kernel is open source. Windows updates service it.

The WSL 2 documentation also says the following:

• Where the speed gains are. Microsoft cites file-heavy operations such as git clone, npm install and apt update as noticeably faster, with early WSL 2 builds up to 20x faster unpacking a tarball. It puts git clone, npm install and cmake at around 2-5x faster.
• Where it isn't faster. Performance across the Windows and Linux file systems is a noted exception. The advice is to keep project files on the same OS as the tools working on them.
• Defaults and requirements. WSL 2 is the default for new distributions. It requires Windows 11, or Windows 10 version 1903 (build 18362) or later. WSL 1 and WSL 2 distributions can coexist.
• When WSL 1 may still be better. Examples include projects that must live on the Windows file system, and cross-compilation that uses Windows and Linux tools on the same files.
• Networking. WSL 2 uses NAT, so a distribution won't share the host's network address the way it did under WSL 1.

So WSL 2 is not a universal speed-up. It fixed the problems that mattered most to developers, but file placement still matters.

The VS Code connection​

The strongest evidence for the workflow framing is the VS Code WSL extension. VS Code's documentation says it lets you use WSL as a full-time development environment, with Linux toolchains and debugging, from the Windows side. The VS Code Server runs inside WSL, so language services and most extensions run there too.

The documented path is short:

1. Install WSL and a Linux distribution.
2. Install VS Code on Windows, not inside WSL, and tick the Add to PATH option during setup.
3. Install the WSL extension.
4. Open a WSL terminal, go to your project folder, and type code ..
5. On first run, VS Code fetches the components it needs. A WSL indicator then appears in the bottom-left corner.

The docs warn that WSL 1 has known limitations for some development scenarios. They also note that extensions on Alpine-based distributions may fail because of glibc dependencies.

That is a development environment, not a Linux desktop. The editor stays in Windows and the toolchain runs in Linux.

September 2026: WSL containers​

On September 29, 2026, Microsoft's Logan Iyer, a corporate vice president for Windows Platform and Developer, announced that WSL containers were generally available. The post said WSL is central to making Windows the best place to build, run and manage Linux workloads. It named AI, cloud-native development and containers as drivers.

What shipped:

• wslc.exe, a CLI to build, run and deploy Linux containers, with a built-in container.exe alias for familiar container commands.
• A WSL containers API that lets native Windows apps run Linux containers programmatically. Microsoft cited local AI workloads and cloud-based containerized apps as examples.
• GA additions including wslc container restart, wslc container cp, wslc system info, wslc events, network connect and disconnect, health checks, --mount support, and a configurable storage path.

To get it, run wsl --update. Microsoft Learn says the feature requires WSL 2.9.3 or later, and wsl --version shows what you have. The API ships as the Microsoft.WSL.Containers NuGet package with C# and C++/WinRT projections. Microsoft says the C++/WinRT projection is still in preview and may see breaking changes.

One discrepancy: Hardware Busters reports the release as WSL 3.0.1, while Microsoft Learn cites 2.9.3 as the minimum version. That fits a later build satisfying the requirement, but check your own wsl --version output. XenoSpectrum also noted that on September 30 some Microsoft Learn pages still carried pre-release wording and --pre-release pointers, even though the blog declared GA. Treat the documentation as slightly out of sync.

What this means for IT admins​

The enterprise side is arguably the most telling part of the announcement. Microsoft says the Defender for Endpoint plugin for WSL now covers containers. It can surface process, file and network activity from WSL containers and tie it back to the Windows host. Intune gains controls to enable or disable the feature and to restrict image pulls to approved registries. The new settings are "Allow WSL containers access" and "WSL containers registry allow list."

That matches the scenario Butler describes: an IT-managed laptop where the user can't swap the OS. Managed Linux tooling is easier to approve when it comes with policy and telemetry.

Microsoft's roadmap also mentions:

• wslc compose, the top feature request, which isn't there yet. Microsoft says it aims for wsl compose up to work with existing compose.yaml files unchanged.
• Work on networking and cross-OS file performance. Microsoft claims up to 2x faster Windows file access from Linux in the container path, plus a new "consomme" network mode for container workflows.

Where Butler's argument holds, and where it's opinion​

Supported by Microsoft's own material:

• WSL began as a developer tool, aimed at Windows users who need Linux command-line tooling.
• Microsoft's FAQ and 2016 posts say it isn't a server platform or full Linux client.
• WSL 2 and containers deepen Windows and Linux integration rather than replace either.

Interpretation, not established fact:

• That WSL exists to stop developers leaving for Linux. It's a plausible business motive, but Microsoft's documents don't say so.
• That WSL is "no threat to Linux whatsoever." That is a judgment call, not a finding.
• That Microsoft's "real reason" is hidden. Microsoft has stated the developer-workflow rationale openly since 2016.

Microsoft's September language also goes beyond tooling. It talks about evolving Linux on Windows into a "strategic execution platform" for AI and cloud-native workloads, under Windows enterprise governance. That's a platform ambition, which is a bigger claim than "convenience for developers."

Practical takeaways​

• If you only need Linux command-line tools alongside Windows apps, WSL fits what it was designed for. A full Linux install is a different product.
• Keep Linux-tool projects inside the Linux file system, not under /mnt/c, unless you have a reason to do otherwise.
• Admins evaluating WSL containers should look at the Intune registry allow list and the Defender for Endpoint plugin first.
• Don't plan around wslc compose yet. Microsoft has only said it's the next focus.
• Don't treat WSL as a production hosting platform. The FAQ says it's designed for inner-loop development, though it points to the WSL container API for building production apps that use Linux runtimes.

WSL didn't set out to make Linux obsolete. It set out to make Windows less annoying for people who build things, and the containers release continues that work with enterprise controls attached.