dockur/windows: Windows-Installation in einem Docker-Container automatisiert
Windows in einem Docker-Container. Windows [![Build]][build_url] [![Version]][tag_url] [![Size]][tag_url] [![Package]][pkg_url] [![Pulls]][hub_url] Windows in einem Docker-Container.
Auf einen Blick
- Was ist das?
- dockur/windows lädt Windows-Abbilder selbstständig herunter, installiert sie ohne Zutun in einem Container und stellt das Ergebnis über einen Webviewer auf Port 8006 sowie RDP auf Port 3389 bereit. Der Text ordnet Installation, Versionswahl, Ressourcensteuerung und die harten Anforderungen an den Host ein.
- Für wen ist es gedacht?
- dockur/windows passt für Linux-Hosts mit KVM, auf denen eine isolierte Windows-Umgebung für Tests, Legacy-Anwendungen oder Entwicklung gebraucht wird und die Installation möglichst ohne manuelle Schritte ablaufen soll. Ungeeignet ist es ohne /dev/kvm, etwa in VMs auf macOS oder unter Docker Desktop auf Windows 10, weil die Leistung dann nicht den Angaben im README entspricht.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Shell, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was dockur/windows tatsächlich liefert
Das Repository dockur/windows beschreibt sich mit einem kurzen Satz: Windows inside a Docker container. Dahinter steht ein Shell-basiertes Setup, das zwei langwierige Aufgaben aus dem klassischen VM-Workflow entfernt. Erstens lädt der Container das gewünschte Windows-Abbild selbstständig herunter, zweitens läuft die Installation ohne Interaktion durch, bis der Desktop erscheint. Wer schon einmal ein Windows in QEMU von Hand aufgesetzt hat, weiß, wie viel Zeit genau in diesen beiden Schritten steckt.
Unter der Haube arbeitet das Projekt mit KVM-Beschleunigung, was laut README eine Leistung nahe an der eines nativen Systems ermöglicht. Das Image dockurr/windows ist MIT-lizenziert, hat über 53.000 Sterne und wurde am 21. August 2026 mit Release v6.05 aktualisiert. Die Monatsabstände zwischen v6.03, v6.04 und v6.05 zeigen eine gleichmäßige Pflege, ohne dass das README konkrete Roadmaps verspricht.
Erster Start über Port 8006 und RDP auf Port 3389
Der Einstieg ist im README in drei Schritten beschrieben: Container starten, im Browser http://127.0.0.1:8006/ öffnen und warten, bis die automatische Installation durchgelaufen ist. Der Webviewer ist laut README vor allem für die Installation gedacht, weil er weniger reaktionsschnell ist und keine Funktionen wie eine gemeinsame Zwischenablage bietet.
Für den regelmäßigen Gebrauch empfiehlt das Projekt den Weg über RDP: Ein beliebiger Microsoft Remote Desktop Client verbindet sich mit der Container-IP auf Port 3389, der Benutzername ist Docker, das Passwort admin. Beide Ports legt das Compose-Beispiel von Anfang an frei, sodass kein zweiter Anlauf nötig ist. Wer das Passwort nicht ändert, betreibt eine Windows-Maschine mit bekannten Zugangsdaten im Netz; das README schweigt an dieser Stelle zu Härtung und Zugriffsschutz.
VERSION, DISK_SIZE und die Abbildtabelle von Windows 11 bis ReactOS
Standardmäßig installiert der Container Windows 11 Pro. Über die Umgebungsvariable VERSION wählt man eine andere Variante: 10 für Windows 10 Pro, 2022 für Windows Server 2022, 11l für Windows 11 LTSC oder xp für Windows XP Professional. Die Tabelle im README listet auch 98, 95 und 2000 sowie die schlanken Varianten Tiny11 und Tiny10 und sogar ReactOS mit einer Abbildgröße von 0,1 GB. Die Größenangaben reichen von 0,4 GB bis 7,9 GB, was für die Planung des Speicherplatzes direkt verwertbar ist.
Der Standardspeicherplatz liegt bei 64 GB und lässt sich über DISK_SIZE anpassen, etwa mit DISK_SIZE: "256G". Der Hinweis im README ist hier wichtig: Eine nachträgliche Vergrößerung ohne Datenverlust ist möglich, aber der zusätzliche Platz erscheint als nicht zugewiesen, und die Partition muss danach manuell erweitert werden. Für ARM64-Versionen von Windows verweist das README auf das Schwesterprojekt dockur/windows-arm.
Ressourcen, Dateiaustausch und Netzwerkmodi im Container
Ohne weitere Konfiguration bekommt Windows 2 CPU-Kerne und 4 GB RAM zugewiesen. Wer mehr braucht, setzt RAM_SIZE und CPU_CORES in der Compose-Datei, etwa auf 8G und 4 Kerne. Das README nennt außerdem dynamische Speicherverwaltung mit Memory Ballooning, USB-Durchreichung und die Netzwerkmodi NAT, user-mode, macvlan und macvtap. Damit sind sowohl einfache NAT-Setups als auch Szenarien abgedeckt, in denen die Windows-Maschine eine eigene Adresse im lokalen Netz braucht.
Für den Dateiaustausch mit dem Host dient ein Bind-Mount wie ./example:/shared. Nach der Installation erscheint auf dem Windows-Desktop ein Ordner namens Shared, der zusätzlich als Laufwerk Z: eingebunden ist. Audio ist standardmäßig ausgeschaltet und wird nur bei RDP-Nutzung oder mit der Umgebungsvariable AUDIO: "Y" an den Browser gestreamt; der Stream ist laut README nur aktiv, solange die Option im Webviewer eingeschaltet bleibt.
Host-Anforderungen: /dev/kvm, /dev/net/tun und die Docker-Desktop-Falle
Die Voraussetzungen sind knapp gefasst, aber bindend: Docker oder Podman auf einem Linux-Host mit KVM-Unterstützung, mindestens 2 GB freier Arbeitsspeicher und mindestens 32 GB freier Festplattenplatz. Das Compose-Beispiel hängt die Geräte /dev/kvm und /dev/net/tun an den Container durch und vergibt die Capability NET_ADMIN, genau weil die Virtualisierung auf diese Wege läuft.
Eine Klammer im README verdient Aufmerksamkeit: Docker Desktop unter Linux, macOS und Windows 10 stellt Containern derzeit keinen KVM-Zugang bereit und wird deshalb nicht unterstützt. Unter Windows 11 geht es mit Docker Desktop oder Podman Desktop, sofern verschachtelte Virtualisierung aktiviert ist. Wer die Umgebung nur auf dem Papier prüft und später Leistungseinbuhen erlebt, findet dafür die Ursache meist genau hier.
Betrieb über Compose, Kubernetes und als Backend für WinBoat
Neben dem Docker-CLI-Einzeiler zeigt das README eine vollständige Compose-Definition mit restart: always und stop_grace_period: 2m, damit die virtuelle Maschine beim Herunterfahren Zeit bekommt, sauber abzuschließen. Für Kubernetes-Setups gibt es eine Manifest-Datei, die per kubectl apply direkt aus dem Repository geladen werden kann.
Interessant ist der Verweis auf drei Desktop-Projekte: WinBoat, WinPodX und WinApps nutzen diesen Container als Backend und bauen eine vollständige grafische Desktop-Erfahrung darüber. Das zeigt, wo die Grenze des Projekts selbst liegt: dockur/windows liefert die automatisierte Windows-VM im Container, die Bedienoberfläche überlässt es bei Bedarf spezialisierten Werkzeugen. Über Lizenzfragen des Windows-Betriebssystems selbst sagt das README nichts aus; diese bleiben Sache der eigenen Windows-Lizenz.
Redaktionelles Fazit
dockur/windows passt für Linux-Hosts mit KVM, auf denen eine isolierte Windows-Umgebung für Tests, Legacy-Anwendungen oder Entwicklung gebraucht wird und die Installation möglichst ohne manuelle Schritte ablaufen soll. Ungeeignet ist es ohne /dev/kvm, etwa in VMs auf macOS oder unter Docker Desktop auf Windows 10, weil die Leistung dann nicht den Angaben im README entspricht. Vor dem Ernstbetrieb lohnt ein Blick in die Versionstabelle mit den Werten VERSION, DISK_SIZE und RAM_SIZE, um Abbildgröße und Speicherort über das Volume ./windows:/storage von vornherein festzulegen.
Community-Notizen