WSLC allgemein verfügbar: Linux-Container direkt unter Windows mit wslc.exe

Microsoft hat am 29. September 2026 WSL containers, kurz WSLC, allgemein verfügbar gemacht. Damit lassen sich Linux-Container direkt unter Windows mit dem mitgelieferten Befehl wslc.exe bauen und starten, ohne eine separate Container-Engine zu installieren. Relevant ist das für Firmen mit Entwickler-Clients unter Windows, auf denen heute Docker Desktop, Podman Desktop oder eine Docker-Engine in einer WSL-Distribution läuft, und für Admins, die WSL per Intune oder Gruppenrichtlinie steuern.

Nicht betroffen sind Windows-Server mit produktiven Container-Workloads, Linux-Server und Clients ohne WSL. Sofortiger Handlungsbedarf besteht nicht, eine Sicherheitslücke steckt hinter der Meldung nicht. Admins sollten aber zeitnah entscheiden, ob WSLC in ihrer Umgebung erlaubt sein soll: Wer WSL bereits auf Version 3.0.1 aktualisiert, bringt wslc.exe automatisch auf die Rechner. Die passenden Richtlinien existieren und gehören ins nächste Wartungsfenster.

Was ist passiert?

Logan Iyer, Corporate Vice President Windows Platform und Developer, hat die allgemeine Verfügbarkeit im Windows Developer Blog angekündigt. Zeitgleich erschien im Microsoft-Entwicklerblog ein technischer Architekturbeitrag, und auf GitHub steht das WSL-Release 3.0.1 mit dem Hinweis bereit, dass WSLC nun allgemein verfügbar ist. Die öffentliche Vorschau war seit dem 29. Juni 2026 mit WSL 2.9.3 verfügbar, vorgestellt hatte Microsoft das Feature auf der Build 2026.

WSLC ist kein eigenständiges Produkt, sondern ein Bestandteil von WSL. Es besteht laut Microsoft Learn aus zwei Komponenten:

• wslc.exe: eine Kommandozeile zum Bauen, Starten und Verwalten von Linux-Containern. Sie ist bewusst an die gewohnte Container-Syntax angelehnt, etwa wslc run, wslc build, wslc image list oder wslc container stop. Zusätzlich gibt es den Alias container.exe.
• WSL container API: ein NuGet-Paket namens Microsoft.WSL.Containers, mit dem Windows-Anwendungen Linux-Container programmatisch starten können. Die C#-Projektion ist Teil des Pakets, die C++/WinRT-Projektion kennzeichnet Microsoft noch als Vorschau mit möglichen Breaking Changes.

Neu gegenüber der Vorschau sind laut Ankündigung unter anderem:

• wslc container restart und wslc container cp zum Kopieren von Dateien per Tar-Archiv
• wslc system info für einen Überblick über die Container-Umgebung und wslc events für Live-Ereignisse
• wslc network connect und wslc network disconnect sowie frei wählbare Treiberoptionen bei wslc network create
• Unterstützung für Container-Healthchecks, --stop-timeout und --mount bei wslc create und wslc run
• ein konfigurierbarer Speicherpfad für die Standard-Session, damit Container-Daten auf einem anderen Laufwerk liegen können

Für wen ist das relevant?

Voraussetzung ist WSL ab Version 2.9.3, die GA-Version ist 3.0.1. Microsoft Learn nennt als Installationsweg schlicht wsl --update, alternativ das Paket von der GitHub-Releaseseite. Eine eigene Liste unterstützter Windows-Versionen für WSLC nennen die geprüften Microsoft-Seiten nicht. Für WSL im Unternehmen allgemein setzt Microsoft Windows 10 22H2 oder Windows 11 22H2 voraus. Ob WSLC auf allen diesen Versionen den vollen Funktionsumfang bietet, ist damit nicht bestätigt und sollte vor einem Rollout getestet werden.

• Entwicklerteams auf Windows: WSLC bringt eine vom Hersteller des Betriebssystems gepflegte Container-Laufzeit mit. VS Code Dev Containers, die VS-Code-Container-Erweiterung und .NET Aspire unterstützen WSLC laut Microsoft bereits.
• Firmen mit Docker-Desktop-Lizenzen: Docker Desktop ist laut Docker nur für Unternehmen mit weniger als 250 Beschäftigten und weniger als 10 Millionen US-Dollar Jahresumsatz kostenlos. Größere Firmen brauchen ein kostenpflichtiges Abo. Microsoft selbst vermarktet WSLC nicht als Ersatz für Docker Desktop, eine Kostenersparnis ist deshalb eine eigene Rechnung und keine Herstelleraussage.
• Softwarehäuser mit Windows-Anwendungen: Über die API können eigene Programme Linux-Komponenten in Containern mitliefern, etwa lokale KI-Workloads.
• Admins mit Intune und Defender for Endpoint: Für sie ist WSLC vor allem eine Richtlinienfrage, siehe unten.

Was ändert sich technisch?

Laut dem Architekturbeitrag von Microsoft unterscheidet sich WSLC in mehreren Punkten vom klassischen WSL:

