Das Windows Subsystem for Linux (WSL) hat sich in vielen Unternehmen vom praktischen Zusatzwerkzeug zur festen Brücke zwischen Windows-Clients und Linux-Workloads entwickelt. WSL kommt für Shell-Werkzeuge, Skripte, Build-Umgebungen, Cloud-Tools, Container-Workflows und zunehmend auch für KI- beziehungsweise Machine-Learning-Szenarien zum Einsatz. Auf der Build 2026 hat Microsoft nun den nächsten Schritt angekündigt: WSL-Container.

Damit soll Windows eine eingebaute Möglichkeit erhalten, Linux-Container direkt über WSL zu erstellen, auszuführen und zu verwalten. Microsoft stellt dafür zwei Bausteine in Aussicht: eine neue Kommandozeile namens wslc.exe sowie eine WSL-Container-API für Anwendungen, die Linux-Container programmatisch nutzen wollen. Die öffentliche Vorschau soll in den kommenden Monaten erscheinen.

WSL wird zur Container-Plattform

Bisher setzen viele Windows-Umgebungen für Linux-Container auf Drittanbieter-Tools wie Docker Desktop oder alternative Container-Stacks. Das funktioniert in der Praxis gut, bringt aber zusätzlichen Installations-, Lizenzierungs- und Administrationsaufwand mit sich. Genau hier setzt Microsoft an: WSL-Container sollen Container-Workflows stärker in Windows integrieren und ohne separate Grundkonfiguration nutzbar machen.

Die neue CLI wslc.exe soll dabei typische Aufgaben übernehmen:

• Container-Images bauen
• Linux-Container starten
• laufende Container verwalten
• mit Containerprozessen interagieren
• Container-Workflows direkt aus Windows heraus anstoßen

Der Ablauf soll vertraut bleiben: Linux-Container laufen in der WSL-Umgebung, lassen sich aber über Windows-Tools und Automatisierung ansprechen. Gleichzeitig stellt Microsoft eine API und Managementansätze in Aussicht, die sich besser in Windows-Umgebungen integrieren lassen als zusätzliche externe Werkzeuge.

Mehr Kontrolle für Unternehmen

Microsoft argumentiert ausdrücklich mit Enterprise-Kontrolle: Container-Workflows auf Windows hängen heute häufig von zusätzlicher Software ab. Dadurch entstehen Setup-Aufwand, mögliche Lizenzkosten und teils eingeschränkte Sichtbarkeit für IT-Abteilungen. Mit WSL-Containern sollen Unternehmen besser steuern können,

• welche Container auf Entwicklerrechnern laufen
• aus welchen Quellen Images bezogen werden
• wie Container mit dem Host interagieren
• welche Richtlinien für Aktivierung und Nutzung gelten

Damit adressiert Microsoft ein bekanntes Spannungsfeld: Linux-basierte Werkzeuge und Workflows sollen direkt auf Windows-Clients verfügbar sein, während IT-Abteilungen gleichzeitig Compliance, Softwareverteilung, Patchstand, Lizenzierung und Security im Blick behalten können. Je stärker Containerfunktionen in Windows selbst verankert sind, desto eher lassen sie sich über bekannte Verwaltungswege standardisieren.

Bedeutung für Dev-, Cloud- und KI-Workflows

WSL-Container zielen nicht nur auf klassische Webentwicklung. Microsoft nennt ausdrücklich lokale Entwicklung, KI-/ML-Workflows und containerisierte Tests als Einsatzfelder. Gerade bei KI-Szenarien ist die Nähe zu Linux relevant, weil viele Frameworks, Toolchains und Container-Images primär aus der Linux-Welt kommen.

Typische Szenarien sind etwa:

• lokale Testumgebungen für Microservices,
• CI-nahe Containerläufe auf Arbeitsplatzsystemen,
• reproduzierbare Build-Umgebungen,
• Linux-basierte Verarbeitung in nativen Windows-Anwendungen,
• lokale KI-Workloads mit containerisierten Frameworks.

Microsofts Ansatz passt damit zur größeren Windows-Strategie: Windows soll auch dann eine geeignete Arbeitsplattform bleiben, wenn Zielumgebungen auf Linux, Kubernetes, Cloud-Diensten oder KI-Stacks basieren. WSL wird damit weniger als Zusatzfunktion verstanden, sondern zunehmend als Bestandteil der Windows-Entwicklerplattform.

Kein offizielles "WSL 3" – Vorsicht bei der Begrifflichkeit

Rund um die Build 2026 kursierten mehrere Berichte über ein angebliches WSL 3 mit neuer Architektur und direkterem Zugriff auf GPU- und NPU-Ressourcen. Offiziell angekündigt und dokumentiert sind nach aktuellem Stand jedoch WSL-Container, nicht ein neues Produktrelease namens WSL 3.

