WSL Containers Ships, but the Migration Is Not Automatic

Microsoft has shipped a Linux container runtime inside WSL, but a team whose development environment starts with a Compose file should resist the urge to call it a drop-in replacement. The useful question is narrower: which parts of a Windows development workflow can now move into the platform, and which responsibilities still sit with the application team? The September 29 release makes that a purchasing and engineering question rather than a preview experiment. It does not answer it for every stack.

The release record is concrete. Microsoft's WSL 3.0.1 GitHub release labels WSL containers generally available, matching its announcement that day. The command-line entry point is wslc.exe, with container.exe as an alias, and a separate API lets native Windows applications operate Linux containers. Existing users can obtain the current release through wsl --update. That establishes a shipped product, not a forecast. This report examines the published implementation and limitations; it is not a hands-on performance test or a certification of the runtime's security.

The distinction between having the feature and having the GA release matters. Microsoft's introductory documentation lists WSL 2.9.3 as the minimum for container functionality, while the later 3.0.1 release marks general availability. A fleet inventory should therefore record actual installed versions instead of treating the presence of a command as sufficient evidence that every workstation is on the same release. That recommendation follows directly from the different milestones. A migration experiment becomes hard to interpret if machines are quietly testing different generations of the software.

Microsoft's getting-started tutorial shows a familiar path: build an image from a Containerfile, start it with a published port, inspect the running container and read its logs. It also documents resource statistics and removing unused images or stopped containers. Those are useful operational basics, especially because the runtime ships with WSL instead of requiring a separate engine installation. But a successful demonstration application proves only that demonstration. For a real evaluation, use the same dependency installation, build, startup and shutdown sequence that developers run against the project being considered.

Underneath the command line, Microsoft has changed who owns the work. Its architecture account says the privileged wslservice.exe creates a wslcsession.exe child process operating for the calling user. Session operations, including directory mounts and port binding, move into that less-privileged process. Each session also has its own virtual hard disk for state such as images, containers, networks and volumes. Microsoft presents this as stronger separation and reduced privilege. Those are descriptions of the design, not evidence that every possible escape or permission error has been eliminated.

The storage choice is more specific than a faster-files headline. Windows paths are shared into the virtual machine through virtiofs, while a VHD-backed volume provides a native Linux filesystem. The networking design, Consomme, routes traffic through a Windows process acting for the session's user, handling name resolution, TCP and UDP traffic and port mapping. Microsoft argues that this improves compatibility with host networking controls. The engineering implication is to test the actual boundary being crossed: a Windows-mounted project is not the same storage arrangement as a Linux-native volume.

That testing distinction is supported by an awkward detail in Microsoft's own tutorial. It still advises keeping source files in the filesystem where the tools execute and warns about cross-filesystem access. In other words, a changed sharing mechanism should not become permission to ignore file placement. A sensible evaluation would compare the same project in the locations the team intends to use, recording build completion, file-watching behavior and cleanup. We would also keep antivirus, network and storage settings consistent between runs so the comparison measures the proposed change rather than an accidental environment difference.

The independent coverage is cautious on speed. Help Net Security reports Microsoft's claim of up to twice the speed for access to Windows files from Linux, while noting that the announcement supplies no test conditions. We would not turn that number into a forecast for compile time, application startup or developer productivity. Those are different measurements. The publication also identifies the missing Compose support. Its account corroborates the release and its boundaries, but does not supply an independent benchmark or security assessment. There is no measured company-wide efficiency gain to report here.

Compose explains why familiar command verbs are not enough. Docker's application model defines services, networks, persistent volumes, configuration and secrets together in YAML. A project groups an application's resources, and the Compose CLI creates and manages the services described by that configuration. This makes the file an operational description of a system, not merely a convenient way to type several run commands. A team evaluating another runtime must account for that entire description, including how resources are named, connected and cleaned up when an environment is replaced.

