Windows Containers: Process Isolation vs Hyper-V Isolation

What Is Container Isolation?

A container is a packaged application plus its dependencies, started from an image. Isolation is the mechanism that stops that container from seeing, touching, or crashing the host and every other container running next to it. On Windows, that mechanism comes in two forms, and unlike Linux, the choice is not fixed by the platform — you pick it per container, at the moment you start it.

Think of process isolation as several tenants sharing one apartment building’s plumbing and electrical systems. Each tenant has a locked door and their own rooms, but a serious enough fault in the building’s shared infrastructure can still affect everyone. Hyper-V isolation is giving each tenant their own detached house on the same street — full separation, at the cost of duplicating some infrastructure.

With process isolation, containers share the host’s kernel. Windows virtualizes several namespaces per container — the file system, the registry, network ports, the process and thread ID space, and the Object Manager namespace — so each container believes it has its own private copy of these, while the underlying kernel instance is the one running on the host. With Hyper-V isolation, each container gets its own lightweight, purpose-built virtual machine and effectively its own kernel. The container host never shares its kernel with a Hyper-V isolated container.

Process Isolation vs Hyper-V Isolation

Both modes run identical container images and support identical Docker commands — the isolation mode is a runtime choice, not a build-time one. What differs is how much of the host each container can see, and what that costs.

Neither mode requires rebuilding an image or changing application code. A developer can build one image and run it under process isolation in a trusted internal pipeline, then run that same image under Hyper-V isolation on a host serving untrusted or multi-tenant workloads.

Why Production Environments Care

Isolation mode is not a cosmetic setting. It decides what a compromised container can reach, whether a container will start at all on a given host, and how many containers a license permits.

Multi-tenant and SaaS-style workloads — anywhere containers from different customers or trust levels land on the same host — are the classic case for Hyper-V isolation. It is also the practical fix for host fleets running mixed Windows Server versions during a staged upgrade: instead of forcing every host to the same build before any container will run, Hyper-V isolation lets an older image run safely on a newer host until the rest of the fleet catches up.

Version and Build Compatibility

Process isolation shares the host kernel, so the container image’s Windows version has to line up closely with the host’s. Hyper-V isolation supplies its own kernel per container, so it tolerates a version mismatch that process isolation will flatly refuse to start. Microsoft publishes the exact combinations that are supported:

The underlying rule is a build-number match: outside the one exception below, Windows Server containers refuse to start if the container host and the container image do not share the same OS build number. A host on build 10.0.14393 (Windows Server 2016) trying to run an image built from 10.0.16299 will fail before the container ever starts, with process isolation. Since Windows Server, version 1809, revision numbers no longer need to match — only the build number does. The one documented exception is Windows 11 hosts running Windows Server 2022 or (from the 24H2 update) Windows Server 2025 container images under process isolation, despite the build mismatch.

Installing the Prerequisites

Two separate Windows features are involved, and they are easy to conflate. Containers is the OS feature that provides the namespace and process isolation primitives containers need — it is required for both isolation modes. The Hyper-V role is only required if any container on that host will run with Hyper-V isolation.

In Server Manager, open Manage → Add Roles and Features, step through to the Features page, and select Containers. If Hyper-V isolation will also be used, select the Hyper-V role from the Server Roles page in the same wizard, work through its virtual switch and migration prompts, and let the installation restart the server. Both can be installed in the same pass through the wizard.

# Install the Containers feature (required for any Windows container, either isolation mode)
Install-WindowsFeature -Name Containers -Restart

# Install the Hyper-V role -- only required if any container will use Hyper-V isolation
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

# Confirm both installed correctly after the restart
Get-WindowsFeature -Name Containers, Hyper-V

Enabling the Containers feature and the Hyper-V role gets the isolation primitives in place, but neither installs a container runtime. On Windows Server, Microsoft publishes helper scripts that install the Moby (Docker CE) or containerd runtime along with any remaining OS configuration:

# Download and run Microsoft's Docker CE / Moby installer for Windows Server
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1
.\install-docker-ce.ps1

Windows Admin Center offers a GUI path to the same result: open the target server, select Containers under Tools, and select Install — it installs and configures Docker in the background. This is also where a good base image choice matters; container hosts running Server Core keep a smaller footprint than Desktop Experience, the same trade-off covered in Server Core vs Desktop Experience.

Running Containers With Each Isolation Mode

Once the runtime is installed, switching isolation mode is a single flag on docker run. Nothing about the image, the Dockerfile, or the application changes.

# Run a container with process isolation (shares the host kernel)
docker run -it --isolation=process mcr.microsoft.com/windows/servercore:ltsc2022 cmd

# Run the same image with Hyper-V isolation (its own lightweight VM and kernel)
docker run -it --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2022 cmd

# Confirm which isolation mode a running container is actually using
docker inspect --format='{{json .HostConfig.Isolation}}' <container-name-or-id>

# List the processes Docker sees running inside the container
docker top <container-name-or-id>

# On the host, a Hyper-V isolated container shows up as a vmwp process, not the app's process
Get-Process -Name vmwp

Windows Server hosts default to process isolation unless --isolation=hyperv is specified. Windows 10 and Windows 11 Pro/Enterprise hosts default the other way, to Hyper-V isolation, so that developer machines match production kernel behaviour. If every container on a host should run under Hyper-V isolation without repeating the flag every time, set it once in the Docker daemon configuration instead:

# Edit (or create) the Docker daemon configuration file
notepad C:\ProgramData\docker\config\daemon.json

# Add this line to force Hyper-V isolation as the default for every container
# { "exec-opts": ["isolation=hyperv"] }

# Restart the Docker service to apply the change
Stop-Service docker
Start-Service docker

If Hyper-V isolation will run inside an already-virtualized container host — a container host that is itself a Hyper-V VM — nested virtualization has to be enabled and sized correctly: at least 4 GB of RAM allocated to that VM, a processor with Intel VT-x support, and at least two virtual processors assigned to the container host VM itself. This layered setup is exactly the kind of scenario covered in Hyper-V Basics for anyone still getting comfortable with virtual switches and VM configuration versions before adding containers on top.

Isolation Mode Comparison

Troubleshooting Cheat Sheet

Final Thoughts

Neither isolation mode is strictly better — they trade off in opposite directions on the same axis. Process isolation gives up some of the hard boundary Hyper-V isolation provides, in exchange for density and speed. Hyper-V isolation gives up some of that speed to guarantee a container can never see or touch the host kernel, and to keep running when host and image versions drift apart.

In practice, the decision comes down to trust and version diversity. Trusted, single-tenant, same-build workloads belong on process isolation. Anything multi-tenant, anything running code you did not write, or any host fleet mid-upgrade belongs on Hyper-V isolation, licensing limits permitting.