Skip to main content
Containers share the host OS kernel. That fundamental constraint means you cannot run a Windows container on a Linux host or a Linux container on a Windows host. Keep this kernel-sharing rule in mind as you choose how to run Docker on Windows.
Containers reuse the host kernel — this is why a Windows host runs Windows containers and a Linux host runs Linux containers. When running Linux workloads on Windows, Docker provides a Linux kernel via a small VM or WSL2.
An infographic titled "Containers Share the Host Kernel" comparing a Linux host and a Windows host. It shows that a Linux host can only run Linux containers (Windows containers crossed out) and a Windows host can only run Windows containers, illustrating containers must use the host kernel.
What are the practical choices for running Docker on Windows? Historically there were two main approaches: the legacy Docker Toolbox and the modern Docker Desktop for Windows. Docker Desktop is the recommended, supported path today, but understanding Toolbox helps explain how Docker on Windows evolved.
A slide titled "Two Options for Docker on Windows" comparing Docker Toolbox (the older, legacy approach bundled with VirtualBox and deprecated since 2020) with Docker Desktop for Windows (the modern, recommended native install using WSL2 or Hyper‑V).
  • Docker Toolbox (legacy)
    • Provided an all-in-one installer (VirtualBox, Docker Engine, Docker Machine, Docker Compose, Kitematic UI).
    • Packed a tiny Linux VM (Boot2Docker) and ran Linux containers inside that VM on Windows hosts.
    • Could not build or run Windows images — Toolbox only ran Linux containers.
    • Deprecated (no longer maintained since 2020). If you’re on modern Windows (10/11), use Docker Desktop instead.
  • Docker Desktop (recommended)
    • The modern developer workstation product for Windows 10 and Windows 11 (all editions, including Home).
    • Provides a small Linux runtime environment so Linux containers can run on a Windows host.
    • Supports two backends for Linux containers: WSL2 (recommended) and Hyper‑V (legacy/alternate).
Docker Toolbox was useful when native Linux support on Windows was immature; today Docker Desktop gives a smoother experience and better performance. Docker Desktop supports two backends for running Linux containers. The default and recommended backend is WSL2 (Windows Subsystem for Linux, version 2). The alternate (older) backend is Hyper‑V. Both run Docker on a Windows host, but they differ in architecture and system requirements.
A side-by-side comparison graphic titled "Two Backends · WSL 2 vs Hyper-V." The left panel recommends WSL 2 (real Linux kernel, fast filesystem, low memory), while the right panel labels Hyper-V as a legacy backend that boots a full Linux VM and is limited to certain Windows editions.
Key notes:
  • WSL2 has been Docker Desktop’s default backend since March 2020 and does not require the full Hyper‑V role (it uses the Windows Hypervisor Platform/Virtual Machine Platform components).
  • Hyper‑V requires the Hyper‑V role and is only available on Windows Pro, Enterprise, and Education editions. It boots a traditional VM and generally has higher overhead than WSL2.
Docker Desktop runs on Windows 11 and Windows 10 (supported releases). Important: Docker Desktop is a developer workstation product and is not supported on Windows Server. For Windows Server you should install the Docker Engine directly or use a supported commercial runtime (for example, Mirantis Container Runtime).
Docker Desktop is not supported on Windows Server. For Windows Server (2016/2019/2022+) install Docker Engine directly or use a supported commercial runtime such as Mirantis Container Runtime.
An infographic titled "Windows Server · Different Path" with a red banner saying "Docker Desktop is not supported on Windows Server." It shows options for Windows Server (2019, 2022, 2025) recommending Docker Engine (install on server) or Mirantis Container Runtime as the commercial path.
Everything covered so far refers to running Linux containers (Linux applications packaged into Linux Docker images). Both Toolbox and Docker Desktop default to running Linux containers on Windows unless you explicitly switch Docker Desktop into Windows containers mode.
A presentation slide titled "So Far · All Linux" showing a boxed list of topics — "Linux containers," "Linux applications," and "Linux Docker images" — with a note that Toolbox and Docker Desktop default to running Linux containers on a Windows host.
Windows containers: support and isolation modes Microsoft added Windows container support with Windows Server 2016. Windows containers allow you to package Windows applications into Windows Docker images and run them on a Windows Docker host. Docker Desktop starts in Linux containers mode by default; to run Windows containers switch via the Docker system tray icon (right-click the Docker icon and choose “Switch to Windows containers”). There are two isolation modes for Windows containers:
  • Windows Server containers (process isolation): containers share the host Windows kernel — conceptually similar to Linux containers.
  • Hyper‑V isolation: each container runs inside a lightweight VM with its own kernel for stronger isolation and to handle kernel version/configuration differences.
A side-by-side infographic titled "Two Flavors of Windows Containers." It contrasts Windows Server Containers that share the host Windows kernel with Hyper‑V isolation where each container runs inside its own VM with its own kernel.
When authoring a Windows Docker image you still specify a base image at the top of the Dockerfile. The two common Windows base images are windows/servercore and windows/nanoserver. Nano Server is a small-footprint, headless base (similar in spirit to Alpine Linux), while Server Core provides a larger Windows API surface.
Windows containers are supported starting with Windows Server 2016 and on Nano Server. On Windows 10 and Windows 11 client editions, Docker Desktop commonly uses Hyper‑V isolation to ensure compatibility (containers run in a lightweight VM); on Windows Server you can often use Windows Server (process) isolation where the host kernel is shared.
An infographic titled "Where Windows Containers Run" showing three colored boxes labeled "Windows Server 2016+", "Nano Server", and "Windows 10 / 11 — Pro & Enterprise." A highlighted orange bar notes that on Windows 10/11 Pro & Enterprise Hyper‑V isolation is always on and each container runs in its own optimized VM.
A historical compatibility note: the claim that VirtualBox and Hyper‑V cannot coexist is largely historical. VirtualBox 6.0 introduced Hyper‑V coexistence support, and modern WSL2 leverages the Windows Hypervisor Platform rather than requiring the full Hyper‑V role. If you have an older Windows/VirtualBox setup, you may need to migrate or update components when moving from Toolbox/VirtualBox to Docker Desktop/WSL2.
A slide titled "Old Worry · Mostly History" showing the crossed-out claim that VirtualBox and Hyper-V can't coexist. It notes VirtualBox 6.0 added Hyper-V coexistence support and that modern WSL2 doesn't use Hyper-V, so the restriction has mostly faded.
Recommendation and quick guidance
  • For most developers on modern Windows (10/11, any edition), use Docker Desktop with the WSL2 backend — it provides the best performance and compatibility for Linux containers.
  • Use Hyper‑V backend only when WSL2 cannot be enabled or you have a specific requirement.
  • For Windows Server hosts, install Docker Engine directly or use a supported commercial runtime for production.
  • If you need Windows containers, choose your base image carefully (windows/nanoserver vs windows/servercore) and pick the appropriate isolation mode (process vs Hyper‑V) based on compatibility and security needs.
An infographic titled "Docker Desktop · WSL 2 Is the Answer" showing a highlighted comparison of Docker deployment options. It lists four rows — Docker Desktop (WSL2), Docker Desktop (Hyper‑V), Docker Engine on Server, and Mirantis Container Runtime — with short notes on use cases and supported Windows/Server versions.
Further reading and references

Watch Video