• Sessions pro Benutzer: Der privilegierte Dienst wslservice.exe erzeugt die virtuelle Maschine, gibt die Kontrolle aber an einen Kindprozess wslcsession.exe ab, der im Kontext des aufrufenden Benutzers läuft. Container anlegen, Verzeichnisse einbinden und Ports freigeben passiert damit in einem weniger privilegierten Prozess.
• Eigene VHD pro Session: Images, Container, Netzwerke und Volumes einer Session liegen in einer eigenen virtuellen Festplatte, bei wslc.exe unter %AppData%\Local\wslc\sessions. Für Backup- und Speicherplatzplanung auf Clients ist das ein neuer Pfad.
• virtiofs statt Plan 9: Windows-Verzeichnisse werden per virtiofs in Container eingebunden. Microsoft spricht von etwa doppelter Geschwindigkeit gegenüber Plan 9.
• Netzwerkmodell Consommé: Der Datenverkehr der Linux-VM wird von einem Windows-Prozess im Namen des Benutzers weitergeleitet. Er erscheint damit wie Verkehr eines normalen Windows-Prozesses, was laut Microsoft die Verträglichkeit mit VPN-Clients und Firewalls verbessert.

Den Quellcode veröffentlicht Microsoft im Repository microsoft/WSL auf GitHub, das unter der MIT-Lizenz steht. Eine wichtige Lücke nennt Microsoft selbst: Compose-Unterstützung fehlt noch. Sie ist laut Ankündigung der am häufigsten gewünschte Punkt und das Ziel der nächsten Versionen, bestehende compose.yaml-Dateien sollen dann unverändert laufen. Einen Termin gibt es dafür nicht.

Wie kritisch ist das?

Es handelt sich um eine Produktneuerung, nicht um ein Sicherheitsereignis. Kritisch ist eher die stille Verbreitung: Wo WSL über wsl --update oder die Softwareverteilung aktuell gehalten wird, steht wslc.exe nach dem Update ohne weiteres Zutun bereit. Nutzer können dann Images aus beliebigen öffentlichen Registries ziehen und Ports auf dem Client öffnen, sofern keine Richtlinie greift.

Für die Sicherheitsbetrachtung positiv sind die Trennung der Sessions in eigene Benutzerprozesse und die Integration in Defender for Endpoint. Microsoft gibt an, dass das WSL-Plugin für Defender for Endpoint nun auch Prozess-, Datei- und Netzwerkaktivität aus WSL-Containern erfasst und dem Windows-Host zuordnet. Unabhängig geprüft ist das bislang nicht.

Was sollten Admins jetzt tun?

• WSL-Versionen inventarisieren: auf Entwickler-Clients wsl --version abfragen und notieren, wo bereits 2.9.3 oder neuer installiert ist. Dort ist wslc.exe schon vorhanden, wslc version bestätigt das.
• Entscheiden, ob WSLC erlaubt sein soll. In Intune steuert die neue Einstellung Allow WSL containers access den Zugriff auf das gesamte Feature. In der Vorschau war die Steuerung laut Microsoft bereits per Gruppenrichtlinie und ADMX möglich.
• Die Registry-Allowlist WSL containers registry allow list nutzen und nur freigegebene Container-Registries zulassen, etwa eine interne Registry oder geprüfte Quellen.
• Prüfen, ob das Defender-for-Endpoint-Plugin für WSL auf den Clients aktiv ist, damit Container-Aktivität im Sicherheitsmonitoring auftaucht.
• Speicherplatz der Session-VHDs unter %AppData%\Local\wslc\sessions im Blick behalten oder den neuen konfigurierbaren Speicherpfad nutzen.
• Vor einem Wechsel von Docker Desktop die eigenen Workflows testen. Ohne Compose-Unterstützung scheitern Projekte mit mehreren Diensten derzeit am fehlenden compose up.
• Docker-Desktop-Lizenzen erst nach einem erfolgreichen Pilot kündigen oder reduzieren, nicht auf Basis der Ankündigung.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist WSLC vor allem eine Option, keine Pflicht. Firmen unter der Docker-Schwelle von 250 Beschäftigten und 10 Millionen US-Dollar Umsatz nutzen Docker Desktop ohnehin kostenlos, für sie zählen eher Verwaltbarkeit und einheitliche Werkzeuge. Größere Organisationen mit vielen Docker-Desktop-Lizenzen haben ein finanzielles Argument, einen Pilot zu starten, sollten aber die fehlende Compose-Unterstützung und die Reife der Werkzeugintegration realistisch einplanen.

Der eigentliche Mehrwert für Admins liegt in der Governance. Bisher war Container-Nutzung auf Clients oft ein blinder Fleck, weil Entwickler Docker-Engines selbst in WSL-Distributionen installierten. Mit WSLC gibt es eine vom Betriebssystemhersteller unterstützte Laufzeit, die sich per Intune abschalten oder auf freigegebene Registries beschränken lässt. Wer das nicht aktiv regelt, bekommt die Funktion trotzdem mit dem nächsten WSL-Update, dann aber ohne Leitplanken.

Passende Anleitungen auf S-EDV

• Docker VMM: Eigene Virtualisierung löst libkrun und WSL 2 ab: wie Docker Desktop unter Windows seine Virtualisierung umbaut.
• Harbor als eigene Container-Registry mit Docker: passendes Ziel für eine Registry-Allowlist im Unternehmen.
• Windows-Geräte mit Intune und Autopilot ausrollen: Grundlage, um WSL-Richtlinien zentral zu verteilen.

Quellen

• Windows Developer Blog: WSL containers is now generally available (29.09.2026)
• Microsoft Command Line Blog: WSLC Architecture deep dive (29.09.2026)
• Microsoft Learn: WSL container, CLI und API
• Microsoft Learn: Einstieg in WSL-Container mit wslc.exe
• GitHub: WSL-Release 3.0.1 mit allgemeiner Verfügbarkeit von WSLC
• Microsoft Command Line Blog: öffentliche Vorschau von WSL container (29.06.2026)
• Docker Docs: Lizenzbedingungen für Docker Desktop
• Phoronix: Microsoft kündigt allgemeine Verfügbarkeit von WSLC an