Seit dem 29. September 2026 sind WSL Containers allgemein verfügbar. Microsoft liefert damit eine eigene Laufzeit für Linux-Container als Teil des Windows Subsystem for Linux aus. Wer WSL installiert hat, bekommt sie mit einem wsl --update und findet danach ein neues Werkzeug namens wslc.exe auf dem Rechner. Docker Desktop, Podman oder Rancher braucht es dafür nicht mehr.
Microsoft spricht in seiner Ankündigung im Windows Developer Blog vor allem Entwickler an. Mich interessiert die andere Seite: Was bedeutet das für jemanden, der ein Windows-Netz betreibt, und was für Menschen, die mit Containern bisher nichts zu tun hatten?
Dieser Artikel erklärt zuerst, was Linux-Container überhaupt sind, dann die Technik hinter WSLc, und zum Schluss, was Admins jetzt regeln sollten. Wer Container kennt, kann den nächsten Abschnitt überspringen.
Was Linux-Container sind und wofür man sie nutzt
Ein Container ist ein Prozess, der vom Rest des Systems abgeschottet läuft. Er sieht ein eigenes Dateisystem, eigene Netzwerkschnittstellen und nur seine eigenen Prozesse. Anders als eine virtuelle Maschine bringt er aber keinen eigenen Betriebssystemkern mit, sondern teilt sich den Kernel mit dem Host. Deshalb startet ein Container in Sekunden und braucht einen Bruchteil des Speichers einer VM.
Die Vorlage für einen Container heißt Image. Darin steckt die Anwendung samt allen Bibliotheken, die sie braucht. Images liegen in Registries, die bekannteste ist Docker Hub. Wer nginx oder postgres starten will, lädt das Image und hat eine Minute später einen laufenden Dienst, ohne etwas auf dem eigenen System zu installieren. Löscht man den Container, ist alles wieder weg.
Genutzt wird das überall dort, wo Software reproduzierbar laufen soll. Entwickler bauen damit identische Umgebungen auf jedem Rechner. Betreiber packen Serverdienste wie Nextcloud, Paperless-ngx oder Datenbanken in Container, weil Updates und Rückbau einfacher werden. Dazu kommen Testumgebungen, Build-Pipelines und inzwischen auch lokale KI-Modelle.
Der Haken unter Windows: Linux-Container brauchen einen Linux-Kernel. Den gibt es dort nur in einer virtuellen Maschine, und genau diese VM stellt WSL 2 bereit. Bisher musste man darin selbst eine Container-Engine einrichten oder Docker Desktop installieren. WSLc macht die Engine zum Bestandteil von WSL.
Was wslc.exe kann
WSL Containers besteht aus zwei Teilen. Der erste ist die Kommandozeile wslc.exe, die sich auch über den Alias container.exe aufrufen lässt. Die Befehle sind an Docker angelehnt. Das Beispiel aus der Dokumentation von Microsoft startet einen Webserver und räumt danach wieder auf:
wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080
wslc container ps
wslc container stop webDer zweite Teil ist eine API. Windows-Anwendungen können darüber Images laden, Container starten und mit den Prozessen darin sprechen, inklusive Dateifreigaben, Netzwerk und GPU-Zugriff. Sie kommt als NuGet-Paket Microsoft.WSL.Containers für C# und C++. Die C++/WinRT-Variante ist laut Dokumentation noch als Vorschau markiert und kann sich ändern.
Angekündigt wurde das Ganze auf der Build im Juni, die öffentliche Vorschau folgte am 29. Juni mit WSL 2.9.3. Die fertige Fassung steckt in WSL 3.0.1 auf GitHub. Gegenüber der Vorschau sind unter anderem dazugekommen: wslc container restart, wslc container cp zum Kopieren von Dateien, wslc system info, Health Checks, Echtzeit-Ereignisse, --mount, das Verbinden und Trennen von Netzwerken und ein frei wählbarer Speicherort für die Container-Daten.
WSLc-Architektur: Sessions, virtiofs und Consommé
WSLc ist kein Docker, das in eine bestehende WSL-Distribution gesteckt wurde. Die Container laufen in einer eigenen VM, getrennt von Ubuntu oder Debian, die Sie vielleicht schon unter WSL nutzen. Wie das aufgebaut ist, beschreibt Pierre Boulay aus dem WSL-Team im Architecture Deep Dive.
Sitzungsmodell
Wie bei WSL nimmt der privilegierte Dienst wslservice.exe die Anfragen entgegen und erzeugt die virtuelle Maschine. Er behält sie aber nicht. Stattdessen startet er einen Kindprozess wslcsession.exe, der im Kontext des aufrufenden Benutzers läuft und alles Weitere erledigt: Container anlegen, Verzeichnisse einhängen, Ports binden.
Das hat zwei Folgen. Sitzungen verschiedener Benutzer stecken in getrennten Prozessen. Und die eigentliche Arbeit geschieht mit weniger Rechten, als der Dienst selbst hat. Aus Sicherheitssicht ist das die richtige Richtung, denn ein Fehler in der Container-Verwaltung trifft dann nicht sofort einen SYSTEM-Prozess.
Speicher
Jede Sitzung hat eine eigene virtuelle Festplatte, in der Images, Container, Netzwerke und Volumes liegen. Microsoft nennt als Ablageort %AppData%\Local\wslc\sessions. Dort wächst also eine VHD im Benutzerprofil, und Container-Images sind selten klein.
Windows-Ordner lassen sich mit -v in einen Container einhängen. Technisch wird der Pfad über virtiofs in die VM gereicht und dort als Bind-Mount an den Container gehängt. virtiofs ist ein Dateisystem, das für den Austausch zwischen Hypervisor und VM gebaut wurde. Microsoft gibt an, es sei etwa doppelt so schnell wie das bisher in WSL verwendete Plan 9. Messwerte, Hardware oder Testaufbau nennt der Beitrag nicht, die Zahl ist also eine Herstellerangabe.
Wer ein echtes Linux-Dateisystem oder eine Größenbegrenzung braucht, legt ein VHD-Volume an:
wslc volume create --driver vhd -o SizeBytes=200000000 my-volumeNetzwerk
Für das Netzwerk hat Microsoft einen neuen Modus gebaut und ihn Consommé getauft. Die VM schickt ihren gesamten Verkehr als Ethernet-Frames in eine virtio-Queue. Auf der Windows-Seite liest ein Prozess diese Frames, der wiederum im Kontext des Benutzers läuft. Er beantwortet DNS-Anfragen, leitet TCP und UDP weiter und kümmert sich um Portfreigaben.
Der Verkehr aus dem Container sieht für Windows damit aus wie der eines gewöhnlichen Benutzerprozesses. Microsoft nennt das als Vorteil, weil VPN-Clients und Firewalls damit umgehen können. Wer WSL 2 schon einmal hinter einem Proxy oder mit Always On VPN betrieben hat, weiß, warum das kein Detail ist.
WSLc oder Docker Desktop: was noch fehlt
Docker Desktop ersetzt WSLc heute nicht vollständig. Die größte Lücke ist Docker Compose, also das Starten mehrerer zusammengehöriger Container aus einer compose.yaml. Microsoft arbeitet nach eigener Aussage an einem Befehl wsl compose up, der vorhandene Dateien unverändert verarbeiten soll. Einen Termin gibt es nicht.
Die zweite Lücke ist die Docker-Engine-API. Viele Werkzeuge, etwa Testcontainers oder buildx, sprechen direkt mit dem Docker-Socket. Eine kompatible Schnittstelle, erreichbar über DOCKER_HOST, ist bisher nur ein offener Feature-Wunsch auf GitHub, den Microsoft nicht zugesagt hat. Ähnliche Befehlsnamen bedeuten eben noch keine Kompatibilität.
Fairerweise: Docker Desktop, Podman Desktop und Rancher Desktop setzen selbst auf WSL auf und profitieren von den Verbesserungen an Dateizugriff und Netzwerk. Und für einzelne Container, Image-Builds aus einem Dockerfile und VS Code Dev Containers reicht WSLc schon jetzt. Die Dev-Containers-Erweiterung, Aspire und die Container-Erweiterung für VS Code unterstützen es bereits.
Für Behörden gibt es einen weiteren Punkt, und der ist rechtlicher Natur. Docker Desktop ist laut Lizenzbedingungen von Docker nur für kleine Unternehmen, Privatnutzung, Bildung und nichtkommerzielle Open-Source-Projekte kostenlos. Staatliche Stellen brauchen ausdrücklich ein bezahltes Abonnement, unabhängig von ihrer Größe. WSLc ist Open Source und Teil von WSL. Für eine Kommune, in der zwei Leute gelegentlich einen Container starten, entfällt damit eine Lizenzfrage, die viele vermutlich nie gestellt haben.
Was Admins jetzt regeln sollten
Aus Betreibersicht ist WSLc zuerst eine neue Möglichkeit, fremden Code auf einem Windows-Client auszuführen. Ein wslc run lädt ein Image aus einer öffentlichen Registry und startet es. Was in diesem Image steckt, hat niemand in Ihrer Organisation geprüft.
Betroffen sind nur Rechner, auf denen WSL bereits eingerichtet ist. Ein Standardbenutzer kann WSL nicht selbst aktivieren. Auf Admin-Arbeitsplätzen und bei Entwicklern ist es aber oft vorhanden, und dort kommt die Container-Laufzeit mit dem nächsten WSL-Update einfach mit.
Microsoft liefert zwei Richtlinien dazu. „Allow WSL containers access“ schaltet die Funktion komplett ab oder frei. Die „WSL containers registry allow list“ beschränkt das Laden von Images auf freigegebene Registries. Die Ankündigung nennt dafür Intune. Wer wie die meisten Kommunen ein klassisches Active Directory ohne Intune betreibt, ist trotzdem nicht außen vor: Die Einstellungen sind als Gruppenrichtlinie in der ADMX-Vorlage von WSL enthalten, wie der zugehörige Pull Request zeigt. Wie man die Vorlage einbindet, steht in der Enterprise-Dokumentation zu WSL.
Ein Blick in diesen Pull Request lohnt sich. Demnach gilt eine leere Allow List als „keine Einschränkung“, und bei aktiver Liste wird auch das lokale Bauen von Images blockiert. Ob das in 3.0.1 noch genauso ist, habe ich nicht nachgeprüft. Testen Sie die Richtlinie deshalb, bevor Sie sich darauf verlassen.
Der dritte Baustein ist Defender for Endpoint. Das vorhandene WSL-Plug-in erfasst nun auch Prozess-, Datei- und Netzwerkaktivität in den Containern und ordnet sie dem Windows-Gerät zu. Nach einem Bericht von XenoSpectrum ist diese Unterstützung noch als Public Preview gekennzeichnet. Sichtbarkeit ist außerdem kein Schutz: Sie sehen hinterher, was passiert ist.
Das Netzwerkmodell hat für Betreiber übrigens eine Kehrseite. Wenn Container-Verkehr wie der eines normalen Benutzerprozesses aussieht, greifen Proxy und Firewall zwar wie gewohnt, aber am Perimeter lässt sich nicht mehr erkennen, ob eine Verbindung aus dem Browser kam oder aus einem Container. Das ist meine Lesart der Architektur, keine Aussage von Microsoft.
Und der Nutzen? Den gibt es auch für Admins. Werkzeuge wie testssl.sh, nmap oder Ansible lassen sich in einem Container starten, ohne eine Linux-VM zu pflegen. Eine Fachanwendung, die der Hersteller als Container ausliefert, kann man auf dem eigenen Rechner ausprobieren, bevor ein Server dafür aufgesetzt wird. Für den Dauerbetrieb von Diensten ist ein Arbeitsplatzrechner mit WSLc aber der falsche Ort. Die Container laufen in einer Benutzersitzung, und die endet mit der Abmeldung.
Was normale Benutzer davon haben
Direkt erst einmal nichts. Wer keine Kommandozeile öffnet, wird wslc.exe nie sehen, und das ist in Ordnung.
Indirekt kann sich das ändern, und zwar über die API. Eine Windows-Anwendung kann künftig einen Linux-Bestandteil mitbringen und ihn im Hintergrund in einem Container starten, ohne dass der Benutzer etwas installieren muss. Microsoft nennt lokale KI-Anwendungen als Beispiel. Viele dieser Werkzeuge gibt es nur für Linux, und bisher scheiterte der Einsatz unter Windows an der Einrichtung.
Für technisch Interessierte zu Hause ist WSLc der bequemste Einstieg in das Thema. Wer schon immer wissen wollte, was es mit Containern auf sich hat, braucht jetzt zwei Befehle und keine zusätzliche Software.
Erste Schritte mit wslc
Voraussetzung ist ein Rechner mit installiertem WSL 2. Dann genügt:
wsl --update
wsl --version
wslc versionDie WSL-Version sollte 3.0.1 oder höher anzeigen. Steht dort noch 2.7.x, ist das Update bei Ihnen nicht angekommen. Teile der Microsoft-Dokumentation verweisen noch auf wsl --update --pre-release, das stammt aus der Vorschauphase und ist nicht mehr nötig.
Der erste Test:
wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"Ein Windows-Ordner kommt mit -v in den Container:
wslc container run -v C:\Windows\System32\drivers\etc:/volume -it debian:latest ls /volumeFazit
WSLc macht Linux-Container zu einer Windows-Funktion, die mit einem Update kommt, nichts kostet und sich über die gewohnten Richtlinien steuern lässt. Technisch ist es sauber gebaut: getrennte Sitzungen, weniger Rechte, ein Netzwerkmodell, das mit VPN und Firewall zusammenarbeitet. Für Projekte mit Compose-Dateien ist es noch zu früh, und wer Werkzeuge mit Docker-Socket nutzt, bleibt vorerst bei Docker.
Für Admins steht die Entscheidung vor der Begeisterung. Prüfen Sie, auf welchen Rechnern in Ihrem Netz WSL installiert ist, laden Sie die aktuelle ADMX-Vorlage und legen Sie fest, ob WSL Containers erlaubt sind und aus welchen Registries Images kommen dürfen. Das ist eine Stunde Arbeit. Danach können Sie es in Ruhe ausprobieren.