Microsoft places Compose support on its roadmap and says the goal is to run existing compose.yaml files unchanged. That is an intention, not a capability in this GA announcement, and the company gives no delivery date there. Replacing a working Compose-based environment today would therefore require a separately justified solution for orchestration. Our recommendation is to leave that workflow intact unless there is a concrete reason to own the replacement work. A runtime experiment should not quietly turn into maintaining a second description of the application just to demonstrate that a new tool can launch it.

Native application developers have a different opening. The Microsoft.WSL.Containers NuGet package exposes objects for checking prerequisites, managing a session and its images, controlling a container, and communicating with its processes. The documented process interface includes input, output, signals and exit events. This gives a Windows application an explicit programming model for a Linux workload rather than requiring a user to manually coordinate each step. The overview also lists GPU access, but that listing does not establish support for a particular customer's hardware or the performance of an intended model.

An important qualification sits inside that API documentation: the C++/WinRT projection remains in preview and may have breaking changes. Product-level general availability should not erase a component-level warning. For an application builder, we would separate the decision to evaluate the runtime from the decision to freeze an integration contract. Test what happens when prerequisites are absent, an image cannot be obtained, a process fails, or the user closes the application. Those are proposed acceptance cases, not defects established by this reporting. They determine whether embedding a workload actually simplifies the customer's experience.

The enterprise pitch needs an equally careful reading. Microsoft's announcement says Intune can disable WSL containers or restrict image pulls to approved registries, and that Defender can connect container activity to the Windows host. These controls address different questions. One governs whether a developer can use the feature and where an image comes from; the other supplies evidence about activity. Neither statement establishes that every permitted image is harmless. An approved registry still needs an owner who decides what belongs there and how those decisions are revisited.

The linked Intune reference illustrates why rollout teams should inspect more than a launch post. The page we reviewed, dated August 4, 2025, describes policies for WSL access, debugging, custom kernels and user-configurable network settings. Its settings list does not include the new container registry control described in the GA announcement. That mismatch does not prove the new control is absent. It does mean the launch article and the older reference should not be treated as interchangeable deployment instructions. Confirm the setting, its scope and enforcement on the intended managed devices before relying on it.

Defender's updated plug-in documentation is more explicit about limitations. It applies to Defender for Endpoint Plan 2 and requires an onboarded Windows host; container support requires WSL 2.9.12 or later. The page excludes ARM64 processors and multi-session Windows variants. It also says antimalware, threat and vulnerability management, and response commands are unavailable for the WSL logical device. Visibility into activity is therefore not the same promise as the complete protection and response surface that a reader might associate with the Defender name.

There is a timing caveat as well. Microsoft warns that short-lived instances may not appear in the portal and that onboarding can take up to 30 minutes. Its validation guidance asks administrators to check active container VMs and their Defender health. Before expanding a pilot, we would run a representative short-lived workload and establish which records the security team actually receives. A dashboard containing a healthy long-running test instance would not, by itself, answer whether the team's brief build jobs are observable in the way its incident process requires.

WSL's broader enterprise guidance assigns ongoing work to the operator. Microsoft recommends Linux configuration-management tools for Linux user space. It also explains that access to Windows files follows the permissions of the Windows user who started WSL: Linux root does not confer Windows administrator rights. That boundary is useful, but it is not a guarantee that a mounted working directory cannot be altered. A user may already have substantial access to valuable source files. In our view, pilot design should inventory the files exposed to a workload, not just celebrate that the workload runs inside a container.

The strongest first deployment is consequently a bounded one. Choose a workload whose lifecycle the team can describe, whose storage can be reproduced and whose network requirements can be checked under its normal VPN and firewall configuration. Assign ownership for runtime versions, image updates, retained data and failure cleanup. Then compare the full workflow with the existing setup. Microsoft has made another execution path available on Windows. Whether it reduces operational work depends on the surrounding application contract, not the number of installation steps removed from a demonstration. Keep the migration decision attached to that evidence.

LaunchPad positionEvaluate the complete application lifecycle, storage boundaries and observable security events before replacing an existing container workflow.