Il 29 settembre 2026 Microsoft ha reso generalmente disponibili i container WSL, portando su Windows la possibilità di eseguire container Linux nativi senza installare Docker Desktop. La funzionalità arriva con wslc.exe, un nuovo strumento a riga di comando integrato direttamente nel Windows Subsystem for Linux (WSL 3.0.1), e segna un passo importante per chi lavora quotidianamente con container su macchine Windows: sviluppatori .NET, team DevOps e sistemisti che gestiscono ambienti ibridi.

In questo articolo vediamo cosa cambia rispetto a Docker Desktop, come installare e usare wslc, quali sono i controlli enterprise disponibili tramite Intune e Defender for Endpoint, e quali limiti bisogna conoscere prima di adottarlo in produzione.

Perché WSL containers e non “solo” Docker Desktop

Fino ad oggi, eseguire container Linux su Windows significava quasi sempre installare Docker Desktop, che a sua volta si appoggia su una VM WSL2 per fornire il kernel Linux. Con i container WSL, Microsoft sposta il motore dei container direttamente dentro l’infrastruttura WSL, eliminando uno strato intermedio: niente demone Docker separato da gestire, niente licenza Docker Desktop da considerare per le aziende con più di 250 dipendenti o oltre 10 milioni di dollari di fatturato (requisito che per molte realtà italiane ha reso Docker Desktop un costo da giustificare).

Il risultato dichiarato da Microsoft è un accesso ai file Windows fino a 2 volte più veloce rispetto alle soluzioni basate su virtiofs tradizionale, grazie a un nuovo modello di rete chiamato internamente “Consommé mode”, che instrada il traffico della VM attraverso un processo Windows eseguito con i permessi dell’utente della sessione, migliorando la compatibilità con VPN aziendali e firewall perimetrali — uno scenario molto comune nelle reti enterprise italiane dove Docker Desktop spesso va in conflitto con client VPN come Cisco AnyConnect o Fortinet.

Installazione e primi comandi

Non serve installare nulla di separato: wslc.exe è incluso a partire da WSL 3.0.1. Basta aggiornare WSL dal prompt dei comandi o da PowerShell:

wsl --update
wsl --version

Il comando wsl --version deve riportare almeno la 3.x (oppure 2.9.3+ per chi è rimasto sul canale di anteprima). Fatto questo, si può avviare subito un primo container di prova:

wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"

Per un caso d’uso più realistico, ecco come avviare un web server Nginx in background con il port forwarding verso l’host Windows:

wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080

La gestione del ciclo di vita dei container ricalca la sintassi Docker, cosa che rende la curva di apprendimento quasi nulla per chi già conosce Docker CLI:

wslc container ps
wslc container stop web
wslc container restart web
wslc container cp web:/var/log/nginx/access.log .
wslc system info
wslc events

Con la GA sono arrivati anche comandi per la gestione della rete, utili quando si orchestrano più container che devono comunicare tra loro:

wslc network create mynet
wslc network connect mynet web
wslc network disconnect mynet web

Per le immagini, sono supportati i flag più comuni per operazioni di pull/push ed ispezione:

wslc pull --all-tags myregistry/myimage
wslc image list --all --digests
wslc image inspect --size myregistry/myimage

Architettura: cosa succede sotto il cofano

Dal punto di vista architetturale, Microsoft ha separato le responsabilità in due processi distinti:

• wslservice.exe crea la macchina virtuale WSL ma non ne mantiene la proprietà operativa dei container;
• wslcsession.exe, eseguito a livello utente, gestisce effettivamente i container, il mounting dei volumi e il binding delle porte.

Questa separazione mantiene isolate le operazioni privilegiate dal resto, un dettaglio che conta per chi deve valutare la postura di sicurezza dell’ambiente. Ogni sessione utente ha il proprio disco virtuale dedicato, salvato in %AppData%\Local\wslc\sessions, che contiene immagini, container, reti e volumi di quella sessione. I path Windows vengono montati tramite virtiofs, mentre i filesystem nativi Linux usano volumi basati su VHD per prestazioni migliori.

Supporto GPU e integrazione .NET

Per chi sviluppa su Windows con carichi di lavoro che richiedono accelerazione hardware (training di modelli, inferenza locale, elaborazione video), l’accesso alla GPU è esposto tramite il nuovo pacchetto NuGet Microsoft.WSL.Containers, che oltre alla GPU espone anche stdin/stdout, mount di file e configurazione di rete direttamente da codice C#. È un’ottima notizia per i team .NET che vogliono orchestrare container Linux senza uscire dal proprio stack di sviluppo abituale, magari dentro una pipeline di test o un tool interno scritto in C#.

Da notare che il supporto per la projection C++/WinRT è ancora in anteprima e soggetto a breaking change, mentre l’API per sviluppatori C# risulta più stabile e pronta per un uso quotidiano.

Controlli enterprise: Intune e Defender for Endpoint

Per i reparti IT che devono governare l’adozione di questa tecnologia in azienda, Microsoft ha introdotto due leve di controllo tramite Intune:

• Allow WSL containers access: un interruttore on/off per abilitare o disabilitare completamente la funzionalità sui dispositivi gestiti;
• WSL containers registry allow list: permette di restringere il pull delle immagini solo ai registry approvati, un controllo fondamentale per evitare che gli utenti scarichino immagini da fonti non verificate.

Sul fronte della sicurezza runtime, il plugin WSL di Microsoft Defender for Endpoint è stato esteso per coprire anche i container, mostrando attività di processo, file e rete collegate all’host Windows. È importante sottolineare che si tratta di visibilità e capacità di indagine, non di un meccanismo di enforcement in tempo reale: Defender segnala e documenta, ma la prevenzione attiva resta affidata alle policy Intune.

I limiti da conoscere prima di migrare

Prima di sostituire Docker Desktop in produzione, vale la pena considerare alcuni limiti ancora presenti alla GA:

• Nessun supporto Compose: è la funzionalità più richiesta dalla community e il lavoro è iniziato, ma Microsoft non ha ancora comunicato una data di rilascio. Chi ha workflow multi-servizio basati su docker compose up dovrà continuare a usare strumenti alternativi o avviare manualmente i singoli container;
• Compatibilità “quasi” totale: test di terze parti riportano buona compatibilità con i comandi Docker esistenti, ma non totale — vale la pena testare gli script di automazione esistenti prima di un rollout su larga scala;
• API C++/WinRT instabile: chi sviluppa tooling nativo in C++ dovrà aspettarsi possibili breaking change nelle prossime release.

Conclusione: chi dovrebbe provarlo subito

Per sviluppatori singoli e piccoli team che non dipendono da Docker Compose, i container WSL rappresentano già oggi un’alternativa solida, gratuita e integrata nativamente in Windows, con un vantaggio prestazionale concreto sull’I/O dei file. Per i team che si affidano a Compose nei workflow quotidiani, conviene affiancare wslc agli strumenti attuali e monitorare l’evoluzione del supporto. Per i reparti IT enterprise, il consiglio è di testare i controlli di governance (Intune e Defender) in un gruppo pilota prima di abilitare la funzionalità su larga scala, verificando in particolare il comportamento con le VPN aziendali e i registry Docker privati già in uso.

Fonte: 4sysops.com e WindowsForum