Docker on Windows 2026: Desktop, WSL2, Rancher, Podman

Docker on Windows in 2026 means picking one of four routes — Docker Desktop, Docker Engine inside a WSL2 distro, Rancher Desktop, or Podman Desktop — because Docker, Inc. tightened the Subscription Service Agreement so that any company over 250 employees or $10M annual revenue (and every government entity, regardless of size) must buy a paid plan to run Docker Desktop. Pick wrong and you get a license invoice, a 10× slowdown on bind-mounted source, or a dev-container setup that silently fails to find the daemon. Pick right and you get the same Linux containers VS Code, Compose, and your CI runners already speak — for free, on Windows Home, with a startup time measured in seconds.

What Licensing Rule Pushes Most Teams Off Docker Desktop?

Section 4.2(a) of the Docker Subscription Service Agreement is the line that decides this for your finance team. Free use of Docker Desktop is permitted only for non-commercial open source work, or commercial use by an organization with fewer than 250 employees AND less than US $10,000,000 in annual revenue. Cross either threshold and you need a paid Subscription. Government entities are excluded from the free tier entirely — even a five-person municipal team must purchase Docker Pro, Team, or Business.

Pricing as of the December 2024 update: Pro is $9/user/month annually ($11 monthly), Team is $15/user/month annually ($16 monthly, up to 100 users), and Business is $24/user/month with no annual discount. Business adds SSO/SAML, SCIM, and Advanced Container Isolation, and is mandatory above 100 users or for regulated industries (HIPAA, SOC 2). New annual Business or Team contracts have a 25-seat minimum; existing customers must add at least 10 seats per amendment.

What Are the Four Ways to Run Docker on Windows?

Every option below uses a Linux VM under the hood — Windows itself cannot run Linux containers natively. The differences are how the VM is provisioned, what runtime sits inside it, what GUI ships on top, and who pays for it.

When Should You Use Docker Desktop?

Docker Desktop is still the right choice when (a) your company qualifies for the free tier or has already paid, (b) you actually need the GUI for image/container/volume management or the bundled tools (Docker Scout, Build Cloud, the Compose UI), or (c) you need to run native Windows containers. It also has the deepest Docker Hub and BuildKit integration, the smoothest first-run experience, and the only supported path to running both Linux and Windows containers from a single CLI on the same box.

Microsoft Learn still recommends Docker Desktop with the WSL2 backend as the default for new Windows developers, with the explicit caveat that you cannot run Linux and Windows containers simultaneously, and that installing Docker Engine directly in WSL is the documented workaround.

How Do You Install Docker Engine in WSL2?

Microsoft and Docker both document this path. Open an admin PowerShell, install WSL2 with a distro (Ubuntu is the path of least resistance), then install the official docker-ce packages from download.docker.com inside that distro. Modern WSL2 ships with systemd enabled by default, so the daemon starts and stays started without the older shell-rc hacks.

# One-shot: enables the WSL feature, installs the kernel, and sets v2 default
wsl --install -d Ubuntu

# Or, if WSL is already enabled:
wsl --set-default-version 2
wsl --install -d Ubuntu

# Verify
wsl -l -v

# Set up Docker's apt repository (official instructions, docs.docker.com/engine/install/ubuntu)
sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Run docker without sudo
sudo usermod -aG docker $USER
# (Close and reopen the WSL shell to pick up the group)

# Verify
docker run --rm hello-world

Does VS Code Dev Containers Work With Docker in WSL2?

Yes — and it is officially documented. Install the WSL extension and the Dev Containers extension, open the project from inside the WSL distro (code . from the WSL shell, or open \\wsl.localhost\Ubuntu\home\...), then run Dev Containers: Reopen in Container. The extension talks to the Docker socket inside WSL, the same as it does on a native Linux box. For details on how the devcontainer.json stack works, see our Dev Containers guide.

One toggle to know about: in VS Code settings, enable Dev Containers: Execute in WSL if you opened the project from a Windows path. This forces the extension to spawn the Docker CLI inside the WSL distro instead of trying to find a Docker socket on the Windows side. Without it, Dev Containers will fail with a Cannot connect to the Docker daemon error and you will start Googling. With it on, everything just works.

Why Are Bind Mounts From /mnt/c So Slow?

WSL2 exposes Windows drives at /mnt/c, /mnt/d, etc. via the 9P protocol — a network filesystem running over the VM boundary. Every stat(), every directory walk, every file watch crosses that boundary, and the cost compounds catastrophically on workloads with many small files. Community measurements consistently report 10× or worse slowdowns versus the WSL ext4 home directory:npm install hangs for minutes, Vite/webpack file watchers miss changes, Django reloads stretch from 2 seconds to half a minute.