Das ist für die Einordnung wichtig: WSL 1 und WSL 2 waren klar unterscheidbare Architekturgenerationen – zunächst mit Systemcall-Übersetzung, später mit echtem Linux-Kernel in einer leichtgewichtigen VM. Bei den jetzt angekündigten Neuerungen beschreibt Microsoft vor allem Containerfunktionen innerhalb von WSL, nicht den formalen Wechsel auf eine neue WSL-Hauptversion.

Die Funktion sollte daher zunächst unter dem Begriff WSL-Container eingeordnet und getestet werden. Ob Microsoft künftig tatsächlich eine neue WSL-Generation mit veränderter Architektur unter dem Namen WSL 3 veröffentlicht, bleibt abzuwarten.

Was bedeutet das für Docker Desktop?

WSL-Container werden Docker Desktop nicht automatisch ersetzen. Docker Desktop bietet weiterhin eine etablierte Oberfläche, Registry-Integration, Unternehmensfunktionen, Kubernetes-Optionen, Erweiterungen und ein großes Ökosystem. Dennoch dürfte Microsofts Schritt vor allem für Organisationen interessant sein, die einfache Linux-Container-Workflows auf Windows standardisieren wollen.

Mögliche Vorteile von WSL-Containern:

• weniger zusätzliche Basiskomponenten
• geringerer Setup-Aufwand
• bessere Integration in Windows-Verwaltung
• potenziell mehr Transparenz für IT-Abteilungen
• einheitlichere Entwicklungsumgebungen

Ob das in der Praxis reicht, hängt von den konkreten Anforderungen ab: Wer komplexe Docker-Desktop-Funktionen nutzt, wird nicht sofort wechseln. Wer dagegen vor allem Container bauen, starten und testen möchte, könnte mit WSL-Containern künftig eine schlankere Option erhalten.

Chancen und offene Fragen

Für IT-Abteilungen ist die Ankündigung vor allem aus Governance-Sicht relevant. Wenn Linux-Container zum Windows-Bordmittel werden, müssen sie auch wie ein regulärer Bestandteil der Client- und Entwicklerplattform behandelt werden.

Wichtige Fragen für den Betrieb:

• Wie lassen sich WSL-Container per Richtlinie aktivieren oder deaktivieren?
• Welche Image-Quellen dürfen genutzt werden?
• Wie werden laufende Container sichtbar gemacht?
• Wie erfolgt Logging und Inventarisierung?
• Welche Netzwerk- und Dateisystemzugriffe sind erlaubt?
• Wie werden Schwachstellen in Images und Toolchains geprüft?
• Welche Rolle spielen bestehende Endpoint-Security-Lösungen?

Gerade in größeren Unternehmen sollte der Rollout nicht allein aus Projektsicht erfolgen. Container auf Clients sind produktivitätsfördernd, können aber auch Schatten-IT, unkontrollierte Images oder unklare Datenflüsse begünstigen. Entscheidend wird daher sein, wie gut Microsoft die angekündigten Policy- und Managementfunktionen tatsächlich in Windows, Intune, Gruppenrichtlinien und vorhandene Security-Werkzeuge integriert.

Windows Developer Configurations als Ergänzung

Parallel zu WSL-Containern treibt Microsoft die Windows Developer Configurations voran. Damit sollen neue Arbeitsplätze schneller in einen produktiven Zustand kommen. Über WinGet-Konfigurationen und workload-spezifische Skripte lassen sich typische Werkzeuge wie WSL, PowerShell 7, Git, GitHub CLI, Visual Studio Code, Python und weitere Komponenten automatisiert installieren und konfigurieren.

Das ist ein weiterer Baustein für standardisierte Entwicklungsumgebungen: Nicht nur Container sollen leichter verfügbar werden, sondern die gesamte Arbeitsumgebung soll reproduzierbarer entstehen. Das passt gut zu Infrastructure-as-Code- und DevOps-Prinzipien auf dem Client.

Fazit

Mit WSL-Containern rückt Microsoft Linux-Workflows noch näher an den Windows-Desktop. In der Praxis dürfte das die Arbeit mit Linux-Containern unter Windows vereinfachen. Unternehmen erhalten zugleich die Chance, Container-Workflows besser zu standardisieren und zu kontrollieren – vorausgesetzt, die angekündigten Managementfunktionen halten in der Praxis, was Microsoft verspricht.

Wichtig bleibt die saubere Einordnung: Offiziell geht es derzeit um WSL-Container mit wslc.exe und API, nicht um ein bestätigtes WSL-3-Release. Unternehmen sollten die öffentliche Vorschau daher gezielt testen, bestehende Docker-Desktop- oder Container-Strategien aber nicht vorschnell ersetzen. Der Trend ist dennoch klar: Windows soll für Linux-basierte Dev-, Cloud-, Container- und KI-Workloads weniger Umweg und mehr native Arbeitsplattform werden.