WSL containers vs Docker Desktop
Both run Linux containers on Windows through a Hyper-V virtual machine, so the interesting differences are not about speed. They are about what is missing. Docker Desktop is a platform; WSL containers is a runtime. If you compare them as products, wslc loses on features and wins on weight, licensing and file I/O.
This page is written to help you decide, which means the "what you give up" section is longer than the "what you gain" section. That asymmetry is honest, not editorial.
On this page
The short answer
Switch to wslc if you build and run single containers, want no background daemon eating RAM, need fast Windows-to-container file access, or cannot justify a Docker Desktop subscription.
Stay on Docker Desktop if you run Compose stacks, need Swarm or Kubernetes,
build multi-platform images with buildx, rely on restart policies, or use
Testcontainers in your test suite.
Architecture: daemon vs daemonless
Docker Desktop installs a dedicated WSL 2 distribution (docker-desktop) and runs
dockerd inside it as a long-lived daemon. Your docker CLI on Windows
talks to that daemon over a named pipe. The daemon owns all state, stays resident, and is the
thing that keeps consuming memory when you have no containers running.
wslc has no daemon. The wslc.exe CLI calls a Windows host service that starts a
dedicated Hyper-V utility VM on demand and launches each container as a process inside it. When
nothing is running there is nothing resident to pay for. This is the same isolation model Windows
Sandbox uses, which is why the VM boots in a couple of seconds rather than like a full distro.
The practical consequences of that difference show up in three places: idle memory, cold-start
time on the first command after a boot, and the fact that wslc exposes a native programmatic API
(Microsoft.WSL.Containers, distributed as a NuGet package) so a C#, C or C++ Windows
application can start and control containers inside its own process. Docker has no equivalent that
does not involve shipping the daemon.
Feature matrix
| Capability | WSL containers (wslc) | Docker Desktop |
|---|---|---|
| Build and run OCI containers | Yes | Yes |
| Background daemon | None (on demand VM) | dockerd, always resident |
| Idle memory footprint | ~0 when idle | ~1–2 GB typical |
| Host file sharing | VirtioFS, up to 2× faster | 9p / gRPC-FUSE |
| Networking | Routes through Windows host stack; inherits VPN, proxy, firewall | NAT with port proxy; VPN needs config |
| GPU passthrough | Yes via CDI, /dev/dxg | Yes via --gpus |
| Compose | No | Yes |
| Kubernetes | No | Bundled |
| Swarm | No | Yes |
Multi-platform buildx | No | Yes |
| Restart policies | No | Yes |
| Graphical dashboard | WSL Container Desktop (basic) | Full GUI + extensions |
| Programmatic API for Windows apps | NuGet package | No |
| Windows containers | No (Linux only) | Yes |
| Licence cost for large companies | Free (part of Windows) | Paid subscription |
| Production readiness | Public preview | Stable, mature |
Performance and resource use
The headline number is file I/O. Docker Desktop shares Windows directories into the Linux VM over
a network-filesystem-style path, which is why npm install against a
C:\ bind mount has been painfully slow for years. wslc uses VirtioFS, a paravirtualised
filesystem, and Microsoft reports up to twice the throughput for host directory access. For
workloads dominated by many small file operations — Node, PHP, Python, anything with a large
dependency tree on a bind mount — this is the difference you will actually feel.
Idle memory is the second real gain. Docker Desktop's daemon plus its WSL distribution typically hold 1–2 GB whether or not you are running containers. wslc's utility VM only exists while containers do, so on a 16 GB laptop that is a meaningful chunk of headroom returned to your editor and browser.
What does not change much: CPU-bound container throughput. Both run the same Linux kernel under the same hypervisor, so a compile inside a container performs about the same either way. Anyone claiming large CPU gains from switching runtimes is measuring something else.
Cold start caveat. The on-demand VM is a trade. The first wslc
command after a Windows boot pays a VM start cost of a few seconds that Docker Desktop has
already paid during startup. If your workflow is dozens of short-lived container invocations in
scripts, benchmark it rather than assuming wslc is faster.
Licensing and cost
This is the reason most enterprise teams are looking at wslc at all. Docker Desktop requires a paid subscription for organisations above Docker's employee and revenue thresholds, per developer, per month. WSL containers is a Windows feature — if you are licensed for Windows 11, you are licensed for it. For a 200-developer organisation that difference is a line item large enough to fund the migration effort by itself.
There is a second, quieter compliance angle: because wslc ships with the OS, it enters the environment through the normal Windows update channel rather than as third-party software requiring separate approval, inventory and renewal. In regulated environments that is often the harder problem, not the money.
Six things you give up
1. Compose — the big one
There is no wslc compose. Multi-service local stacks are the most common Docker
Desktop use case and the least covered by wslc today. You either translate each service into a
wslc run call driven by a script, or keep Docker for those projects. The
Compose migration guide walks the translation field by field,
including the fields that have no equivalent at all.
2. Orchestration
No Kubernetes, no Swarm. Docker Desktop's one-click local Kubernetes cluster has no counterpart.
If you need local k8s alongside wslc, run kind or minikube against a
separate provider — but at that point you are running two container runtimes anyway.
3. Multi-platform builds
buildx and bake files are absent, so you cannot cross-build linux/arm64
images from an x64 machine. Teams shipping multi-arch images will need to keep that step in CI or
on Docker. wslc builds for the host architecture only.
4. Restart policies
--restart always is not implemented. Containers you want surviving a reboot need a
Windows scheduled task or a wrapper script. This is a genuine gap for anyone using containers as
quasi-services on a dev box.
5. Ecosystem tooling that assumes a Docker socket
Testcontainers, many CI runners, IDE plugins and monitoring agents look for
/var/run/docker.sock or the Windows named pipe. wslc does not expose a Docker-compatible
socket, so these do not transparently work. Some tools accept a custom CLI path, which is how the
VS Code Dev Containers extension can be pointed at wslc, but that is per-tool
goodwill rather than a general shim.
6. Stability and a moving target
wslc is a public preview behind wsl --update --pre-release. Command names have already
shifted (verb forms becoming noun forms), and flags will change again before general availability.
Docker Desktop's CLI surface has been stable for years. Do not build CI on wslc yet.
There is also a smaller difference worth knowing: wslc inspect emits OCI-shaped JSON,
not Docker's schema. Any script that greps .NetworkSettings.IPAddress or similar
Docker-specific paths will silently return nothing rather than fail loudly. Audit your automation
for JSON path assumptions before switching.
Which one should you use
| Your situation | Recommendation |
|---|---|
| Single-container build/run/debug loop | wslc — lighter, faster file I/O, no licence |
| Docker Desktop licence is a cost or compliance blocker | wslc for anything it covers, Docker only where required |
| GPU / CUDA / ML development | wslc — CDI passthrough works well and the flag is --device nvidia.com/gpu=all |
| Corporate VPN or proxy makes Docker networking painful | wslc — inherits host network config automatically |
| Multi-service Compose stack | Docker Desktop, or script the translation |
| Local Kubernetes | Docker Desktop |
| Multi-arch image publishing | Docker Desktop or CI |
| Testcontainers in your test suite | Docker Desktop |
| Windows container images | Docker Desktop — wslc is Linux-only |
| Production CI/CD pipeline | Docker — wslc is preview software |
Running both side by side
You do not have to choose globally. wslc and Docker Desktop use separate utility VMs, separate image stores and separate control channels, so they coexist without port or socket conflicts. Run wslc for day-to-day single-container work and fall back to Docker for the Compose projects.
The cost is disk. Nothing is shared between the two image stores, so an image you have in Docker
must be pulled again for wslc and occupies space twice. On a machine with a small SSD, plan for
roughly double your current image footprint, and prune both stores independently
(docker system prune and wslc system prune).
A pragmatic pattern that works well: point VS Code Dev Containers at wslc as the
default, and keep Docker Desktop installed but set to not start on login. You then start it
manually only for the projects that need Compose, which recovers most of the idle-memory benefit
while keeping the escape hatch.
FAQ
- What is the difference between WSL containers and Docker Desktop?
- WSL containers is a built-in Windows feature that runs OCI containers daemonless inside a Hyper-V utility VM, driven by the wslc CLI. Docker Desktop is a third-party product that runs a Docker daemon inside its own WSL 2 distribution and adds Compose, a GUI, Kubernetes, extensions and buildx. wslc is lighter and licence-free but covers only single-container build-and-run workflows.
- Is wslc faster than Docker Desktop?
- For host file access yes — wslc shares directories over VirtioFS, which Microsoft measures at up to twice the throughput of the older sharing path, and there is no idle daemon consuming memory. Raw container CPU throughput is comparable because both run Linux under Hyper-V.
- Should I replace Docker Desktop with WSL containers?
- Replace it if your workflow is single-container build, run and debug, or if Docker Desktop licensing is a cost or compliance problem. Keep Docker Desktop if you depend on Compose stacks, Swarm, multi-platform buildx builds, restart policies, or Testcontainers-style integration tests.
- Can WSL containers and Docker Desktop run at the same time?
- Yes. They use separate utility VMs and separate image stores, so there is no port or socket conflict. The cost is duplicated images and roughly double the disk footprint, since nothing is shared between the two stores.