The fix is to stop storing source under C:\Users\. Clone repos under ~/ inside WSL (which lives on an ext4 VHDX) and access them from Windows tools through the \\wsl.localhost\Ubuntu\home\you\repo UNC path when needed. For high-churn directories like node_modules, push them into a Docker named volume even when the rest of the source is bind-mounted.

services:
  web:
    build: .
    volumes:
      - .:/app                     # bind source for hot reload
      - node_modules:/app/node_modules   # avoid 9P slowdown on the hot path

volumes:
  node_modules:

What About Rancher Desktop and Podman Desktop?

Both are legitimate free, open-source alternatives that fill the GUI-shaped hole left by skipping Docker Desktop.

• Rancher Desktop (maintained by SUSE, Apache 2.0) installs a dedicated WSL2 distro, lets you choose between the dockerd and containerd runtimes at install time, and ships k3s for one-click Kubernetes. The docker and nerdctl CLIs work out of the box. It is the closest like-for-like Docker Desktop replacement and the right pick when your team needs a GUI but cannot get a license signed off.
• Podman Desktop (Red Hat, Apache 2.0) runs a daemonless, rootless container engine inside WSL2 or Hyper-V. The CLI is mostly Docker-compatible — most teams alias docker=podman and move on. Podman natively understands pods, the Kubernetes primitive, which is why it is the default in OpenShift shops. Trade-off: Docker Swarm and a few Compose edge cases are not supported.

OrbStack is a frequent name in the alternatives lists, but it is macOS only — there is no Windows build, so it does not factor into this decision.

How Do You Pick the Daily Docker Commands You Will Actually Use?

Once Docker is running — by whichever route — the day-to-day CLI surface is identical to Docker on Linux. For a printable copy-paste reference of run, build, exec, logs, and prune commands, see the Docker cheat sheet. For multi-container workflows, the Docker networking guide covers user-defined bridges, port publishing, and the macvlan/host edge cases — none of that changes on Windows.

When Should You NOT Use Docker in WSL2?

• You need native Windows containers. Windows Server Core, Nano Server, and IIS images cannot run inside a Linux VM — the kernel is wrong. Docker Desktop with the Windows Containers feature (or Microsoft's containerd on Windows Server) is the only supported path.
• You want a bundled, one-click local Kubernetes cluster. Docker Desktop and Rancher Desktop both ship this; standalone Docker in WSL2 does not. You can install kind, k3d, or minikube on top in five minutes, but if that five minutes is friction your team will not absorb, pick Rancher Desktop.
• Your security team requires rootless containers. Docker in WSL2 still runs the daemon as root; the docker group on the host is effectively root-equivalent. Use Podman Desktop (rootless by default) or run Docker rootless mode explicitly.
• You rely on Docker Desktop-specific features. Docker Build Cloud minutes, Docker Scout, the new Compose UI, and the Settings > Resources > WSL Integration toggle all live in the Desktop app. If a workflow depends on them, you are buying the license, not skipping it.

Should You Use Hyper-V Backend Instead of WSL2?

No, in almost every case. Docker Desktop's Hyper-V backend is the legacy path from before WSL2 supported containers natively. The WSL2 backend boots faster, integrates with \\wsl.localhost for file access, shares memory dynamically with the host, and is the path Microsoft and Docker actively invest in. The only reason to stay on Hyper-V is if your enterprise security policy disables WSL — and even then, Podman Desktop with the Hyper-V provider is a cleaner solution than legacy Docker Desktop.

References

• Docker Subscription Service Agreement — the legal text behind the 250 employees / $10M revenue thresholds (Section 4.2).
• Docker Desktop license agreement — official summary of who needs to pay, including the government-entity carve-out.
• Install Docker Engine on Ubuntu — the apt-repository instructions used inside the WSL distro.
• Microsoft Learn: Get started with Docker containers on WSL — Microsoft's own guidance, including when to install Docker Engine directly in WSL.
• VS Code: Using Dev Containers in WSL 2 — the Dev Containers + WSL workflow this guide recommends.
• Rancher Desktop — open source, Apache 2.0, free for any company size, k3s built in.
• Podman Desktop on Windows — daemonless, rootless container engine with WSL2 or Hyper-V provider.
• Docker Docs: WSL 2 best practices — the official source on the /mnt/c performance trap.