Windows in Docker: Automated full Windows installation and runtime inside a container
Packages a full Windows installation inside a Docker container with KVM acceleration and a web UI for development, testing and temporary desktop use on KVM-capable Linux hosts; users remain responsible for licensing and host resource constraints.
GitHub dockur/windows Updated 2025-08-31 Branch master Stars 44.0K Forks 3.2K
Shell Dockerfile Containerized virtualization Automated installation

💡 Deep Analysis

3
How are disk persistence and expansion implemented? Is data safe across container rebuilds/upgrades?

Core Analysis

Question core: How does the project implement disk persistence and expansion? Is data safe across container rebuilds/upgrades?

Technical analysis

  • Persistence: Mounting ./windows:/storage stores QEMU/virtual disk files on the host filesystem, decoupling data from container lifecycle.
  • Expansion: README supports the DISK_SIZE env var to grow the default disk (e.g., 64GB -> 256G) and claims online expansion without data loss. Typical expansion is a two-step process: enlarge the virtual disk file, then expand the partition inside Windows.
  • Dependencies and risks: Data safety depends on host volume reliability and permissions. Mount permission issues, filesystem problems, interrupted expansions, or failure to grow the in-guest partition can cause availability issues.

Practical recommendations

  1. Always use a host-mounted volume or persistent PV (Kubernetes) for /storage rather than storing disk files inside the container.
  2. Backup important disk files regularly (copy the storage folder or use snapshots) to recover from host failures or mistakes.
  3. Expansion steps: Increase DISK_SIZE, verify the disk image grew on the host, then expand partitions inside Windows using Disk Management.
  4. Permissions and security: Ensure host directory permissions and SELinux/AppArmor policies allow container access.

Caveats

Warning: Expansion does not automatically resize Windows partitions—failures or host disk faults can make data unavailable. Always take backups before resizing.

Summary: Using host volumes and following explicit expansion and backup steps keeps data safe across rebuilds/upgrades; main risks lie in host storage reliability and operator error.

88.0%
How should I configure performance and resource allocation to achieve near-native experience, and what are the limitations?

Core Analysis

Question core: How to configure for near-native performance and what are the projects limits?

Technical analysis

  • /dev/kvm is essential: README highlights KVM acceleration; you must map /dev/kvm at runtime. Host must have virtualization extensions (VT-x/AMD-V) enabled.
  • CPU/memory allocation: Use CPU_CORES and RAM_SIZE env vars to allocate resources; avoid host overcommit to prevent jitter.
  • Disk and I/O: Mount ./windows on a performant filesystem or block device and set DISK_SIZE; ensure host IOPS/throughput meets needs.

Practical recommendations

  1. Run on a Linux physical host and confirm lsmod | grep kvm and /dev/kvm accessibility.
  2. Allocate at least 2 CPU cores and >=4GB RAM for lightweight Windows guests; increase per version/workload.
  3. Place /storage on local SSD or a high-performance PV in Kubernetes and monitor IO.
  4. For GPU/graphics needs, use traditional VMs with GPU passthrough—this repo doesnt advertise GPU support.

Caveats

Warning: Nested virtualization might be disabled on many cloud VM types; lacking /dev/kvm will severely degrade performance or prevent startup.

Summary: Enabling KVM, assigning sufficient CPU/memory, and optimizing disk IO will yield near-native CPU/memory performance for most dev/test workloads, but GPU workloads and constrained hosts remain limiting factors.

87.0%
What security and licensing considerations should I be aware of, and what protections does the project itself provide?

Core Analysis

Core question: What security and licensing issues should you watch for, and what protections does the project provide?

Technical analysis

  • Ports and default credentials: Examples map the web viewer (8006) and RDP (3389) to the host; README warns about default credential risks—exposed services can be accessed if not protected.
  • Licensing: Auto-downloaded ISOs do not handle Microsoft licensing/activation; users must ensure legal compliance.
  • Security hooks available: The project supports injecting OEM scripts and bind mounts to change passwords, install patches, configure firewall, and enforce policies during installation.

Practical recommendations

  1. Change defaults immediately: Replace default usernames/passwords and enforce strong password policies inside Windows.
  2. Restrict network exposure: Do not expose 3389/8006 to the public internet—use firewalls, SSH tunnels, or VPNs.
  3. Handle licensing: Prepare valid Windows licenses and activation methods; inject license files or activation scripts via bind mounts or OEM scripts.
  4. Automate hardening: Use OEM scripts to apply security patches, disable unnecessary services, and enable auditing.

Caveats

Important: The project does not handle licensing or legal compliance; leaving ports open or default credentials unchanged creates serious security risks.

Summary: While the repo provides hooks for secure configuration during installation, you must proactively change credentials, limit access, and ensure license compliance before any production exposure.

86.0%

✨ Highlights

  • Automated installation and run of a full Windows system inside a container
  • Supports KVM acceleration, web-based viewer and persistent storage
  • Windows image and licensing compliance are the user's responsibility

🔧 Engineering

  • Automates downloading and installing multiple Windows versions with a web UI and persistent storage
  • Flexible deployment: supports Docker Compose, Docker CLI, Kubernetes and GitHub Codespaces

⚠️ Risks

  • Depends on /dev/kvm and host kernel features; requires appropriate hardware and kernel support
  • Exposed network ports and privileged device access can introduce security and compliance risks

👥 For who?

  • Developers and testers who need to validate Windows features on Linux hosts
  • Operations and QA teams needing temporary desktops, legacy environment reproduction, or cross-platform demos