Docker Desktop migrates existing WSL installations to one distribution

A simpler installation architecture is only part of a rollout if existing installations retain the old layout. Fresh installations can adopt new defaults without moving stored data, while an upgrade has to reconcile an existing environment with the new implementation. Docker Desktop's WSL change reaches that second stage in 4.36.

The November 18 release notes say existing Windows installations using the WSL 2 engine now migrate automatically to a single-distribution architecture. Docker's November 22 announcement describes the reduction from two Docker-managed WSL distributions to one. The consequential change this month is coverage of existing installations.

I value Docker's ability to make an application's environment transferable. The desktop backend still has a local lifecycle, including its storage and upgrade behavior. Reducing differences between fresh and upgraded installations makes that backend easier to describe without confusing it with the contents of the application image.

The rollout began with fresh installations

Docker's 4.30 announcement in May described an incremental first phase for fresh installations. It reduced the two Docker Desktop WSL distributions to one and identified migration of existing data as work for a subsequent update. That announcement separates the architectural change from the task of applying it to an established installation.

The 4.30 release notes called the simplified WSL provisioning mode experimental. They described avoiding the ancillary docker-desktop-data distribution. It is therefore inaccurate to describe 4.36 as the first release with any single-distribution setup. November extends the rollout to the installed population that still needs migration.

The earlier announcement linked simplification to code maintainability and failure handling. Those goals explain the direction without establishing a measured speed improvement for a particular laptop. Neither announcement supplies a benchmark methodology or a quantified improvement that can be applied to every existing installation.

The distinction is useful when evaluating the work. Removing a distribution from new provisioning changes how the system starts life. Automatically migrating existing installations also has to preserve the operational role of their stored data. The release notes announce that migration, but do not expose every internal data-copy or recovery operation.

One distribution does not mean no persistent data

The named change concerns Docker-managed WSL distributions. It should not be interpreted as removal of container data or elimination of the distinction between system code and persistent storage. A distribution count describes packaging of the backend, not whether application state still needs storage.

Docker's November announcement discusses separation of data and system files and relocation of data to another drive. Those concerns remain relevant in a simplified backend. Fewer distributions can coexist with explicit management of the data used by containers and images.

The release notes scope the automatic migration to Windows installations using the WSL 2 engine. That is the reliable platform statement for this feature. Other Desktop backends and host operating systems have their own implementation, so their storage behavior should not be inferred from the WSL distribution count.

For someone explaining the upgrade, the useful before-and-after description is consequently narrow. Existing WSL installations join the single-distribution architecture already introduced for fresh installations. The change standardizes that part of the backend's installation layout while leaving persistent-data management as an explicit responsibility.

Central policy management addresses another source of differences

Desktop 4.36 also introduces early-access administration capabilities for Docker Business. The announcement describes managing settings through the Admin Console, importing existing admin-settings.json configurations, and exporting policies as JSON. It also supports applying a policy to a smaller group before wider deployment.

These capabilities concern configuration distribution rather than WSL storage migration. A common backend layout does not establish common settings across a fleet. Central policy management gives administrators another way to supply and enforce those settings.

The early-access designation matters. Docker's announcement separately describes prospective work such as additional compliance reporting. Those plans are not evidence that every proposed management capability is already delivered in 4.36. The current release should be described through the functions it actually makes available.

Sign-in enforcement gains support for multiple organizations through allowedOrgs. The announcement names supported configuration methods including Windows Registry settings and macOS configuration profiles. The macOS profile mechanism and PKG deployment are also early-access additions, with the installer intended for bulk deployment.

These changes affect how an organization distributes and governs the desktop application. They do not change the application's Dockerfile or establish access permissions inside a service running in a container. Keeping those scopes separate helps make a fleet's intended configuration understandable.

The release also clarifies a local control by keeping Desktop paused after a manual pause. Its notes describe an earlier problem in which background software could issue a CLI command and unintentionally resume the engine. Requiring manual resumption preserves the user's requested state. That is another configuration concern independent of how many WSL distributions the installation uses, and it changes the expected effect of background clients on an intentionally paused engine.

Broader socket permissions are an explicit policy choice

Enhanced Container Isolation also gains more flexible Docker socket mount rules. Docker's announcement describes permitting all containers through wildcard entries in the socket permission image list. It separately adds wildcard tags for allowedDerivedImages, avoiding the need to enumerate each specific tag for that rule.

These additions broaden what a policy can express. Allowing all containers to mount the Docker socket relaxes a restriction deliberately, even if the configuration remains centrally administered. Administrative convenience and the resulting permission set need to be evaluated as separate properties.

My preference is for that permission to remain visible in the configuration. A wildcard can accurately express an organization's intended allowance, but it should be read as the allowance it grants. Supporting a wildcard does not make its effect equivalent to an enumerated list of particular images.

The November release thus reduces installation differences while adding more options for governing configuration. Existing WSL installations migrate to the simplified distribution layout, and administrators gain early-access methods to distribute policies and specify socket allowances. Each change has its own object of control, which keeps the backend migration distinct from the permissions applied to workloads.