dockur/windows: what a KVM-only Windows container gives you, and the two gaps you will hit

Docker Desktop is ruled out: the container needs /dev/kvm directly

The requirements are short and they exclude the host most people already have. It asks for Docker or Podman on a Linux host with KVM support, or Docker Desktop or Podman Desktop on Windows 11 with nested virtualization enabled, plus at least 2 GB of available RAM and 32 GB of free disk. A note then states that Docker Desktop on Linux, macOS, and Windows 10 does not currently provide KVM access to containers and is therefore not supported. On a Mac that closes off the obvious path entirely. The sample compose file asks for the device by name, with `/dev/kvm` listed in the devices block alongside `/dev/net/tun`, so a container without that node has no hardware acceleration path. The documented alternatives for a macOS user are a Linux host, a GitHub Codespace opened from the repository link, or one of the desktop front-ends that wrap this container.

The VERSION value picks the download, and the sizes run from 0.1 GB to 7.9 GB

Windows 11 Pro is the default, and a `VERSION` environment variable selects something else. The table of accepted values covers a wide range: Windows 11 LTSC at 4.7 GB, 11 Enterprise at 6.6 GB, Windows 10 Pro at 5.7 GB, Windows 8.1 Enterprise at 3.7 GB, then down to Windows XP Professional at 0.6 GB, Windows 2000 Professional at 0.4 GB, and ReactOS at 0.1 GB. Server editions live in the same table, from Windows Server 2025 at 7.6 GB down to Server 2003 at 0.6 GB, with Tiny11 Core and Tiny10 in between at 3.0 GB and 3.6 GB. Read the size column as a planning number, since the download happens on first start and the stated host minimum is 32 GB of free disk. The 64 GB figure people quote is a different thing: the default disk created for the guest.

Growing the disk stops at unallocated space until you extend the partition

`DISK_SIZE` is the capacity setting and takes values such as `256G`. Applied to an existing disk it works without data loss, which is the genuinely useful part of it. What it does not do is resize the guest partition, and the documentation is explicit about why: the added space appears as unallocated, so afterwards you have to extend the disk partition yourself following the linked Microsoft instructions. That is the gap between a virtual disk that got bigger and a C: drive that can use the extra room, and nothing in the container automates the second half. Nothing describes the reverse either, so treat the setting as one-way in practice. And size the disk where it persists: the sample maps `./windows:/storage`, so the container path is a host directory of your choosing.

RDP lands you at Docker / admin on a published port 3389

The credentials are fixed rather than configurable in what is documented here. The RDP instructions say to connect with any Microsoft Remote Desktop client to the IP of the container, using the username `Docker` and the password `admin`, and the sample compose file publishes 3389 on both TCP and UDP. That pairing deserves a second look before this runs on a shared machine, since the port is open to anything that can route to the host and the guest hands over a full interactive Windows session to anyone holding two fixed strings. The web viewer on 8006 is the opposite trade. It is meant for installation, because the automated setup runs there, and the documentation says it is less responsive than RDP and does not support features such as clipboard sharing. Audio arrives over RDP, or reaches the browser with `AUDIO: "Y"` plus the Audio option under Settings, Advanced.

NET_ADMIN and /dev/net/tun come with the macvlan and macvtap modes

The device and capability lines in the sample are not decorative. The feature list names NAT, user-mode, macvlan, and macvtap networking, and the last two are the reason the container is granted `NET_ADMIN` in `cap_add` and `/dev/net/tun` in `devices`, since those modes require creating interfaces. USB passthrough and host folder sharing sit in the same list, and folder sharing is the simplest of them: mount a host path at `/shared` and it shows up on the guest desktop as `Shared` and as drive `Z:`. Two other lines in the same file are worth reading as signals about how this thing behaves. `restart: always` brings the container back unattended, and `stop_grace_period: 2m`, which the CLI form spells `--stop-timeout 120`, gives Windows two minutes to shut down cleanly. Shorten that and you interrupt the guest mid-write.

The emulator binary comes from a latest tag while everything else is pinned

The Dockerfile pins its guest components with build arguments and the versions are exact: Blinter 1.0.112, wsdd-native 1.27, dxvk-native 3.0.2, virtio-win drivers 1.9.61, plus a udfread copy at 1.2.0 and a QEMU base image at 7.50 for everything except the emulator itself. That last case is the exception worth noticing. The qemu-system-x86_64 binary is copied in from a tag reading `latest`, so the component that actually executes your Windows guest is the one part of the build that can change without this repository recording a new version. The rest of the file is plumbing around it: cabextract and wimtools for archives, samba for the host share, mtools, gcab, xmlstarlet, and a pip install of Blinter. Day to day speed rests on that KVM device and the VirtIO drivers, not on the base image.

Nothing is baked in: the first start downloads and installs Windows

Nothing is baked in. The feature list calls it automatic download and hands-free installation, and the one command that starts it all is:

docker run -it --rm --name windows -e "VERSION=11" -p 8006:8006 --device=/dev/kvm --device=/dev/net/tun --cap-add NET_ADMIN -v "${PWD:-.}/windows:/storage" --stop-timeout 120 docker.io/dockurr/windows

That single line carries the whole contract at once: the image, the requested Windows version, the KVM and TUN devices, the added network capability, the storage bind mount, and a two minute stop timeout. On Kubernetes the equivalent is a single apply:

kubectl apply -f https://raw.githubusercontent.com/dockur/windows/refs/heads/master/kubernetes.yml

Then you open port 8006 in a browser, let the install run unattended, and wait for the desktop to appear, so the first boot is a long network operation rather than a boot. Guest resources have defaults worth knowing before you start: 2 CPU cores and 4 GB of RAM, adjustable with `CPU_CORES` and `RAM_SIZE` values such as `4` and `8G`, and dynamic memory allocation through memory ballooning, which is how the guest returns memory it is not using. Storage persists in the bind-mounted directory rather than the container layer, so removing the container does not take the Windows installation with it.

ARM64 is a separate repository, and the desktop is a separate project

Choosing the right VERSION value still leaves you looking at a browser tab. For a complete graphical desktop the documentation points to WinBoat, WinPodX, and WinApps, and states that each of them uses this container as its backend. That split defines who owns which setting: the front-end owns the window, while this container owns the Windows version, the disk size, the CPU and memory allocation, and the RDP credentials. ARM64 is handled the same way, by pointing somewhere else. A tip in the documentation says to install ARM64 versions of Windows using dockur/windows-arm, and the Dockerfile mirrors that split with a separate build stage that starts from a windows-arm image. So this x86 image does not cover Apple silicon or other ARM hosts, which is worth checking before a first boot rather than after it.

Editorial conclusion

dockur/windows fits anyone with a Linux host that hands the container /dev/kvm and a real need for a disposable Windows desktop, whether for legacy software, testing, or automation. It does not fit a Mac user on Docker Desktop, and anyone putting it on a shared network has to deal with the fixed Docker / admin RDP credentials first. Verify the host exposes KVM, plan the partition extension after any DISK_SIZE change, and remember the emulator binary itself is pulled from a floating tag.

Frequently asked questions

Official sources

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