wslc and the Docker socket: what is missing
A recurring question from people moving to wslc: "why does my tool say it cannot find
Docker?" The answer is architectural. wslc is daemonless by design. There
is no dockerd, no /var/run/docker.sock, and no Docker Engine HTTP
API. Tools built around the Docker API cannot see wslc.
wslc run/pull/build/exec/logs | ✅ Native CLI |
| Docker Engine HTTP API | ❌ None |
| /var/run/docker.sock | ❌ Does not exist |
| DOCKER_HOST endpoint | ❌ Not implemented |
| docker context | ❌ No such concept |
Instead of a long-running daemon on a socket, the wslc service starts a Hyper-V utility VM on
demand and the CLI talks to it over a private channel. That is why idle memory is near zero —
and why socket-dependent tooling cannot attach.
## The tools that break
Any tool that speaks the Docker Engine API via DOCKER_HOST or a socket:
- docker CLI and docker compose
- Testcontainers (integration test libraries)
- nektos/act (run GitHub Actions locally)
- Rancher Desktop / Podman Desktop integrations
- Any CI agent that expects a Docker socket
## The DOCKER_HOST feature request
Microsoft tracks an API-compatible endpoint in
microsoft/WSL #40976:
"Support DOCKER_HOST via Docker Engine API-compatible endpoint in WSLC." It is a
feature request with no milestone as of mid-2026. When it lands, all of the above tools will
work against wslc with DOCKER_HOST=... — until then, they cannot.
## The silent bind-mount trap
You would think mounting the socket would fail loudly. It does not. On wslc 2.9.4.0:
```powershell
wslc run --rm -v /var/run/docker.sock:/var/run/docker.sock alpine sh -c "echo mounted"
```
...exits 0. The bind mount is accepted, so the command looks fine. But there is
no server behind that socket inside the container, and the tool fails later with a connection
error that is hard to trace back to wslc. Do not waste time on this path — there is no socket to
mount.
## Reaching a real Docker daemon
For tools that genuinely need the Docker API, run a real daemon and point them at it:
1. Install Docker Engine inside a normal WSL2 distro (free, no Docker Desktop licence).
2. Set DOCKER_HOST to that daemon for the tool in question.
3. Keep using wslc for ad-hoc containers and dev containers.
wslc and a Docker Engine inside WSL2 coexist — separate VMs, separate image stores. The cost is
pulling images twice. See the Testcontainers guide for the
concrete setup.
## Track it
Watch microsoft/WSL #40976. The
moment a DOCKER_HOST endpoint ships, this page flips from "cannot attach" to "set DOCKER_HOST
and go".