This article is based on reporting originally published at TechRepublic (techrepublic.com). Original publication date: February 2020.
Windows Containers: More Than Just Docker
Microsoft’s container story on Windows is broader than most engineers realize. If you’re running Windows 10, you’re already using containers without necessarily knowing it: UWP (Universal Windows Platform) apps run inside lightweight app containers that sandbox them from the rest of the OS. Beyond that, developers can run both Windows and Linux Docker instances on the same machine, thanks to WSL2 and Docker Desktop.
Understanding the different container models — and when each applies — is essential for DevOps teams building hybrid-cloud or Windows-native workloads. Despite the surface complexity, Microsoft’s strategy follows a clear logic once you separate desktop isolation concerns from server-side orchestration concerns.
The Two Broad Use Cases for Windows Containers
- Desktop application isolation: Windows 10 uses container-like process isolation to sandbox apps installed via
.appxor.msixpackages. This happens automatically and is managed by the OS installer — developers and operators don’t need to configure it manually. - Server and cloud workloads: Windows Server containers allow .NET applications, SQL Server, and other Windows-based services to be packaged, versioned, and deployed through standard DevOps CI/CD pipelines using Docker and Kubernetes tooling.
The desktop side is largely transparent to operators. The server side is where DevOps teams need to make deliberate architectural decisions.
Windows Containers vs. Linux Containers on Windows
Windows 10 Pro and Enterprise can run Docker containers in two flavors:
- Windows containers: Use the Windows kernel. Images are Windows-based and cannot run on a Linux host without emulation.
- Linux containers via WSL2: Docker Desktop for Windows uses the WSL2 backend to run a real Linux kernel on Windows, enabling Linux container images to run natively without a full Linux VM overhead.
Docker Desktop abstracts the complexity of switching between these modes, making Windows 10 a viable development platform for both Windows and Linux containerized workloads. For teams building microservices that will ultimately run on Linux nodes in production, the WSL2-backed Linux container workflow on Windows provides a high-fidelity local development environment.
Windows Containers in Hybrid Cloud and Kubernetes
Windows containers are officially supported in Kubernetes, enabling organizations to run mixed Windows/Linux clusters. Both upstream Kubernetes and Red Hat OpenShift support Windows worker nodes alongside Linux worker nodes, managed from a single control plane.
Key architectural points for Kubernetes-based Windows container deployments:
- Windows containers run on Windows Server worker nodes, not on Linux nodes. There is no cross-OS kernel sharing; Windows containers require a Windows host.
- Windows Server licensing requirements mean each VM instance hosting Windows containers requires a valid Windows licence — a cost consideration when sizing your cluster.
- Tools such as Azure Kubernetes Service (AKS) and OpenShift automate workload scheduling across Linux and Windows nodes, handling placement transparently.
- Container images can be stored in the Azure Container Registry and pulled to Windows nodes using standard Kubernetes manifests.
For teams migrating legacy .NET or COM-based applications to a cloud-native architecture, lifting the application into a Windows Docker container and deploying it via Kubernetes is a practical intermediate step — you get CI/CD pipeline integration and horizontal scaling without requiring a full application rewrite.
Choosing an Isolation Mode: Process vs. Hyper-V
Windows Server containers offer two isolation modes. Choosing the right one depends primarily on your trust boundary requirements and hosting environment.
Process Isolation
Similar to the default Linux container model, process isolation runs multiple container images on a shared Windows kernel. Namespace isolation keeps containers separate from each other and from the host, but the kernel is shared.
- Pros: Lower overhead, faster startup, better density.
- Cons: Shared kernel means a kernel-level vulnerability could affect all containers on the host. Not recommended for multi-tenant scenarios.
- Best for: Controlled single-tenant environments where you know and trust all workloads running on the host.
Hyper-V Isolation
Hyper-V isolation wraps each container in a thin, optimized virtual machine with its own kernel instance, running on top of Hyper-V. This provides hardware-level isolation between containers.
- Pros: Strong isolation boundary; suitable for multi-tenant workloads; prevents information leakage between containers.
- Cons: Slightly higher resource overhead compared to process isolation.
- Best for: Public cloud deployments, multi-tenant container hosting, or any environment where workloads from different trust domains share the same host.
To run a container with Hyper-V isolation using Docker, pass the --isolation flag:
docker run --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2019 cmdNote that the default isolation mode differs by platform: Windows 10 desktop defaults to Hyper-V isolation, while Windows Server defaults to process isolation. If you require Hyper-V isolation on a Windows Server host, you must specify it explicitly.
Container Base Image Sizes: A Practical Consideration
One historical criticism of Windows containers has been the size of the base images. Microsoft has been actively reducing image sizes across Windows Server releases. As of the Windows Server 2004 release (circa 2020), the Windows Server Core base image was reported to be approximately 2.46 GB, down from nearly 5 GB in the Windows Server 1809 and 1903 releases.
Building on Windows Server Core rather than Nano Server is generally recommended for containerized .NET applications because Server Core exposes a larger API surface area, reducing the risk of application compatibility issues when lifting existing code into containers.
Tooling and Observability for Windows Containers
Microsoft has invested in open-source tooling to support Windows container operations, including logging utilities hosted on GitHub. Robust logging is especially important in Kubernetes-orchestrated environments where a single application may span dozens of containers across multiple nodes. Teams should evaluate their observability stack — log aggregation, metrics, and distributed tracing — before going to production with Windows container workloads.
Decision Guide: Which Windows Container Approach Is Right for You?
| Scenario | Recommended Approach |
|---|---|
| Local development of Linux workloads on Windows | Docker Desktop with WSL2 backend, Linux containers |
| Local development of Windows workloads | Docker Desktop, Windows containers, process or Hyper-V isolation |
| Production Windows workloads on your own servers | Windows Server with process isolation; Hyper-V if multi-tenant |
| Production Windows workloads in Azure | AKS with Windows node pools; Hyper-V isolation recommended |
| Mixed Windows/Linux microservices | Kubernetes or OpenShift hybrid cluster with separate node pools |
Summary
Windows containers are no longer a niche concern. With Kubernetes support, WSL2-backed Linux containers on Windows, and shrinking base image sizes, the toolchain has matured to the point where DevOps teams can treat Windows workloads with the same CI/CD discipline they apply to Linux services. The key decisions are straightforward: choose process isolation for trusted single-tenant hosts, Hyper-V isolation for multi-tenant or public cloud scenarios, and use standard Kubernetes tooling to manage mixed clusters. Desktop isolation is handled automatically and requires no operator intervention.