Docker Desktop makes WSL 2 a supported backend

The difficult part of a desktop container environment is connecting the developer's tools and files to the system that runs the containers. Docker's WSL 2 backend changes those connections. In its 20 May account of the integration, Docker confirms that Desktop 2.3.0.2 has reached general availability for WSL 2. The same account describes the Windows 2004 release as imminent. Docker's backend milestone and the operating-system rollout are related events with distinct dates.

The Windows release notes date Desktop 2.3.0.2 to 11 May. They add support for Windows 10 Home through WSL 2, requiring Windows 10 version 2004 or later. Compatible installations now default to the WSL 2 backend. That makes this more than another preview option for developers already following the integration.

I value Docker for reducing differences between development environments through repeatable build descriptions and images. A supported backend matters when it reduces the differences surrounding those artifacts too. Source-file access and the tools executing a build remain part of the development environment, even when the resulting image is intended to be transferable.

Isolation survives the move into WSL

The architecture behind this release dates to the October 2019 redesign. Docker moved away from running the daemon directly inside the user's distribution. The replacement runs its LinuxKit components inside an isolated environment, with a bootstrapping distribution and a separate distribution for persistent Docker data. It reuses components from the Hyper-V and Mac backends.

This was a response to concrete maintenance problems. Docker described networking conflicts when applications in the user's distribution altered networking state, including competing daemons changing iptables rules. Isolating the environment gives Docker more control over what it has to diagnose. A user distribution can still contain the developer's tools without also becoming the uncontrolled host for every part of Desktop's implementation.

The integration uses cross-distribution mounts and an API proxy that translates paths to locations accessible from the LinuxKit environment. Those mechanisms explain how separation can coexist with access to the developer's working files. Running Docker in a controlled environment does not require copying the entire development workflow into that environment. It does require a precise way to connect the two.

Source-file placement changes the work performed

Docker's 4 May guidance recommends keeping Linux-container project files inside the chosen WSL distribution and running the CLI there. The user distribution and Docker's distribution share the utility virtual machine, kernel and filesystem cache. Bind mounts from those Linux files do not need a remote file-sharing system. Files accessed through a Windows mount such as /mnt/c instead pass through a Plan 9 share.

The distinction is about where an operation goes. Starting a command from a Linux shell does not by itself move a project out of the Windows filesystem. A project reached through /mnt/c still follows the Windows-file access path. For a source-heavy build or a process that repeatedly reads source files, the project location is therefore part of the execution design.

That is a useful way to interpret the backend change without assuming that every workload becomes faster by a fixed amount. The integration can avoid a particular sharing mechanism when both sides use the Linux filesystem. The benefit depends on actually arranging the working tree that way. A backend checkbox cannot infer that a project's files should move or decide where its other tools expect to find them.

I prefer this explanation to treating WSL 2 as a general performance promise. It identifies a concrete source of extra work and a configuration that avoids it. It also preserves the distinction between an image's contents and the source files mounted into a development container.

Installation includes a separate kernel requirement

Microsoft's March description of WSL 2 servicing says it removed the Linux kernel from the Windows operating-system image. The intended servicing path uses Windows Update independently of a Windows image update. The initial Windows 2004 experience temporarily requires installing the kernel package manually. Microsoft describes a one-time message directing the user to the kernel download.

Desktop's release notes reflect that dependency. The installer detects a missing Linux kernel and points to Microsoft's download documentation. It also checks whether firmware virtualization is enabled. These checks concern prerequisites that Docker cannot satisfy merely by installing its own application files. A compatible Windows version is necessary, but it is not the entire account of whether the backend can start.

This separation is useful operationally. A missing kernel package is a different condition from a failing Docker service after startup. Reporting it during installation gives the user a more specific explanation. It also makes the ownership of the update clearer. Desktop integrates with the WSL environment while Microsoft supplies the kernel and its servicing mechanism.

Supporting Home changes the eligible machines

Docker's May account traces Windows Home support to work introduced in March. That configuration removes the old Hyper-V Moby virtual-machine functionality and Windows-container options, which the account says Home does not support. Windows Pro users retain the ability to switch to Windows containers. The Home addition therefore concerns Linux-container development through WSL 2, rather than a promise that every Desktop mode now works on every Windows edition.

The distinction matters to anyone comparing setups across developers' machines. Edition compatibility can affect which local workflow is available even if everyone uses the same image references. The WSL integration broadens access to the Linux-container workflow. It does not erase the differences between Linux-container and Windows-container execution.

A supported configuration also needs evidence across the relevant operating-system versions. Docker's April testing account describes adding WSL-capable Windows machines to its test matrix. It creates Azure runner images with Packer, verifies required software with InSpec, and checks canary runners before updating the end-to-end test configuration. Windows Home runners need a VNC server for investigation because Home lacks Remote Desktop support.

Those details explain why edition support is an engineering task beyond changing an installer condition. The maintainers need to create the environment repeatedly and investigate its failures. The diagnostic path itself can differ between editions. Automated preparation and verification make that difference an explicit part of the supported setup.

Release fixes expose the remaining boundaries

The 2.3.0.2 notes include chmod and chown support on WSL 2 bind mounts and correction of host-port exposure so a Linux port is exposed only when its Windows counterpart is available for the corresponding application to use. They also list unresolved cases involving Swarm bind mounts and multiple containers mounting files outside the root mount point. These are specific interactions between the environments that the integration connects.

They matter because a familiar command can span more than one system. A service visible inside Linux still needs an available Windows port if the integration exposes it there. A bind mount still has to retain the intended filesystem behavior. Supporting the backend means implementing those connections, and the documented limitations identify cases in which the connection remains incomplete.

The notes also describe detecting when the WSL 2 backend stops and allowing the user to restart it. This gives Desktop a recovery operation for a condition below the application containers. Restarting an application cannot correct the absence of its hosting environment. Detecting that state lets the interface offer an action at the level where execution has stopped, instead of leaving the user to interpret every application failure independently.

File-sharing corrections in the same release include missed updates after a container restart under load and event handling on long paths. These details matter for development loops that depend on noticing source changes. An application can remain running while working with stale inputs if the sharing path fails to deliver the update. Container lifecycle and source-file visibility therefore need separate observation, even when the dashboard presents the application as a single running unit.

Resource allocation requires similar attention. Docker's May guidance notes that WSL 2 can use the machine's CPU and memory resources and recommends container resource limits. Access to more resources is useful for a build, but a developer's machine also runs editors and other applications. The supported backend makes Linux-container development available on more Windows installations while leaving resource policy and working-tree placement as explicit parts of the local environment.