dockur/windows: A Docker Container That Runs Windows, With KVM as the Real Requirement

What This Container Actually Solves

dockur/windows solves a narrow but real problem: getting a Windows desktop or server running on a Linux host without a separate VM manager. The README positions it as "Windows inside a Docker container," with automatic download and hands-free installation. The target user is someone who already standardizes on Docker or Podman and wants Windows as just another workload. The container downloads the chosen Windows ISO, boots it, performs the installation unattended, and leaves you with a running Windows instance. That removes the manual steps of creating a VM, mounting an ISO, and clicking through the Windows setup wizard. The intended audience is not the general desktop user. It is the engineer or homelab operator who wants Windows in a containerized workflow, with config files checked into version control and reproducible startup.

The Mechanism: KVM, QEMU, and a Web Viewer

The container does not virtualize Windows by itself. It relies on the host kernel's KVM module, which is why the requirements section insists on Linux with KVM support. The compose example passes /dev/kvm and /dev/net/tun into the container, along with NET_ADMIN capability. That device access is what allows the container to run a hardware-accelerated virtual machine. The README claims "near-native performance with KVM acceleration," which is plausible only because KVM provides hardware virtualization. The container exposes port 8006, which serves a web viewer. The viewer is described as "mainly intended for use during installation," because it is less responsive than RDP and lacks clipboard sharing. Once Windows is installed, the recommended path is to connect via Microsoft Remote Desktop to the container's IP with username Docker and password admin. So the data flow is: Docker starts a container, the container runs a QEMU-like VM backed by KVM, the VM boots Windows, and the user interacts through the web viewer or RDP.

Getting It Running: Compose, CLI, and Kubernetes

The README provides three ways to start the container. Docker Compose is the most complete example. The minimal service block sets image dockurr/windows, environment VERSION: "11", devices /dev/kvm and /dev/net/tun, cap_add NET_ADMIN, ports 8006 and 3389, and a volume ./windows:/storage. The Docker CLI equivalent is a single docker run command with the same flags, plus --stop-timeout 120. There is also a Kubernetes manifest at kubernetes.yml in the repository, applied with kubectl apply -f. The default Windows version is 11 Pro, but VERSION accepts values from 11 down to 95, including Server editions and tiny builds. The storage volume is mandatory in practice, because the disk image lives under /storage. The DISK_SIZE variable defaults to 64 GB and can be set to something like "256G". The README notes that increasing DISK_SIZE after the fact works, but you must manually extend the partition inside Windows because the new space appears as unallocated.

Configuration Surface: RAM, CPU, Audio, and Sharing

Beyond VERSION and DISK_SIZE, the container exposes a few environment variables that control the guest hardware. RAM_SIZE and CPU_CORES set the VM's memory and processor count, with defaults of 4 GB and 2 cores. AUDIO toggles audio streaming to the web viewer, but it is disabled by default unless you use RDP. The README says that when AUDIO is set to Y, you must also enable Audio under Settings -> Advanced in the web viewer, and the stream is only active while that option is on. Host folder sharing is handled by a second bind mount: mounting a host directory at /shared makes it appear as a folder named Shared on the Windows desktop and as drive Z:. That is a simple and useful feature, but it is also a reminder that file sharing is explicit and separate from the /storage volume. The storage volume holds the disk image, while /shared is the exchange directory. This separation is good, but it adds a second mount to remember.

The Hard Limitation: KVM Availability

The most important constraint is also the one that disqualifies many potential users. The README states clearly: "Docker Desktop on Linux, macOS, and Windows 10 does not currently provide KVM access to containers and is therefore not supported." That sentence is the whole story. If you are on macOS, you cannot use this container with Docker Desktop. If you are on Windows 10, same. Even on Windows 11, you need Docker Desktop with nested virtualization enabled, which is a BIOS-level setting and not always available. On Linux, the host must have KVM compiled into the kernel and /dev/kvm must be present. Without KVM, the container either fails to start or runs without acceleration, which for Windows would be painfully slow. The minimum requirements are 2 GB of RAM and 32 GB of disk space, but those are floors, not comfortable working numbers. A Windows 11 VM with 4 GB RAM and a 64 GB disk will feel cramped for anything beyond basic use.

Where This Is the Wrong Tool

dockur/windows is the wrong choice if you need a Windows environment that must survive host kernel upgrades or Docker daemon restarts with zero intervention. The container is ephemeral by design; the disk lives in the /storage volume, but the VM lifecycle is tied to the container. If you remove the container with docker rm, you must recreate it and hope the disk image is intact. It is also the wrong tool if you need GPU passthrough for gaming or machine learning, because the README does not mention any GPU support. For audio, the web viewer stream is a workaround, but RDP is the recommended path, which implies that the browser experience is not the primary interface. If you need a lightweight Windows instance for a single test, a plain QEMU command with KVM might be simpler, because you skip the Docker layer entirely. And if you need macOS or Windows 10 support, this container is simply not an option.

A Real Alternative: QEMU Directly or a Full Hypervisor

The obvious alternative is to run QEMU directly on the host, without Docker. The difference in approach is that dockur/windows wraps QEMU inside a container, adding a management layer for automatic ISO download and unattended installation. With bare QEMU, you control the VM through command-line flags and a VNC or Spice display. You lose the convenience of a web viewer and the declarative compose file, but you gain direct access to the host's KVM without needing to pass devices through container boundaries. On a Linux host, you can run qemu-system-x86_64 with -enable-kvm and a Windows ISO, and you get the same near-native performance. The trade-off is that you must handle the Windows installation manually, including answering setup questions and installing drivers. Another alternative is a full hypervisor like Proxmox VE or libvirt, which gives you snapshotting, live migration, and a management API. Those tools are heavier than a single container but are more appropriate for production Windows workloads that need uptime and backup integration.

Maintenance and License Considerations

The repository is active, with releases v6.05, v6.04, and v6.03 pushed in August and July 2026. The project is licensed under MIT, which means you can use, modify, and redistribute the container code with minimal restrictions. The Windows images themselves are not covered by MIT; they are Microsoft products with their own licensing terms. The README does not discuss activation or licensing, so you must verify that your use of Windows in a container complies with Microsoft's licensing. From a maintenance perspective, the container is a Shell script project, so upgrades are likely to be straightforward: pull the new image and recreate the container. The risk is that the project depends on external Windows ISO sources and on KVM behavior across kernel versions. If Microsoft changes download URLs or the container's unattended installation logic breaks for a new Windows update, you will need to wait for a new release. The active release cadence suggests the maintainers are responsive, but the project's longevity is not guaranteed by the MIT license alone.

Editorial conclusion

Adopt dockur/windows if you run Linux with KVM and need a disposable or isolated Windows instance without a separate hypervisor. Avoid it if your host cannot expose /dev/kvm, which includes Docker Desktop on macOS, Windows 10, and Linux. Before adoption, verify that your kernel has KVM enabled, that you can pass /dev/kvm and /dev/net/tun to containers, and that you accept the disk space and RAM minimums. Then test the container with VERSION=11 and a 64 GB disk before committing to a production workflow.

Official sources

1. Official README
2. Project repository
3. Release notes