18.1.1 Desktop Local Runtime

The Desktop local runtime is the specific virtualization backend Docker Desktop uses underneath its own interface to actually host the Linux environment running the Docker daemon, and this backend differs by host operating system and, on some platforms, by explicit user choice, with real performance and compatibility implications depending on which one is actually in use.

macOS virtualization backends

On macOS, Docker Desktop has used different underlying virtualization technologies over its history, transitioning from HyperKit toward Apple's own Virtualization.framework, which generally provides better performance and tighter integration with the host operating system's own virtualization capabilities:

Settings > General > Choose the virtualization framework: Apple Virtualization Framework

docker info --format '{{.OperatingSystem}}'

Confirming which framework is actually active, particularly after a Docker Desktop upgrade that might have changed the default, clarifies which underlying technology is responsible for a given performance characteristic or compatibility behavior currently being observed.

Windows backend options: WSL2 versus Hyper-V

On Windows, Docker Desktop has historically supported two distinct backend options, WSL2 (Windows Subsystem for Linux version 2) and Hyper-V, with WSL2 now the default and generally recommended choice due to its improved performance and lighter resource footprint:

Settings > General > Use the WSL 2 based engine

wsl --status

The WSL2 backend integrates more directly with Windows's own lightweight Linux subsystem rather than requiring a full, separate Hyper-V virtual machine, which generally produces faster startup times and lower baseline resource consumption, though Hyper-V remains available and may still be relevant for specific compatibility scenarios or organizational policy requirements that mandate it specifically.

Performance implications of backend choice

The choice of backend directly affects file sharing performance, container startup time, and general resource efficiency, which means a performance issue observed on one backend may not reproduce, or may behave quite differently, on another, even with an otherwise identical Docker configuration and workload:

time docker run --rm alpine echo hello

Measuring basic container startup time directly, and comparing it across different backend configurations if a performance issue is suspected to be backend-related, isolates whether the underlying virtualization technology itself, rather than anything about the specific containers or images involved, is contributing to an observed slowdown.

File system integration differences between backends

Each backend has its own specific approach to bridging the host filesystem and the Linux environment for bind mounts, which produces the file-sharing performance and permission behavior differences covered in dedicated bind mount troubleshooting content; understanding which backend is actually in use is a necessary first step before investigating any file-sharing-specific symptom, since the relevant behavior genuinely differs between them.

docker run --rm -v "$(pwd)":/test alpine ls -la /test

Switching backends and what to expect

Switching from one backend to another on the same machine is generally supported through Docker Desktop's own settings interface, but existing containers, volumes, and images may need to be recreated or migrated, since the underlying storage representation can differ meaningfully between backends:

Settings > General > Use the WSL 2 based engine [toggle]

Reviewing Docker Desktop's own release notes and migration guidance before switching backends on a machine with significant existing state, rather than assuming a seamless, lossless transition, avoids losing track of existing containers, volumes, or images during the switch.

Diagnosing backend-specific issues

When troubleshooting a problem that seems specific to Docker Desktop rather than to Docker behavior generally, confirming which specific backend is active, and checking whether the same issue is documented as a known behavior or limitation specific to that backend, often resolves the investigation faster than treating it as a general, backend-agnostic Docker problem:

docker info

Operating System: Docker Desktop
Kernel Version: 5.15.0-microsoft-standard-WSL2

The kernel version string here directly confirms WSL2 is the active backend on Windows, which is useful, specific evidence when searching for or reporting a backend-specific issue rather than a more general Docker behavior question.

Resource allocation differences between backends

Each backend may have its own specific resource allocation behavior and defaults, separate from Docker Desktop's own general resource settings, and confirming the actual, effective resource allocation through the backend's own native tooling, rather than only Docker Desktop's interface, provides a more complete picture when investigating a resource-related performance question:

wsl --status

docker info --format '{{.NCPU}} {{.MemTotal}}'

Comparing what Docker itself reports against what the underlying backend's own native tooling reports for the same resource allocation confirms whether the two are consistent, or whether a mismatch between Docker Desktop's configured settings and the backend's own actual allocation might be contributing to an observed issue.

Common mistakes

• Assuming Docker Desktop behaves identically across every host operating system and backend without confirming which specific virtualization technology is actually in use on a given machine.
• Investigating a performance or compatibility issue without first confirming whether it is specific to the active backend rather than a general Docker behavior.
• Switching backends on a machine with significant existing containers, volumes, or images without reviewing migration guidance first, risking losing track of that existing state.
• Comparing performance observations across machines using different backends without accounting for the backend itself as a meaningful variable in that comparison.
• Not checking the backend's own native resource allocation tooling when investigating a resource-related question, relying solely on Docker Desktop's own reported settings.

The Desktop local runtime, whichever specific virtualization backend is actually active on a given machine, is a meaningful variable affecting performance, file-sharing behavior, and certain compatibility characteristics, and confirming which backend is in use is a useful, often overlooked first step whenever troubleshooting a Docker Desktop-specific issue rather than a general Docker behavior question.