Windows

Last reviewed Sep 13, 2026 · 765 words

Check for /dev/kvm on the host before you do anything else with dockur/windows. If it exists, you get a fully automated Windows 11 install in a Docker container in about 20 minutes with a browser viewer on port 8006, and it is one of the more delightful things in the self-hosting world. If it does not exist, the container falls back to software emulation and Windows takes hours to install and is unusable afterwards. Most "it doesn't work" reports about this project are hosts without KVM: cloud VMs without nested virtualisation, Docker Desktop on macOS, or an LXC container that was never given the device.

What it actually does

The image wraps QEMU. On first start it downloads the Windows ISO you asked for straight from Microsoft, answers the installer unattended, installs the VirtIO drivers, and boots to a desktop. You watch the whole thing through the built-in noVNC viewer, then switch to RDP on port 3389 once the desktop is up, because RDP is dramatically smoother than VNC for daily use. Free licence, 53,152 stars, and it stays that popular because the automation is genuinely reliable across Windows 11, 10, 8, 7, XP and several server editions.

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      RAM_SIZE: "4G"
      CPU_CORES: "2"
      DISK_SIZE: "64G"
    devices:
      - /dev/kvm
      - /dev/net/tun
    cap_add:
      - NET_ADMIN
    ports:
      - 8006:8006
      - 3389:3389/tcp
      - 3389:3389/udp
    volumes:
      - ./windows:/storage
      - ./shared:/data
    stop_grace_period: 2m

The ./shared mount appears inside Windows as a network share, which is the easiest way to move files in and out. stop_grace_period matters: without it, docker compose down pulls the plug on Windows mid-write and you get a disk check on next boot, or worse.

Give it 4 GB even though the listing says 512 MB

The 512 MB in the catalogue is the container's own overhead. Windows 11 inside it wants 4 GB to be pleasant and 2 cores to not feel like 2009, and the disk image grows toward the DISK_SIZE you set as Windows updates itself. A 64 GB image on a spinning disk will remind you why SSDs exist. Reserve the RAM on the host too; QEMU allocates it as the guest touches pages, so a host that looked fine at idle can hit swap once Windows Update runs.

Windows licensing does not go away because it's in Docker

The project downloads evaluation and retail ISOs; it does not include a licence key. Windows runs unactivated with the watermark and personalisation limits, which is fine for a build box or a once-a-month tax application. Anything you would need a licence for on bare metal, you need one for here. Enterprise evaluation editions expire after 90 days. Plan on buying a key if the VM becomes permanent.

Proxmox, LXC and the nesting question

If you already run Proxmox, a native VM is simpler and faster than Docker-in-VM-in-Proxmox, and the only reason to use this image is that you keep everything in Compose and like the zero-config install. Running it inside a Proxmox VM works when nested virtualisation is enabled on the outer VM's CPU settings. Running it in an LXC container works when you pass /dev/kvm and /dev/net/tun through in the container config, which Proxmox does not do by default. Either path is a 5-minute change once you know it is the problem.

Reaching it from outside: RDP over a tunnel, never exposed

Port 3389 on the public internet is the single most brute-forced port on earth. Keep it on your LAN and reach it over Tailscale from a laptop; Microsoft's own RDP clients on macOS and iOS work well. For a browser-only experience across a whole team, look at Kasm Workspaces or Guacamole in front of it; the other tools in the remote-access category solve the same problem with different trade-offs.

What I'd do

Use dockur/windows for exactly what it is good at: an occasional Windows desktop on a Linux box, spun up for the one vendor tool, the firmware updater, or the game launcher that has no Linux port. Confirm KVM first, give it 4 GB and 2 cores, use RDP over Tailscale, and set the grace period. If you find yourself running it 24/7 and doing real work in it, move that workload to a proper Proxmox VM with a licence and treat the container as the prototype it was.