Microsoft udostępnił 29 czerwca 2026 r. WSL Containers, czyli WSLC, w public preview wraz z wydaniem WSL 2.9.3 w kanale pre-release. To nie jest kosmetyczna aktualizacja Windows Subsystem for Linux. Do WSL trafia osobny interfejs wslc.exe, alias container.exe oraz API dla aplikacji Windows, które mogą programowo uruchamiać kontenery Linuksa jako część własnej logiki. Dla administratorów, DevOpsów i zespołów developerskich oznacza to kolejny krok w stronę natywnego, zarządzalnego środowiska kontenerowego na stacjach z Windows 11, bez obowiązkowego instalowania Docker Desktop, Podman Desktop albo Rancher Desktop tylko po to, aby odpalić lokalny kontener Linuksa.
Temat jest ważny również dla osób pracujących głównie na Linuksie, bo zmienia sposób, w jaki organizacje mogą standaryzować środowiska developerskie. W wielu firmach kod powstaje na laptopach z Windows, ale aplikacje i pipeline’y żyją później na Linuksie: w Kubernetes, na maszynach wirtualnych, w CI/CD albo w chmurze. WSLC próbuje skrócić tę ścieżkę: developer uruchamia ten sam typ workloadu kontenerowego lokalnie, a zespół IT dostaje mechanizmy polityk, allowlist rejestrów i integracji z narzędziami enterprise.
Co dokładnie zostało wydane 29 czerwca 2026 r.
Public preview WSL Containers pojawiło się jako część WSL 2.9.3. Aktualizacja dodaje dwie główne warstwy. Pierwsza to CLI wslc.exe, które ma obsługiwać typowe zadania: uruchamianie, budowanie, zatrzymywanie, inspekcję i usuwanie kontenerów oraz pracę z obrazami. Druga to WSL container API dostępne m.in. przez pakiet NuGet Microsoft.WSL.Containers, z projekcjami dla C#, C++/WinRT oraz referencją API obejmującą sesje, kontenery, procesy, obrazy i storage.
Z punktu widzenia praktyka najważniejsze jest to, że Microsoft nie ograniczył się do prostego wrappera na istniejący daemon. WSLC ma własną koncepcję sesji, zarządzania obrazami i kontenerami, port mappings, wolumenów oraz integracji buildowej z MSBuild i CMake. W notatkach wydania WSL 2.9.3 wymieniono m.in. resource limits przez --cpus, --memory i --ulimit, obsługę --shm-size, operacje na obrazach takie jak pull, push, import, save i inspect, sieci z aliasami oraz port publishing, VHD-backed volumes i wsparcie GPU przez CDI.
Warto zwrócić uwagę na wymagania: dokumentacja Microsoftu mówi wprost, że funkcja wymaga WSL 2.9.3 lub nowszego, a w sierpniu 2026 r. ta wersja jest dostępna w kanale pre-release. To oznacza, że nie należy jeszcze traktować WSLC jako bezpiecznego zamiennika produkcyjnych workflow bez testów regresji, walidacji polityk i kontroli kompatybilności z używanymi obrazami.
Minimalny test w laboratorium
Najprostszy scenariusz testowy można wykonać z PowerShella na maszynie developerskiej. Celem nie jest jeszcze migracja całego stacku, tylko sprawdzenie, czy nowy runtime działa, czy potrafi pobrać obraz, wystawić port i czy sieć zachowuje się poprawnie w firmowym środowisku z VPN, proxy oraz lokalnym firewallem.
# PowerShell
wsl --update --pre-release
wsl --version
# Test podstawowego obrazu Linuksa
wslc run --rm -it ubuntu:latest bash -lc 'cat /etc/os-release; uname -a'
# Prosty test port publishing
wslc run -it --rm -d -p 8080:80 --name web nginx
curl http://localhost:8080
wslc container ps
wslc container stop webTen krótki test daje kilka informacji naraz. Po pierwsze, weryfikuje instalację kanału pre-release i dostępność binarki wslc. Po drugie, pokazuje, czy pobieranie obrazów z rejestru działa w sieci organizacji. Po trzecie, sprawdza trasowanie portu z kontenera do hosta Windows. To ostatnie jest szczególnie istotne, bo w środowiskach korporacyjnych najwięcej problemów powodują zwykle VPN-y, zapory, transparentne proxy, rozwiązywanie DNS i narzędzia inspekcji ruchu.
Dlaczego to ma znaczenie dla administratorów Linuksa
Administrator Linuksa może zapytać: po co przejmować się kontenerami w Windows, skoro produkcja i tak działa na Linux kernel, containerd, CRI-O albo Docker Engine? Odpowiedź jest organizacyjna i operacyjna. Stacje robocze są częścią łańcucha dostaw oprogramowania. Jeśli developerzy budują i testują obrazy lokalnie, to ich runtime, polityki dostępu do rejestrów, sposób montowania katalogów i obsługa sekretów wpływają później na jakość oraz bezpieczeństwo wdrożeń.
WSLC może zmniejszyć rozjazd między środowiskiem developerskim a linuxowym runtime’em w CI/CD, ale tylko wtedy, gdy zostanie wprowadzony świadomie. Nowe narzędzie nie zwalnia z podstawowych zasad: obraz powinien mieć jawny tag lub digest, zależności muszą przechodzić skanowanie, kontenery nie powinny dostawać nadmiarowych uprawnień, a porty i wolumeny powinny być dokumentowane. Różnica polega na tym, że część kontroli może teraz wejść na poziom zarządzania stacją Windows, a nie tylko instrukcji w README.
- Dla DevOpsów: WSLC może uprościć onboarding developerów, którzy potrzebują lokalnie kontenera Linuksa, ale nie całego rozbudowanego desktopowego stosu kontenerowego.
- Dla administratorów endpointów: pojawia się punkt kontroli dla WSL i kontenerów poprzez polityki, w tym allowlistę rejestrów obrazów.
- Dla zespołów bezpieczeństwa: integracja z Microsoft Defender for Endpoint dla zdarzeń kontenerowych została zapowiedziana jako private preview, więc warto monitorować jej dojrzewanie.
- Dla maintainerów platform developerskich: trzeba przetestować zgodność z devcontainerami, skryptami buildowymi i lokalnymi zależnościami, zanim WSLC trafi do standardowego obrazu laptopa.
Enterprise: polityki, rejestry i obserwowalność
Jedną z ciekawszych części ogłoszenia nie jest samo wslc run, ale zarządzanie. Microsoft zapowiedział możliwość kontrolowania, czy użytkownicy mogą korzystać z dystrybucji WSL i kontenerów, a także definiowania listy dozwolonych rejestrów, z których wolno pobierać obrazy. W momencie publikacji public preview ustawienia są dostępne przez GPO i politykę ADMX, a wsparcie w dashboardach Intune ma trafić później.
To odpowiada na realny problem: w wielu firmach developer może uruchomić lokalnie praktycznie dowolny obraz z publicznego rejestru. Jeśli taki obraz zawiera podatną bibliotekę, koparkę, credential stealer albo narzędzia omijające polityki proxy, endpoint staje się słabym punktem. Allowlista rejestrów nie rozwiązuje wszystkiego, ale jest dobrym minimum. W praktyce warto połączyć ją z prywatnym registry, skanowaniem obrazów, podpisywaniem artefaktów i polityką usuwania nieużywanych obrazów.
Drugi aspekt to logi i statystyki. WSL 2.9.3 wymienia wslc logs z filtrami czasu, statystyki kontenerów i ustrukturyzowane wyjście CLI. To drobiazgi, które decydują, czy narzędzie nadaje się do codziennej diagnostyki. Bez możliwości szybkiego sprawdzenia logów, stanu kontenera, mapowania portów i zużycia zasobów każdy runtime staje się czarną skrzynką.
Virtiofs, Consomme i pamięć: mniej tarcia przy pracy z plikami
WSLC przynosi również zmiany pod spodem. Microsoft wskazał virtiofs jako nowy domyślny system plików dla WSL Containers, deklarując dwukrotnie szybszy dostęp do plików Windows. Dla osób budujących projekty z tysiącami małych plików — typowy frontend, monorepo, repozytoria Go, Rust, Python albo Node.js — różnica w I/O może być bardziej odczuwalna niż samo dodanie nowej komendy.
Drugim elementem jest eksperymentalny tryb sieciowy Consomme. Jego założenie jest proste: ruch sieciowy Linuksa ma być przekazywany przez Windows, aby kontenery korzystały z tego samego środowiska sieciowego, polityk bezpieczeństwa i integracji enterprise co aplikacje Windows. To brzmi jak detal, ale w praktyce może ograniczyć klasę błędów, w których kontener działa w domu, a przestaje działać za firmowym VPN-em albo przy inspekcji TLS.
Trzeci obszar to odzyskiwanie pamięci. WSL od lat bywa krytykowany za sytuacje, w których maszyna wirtualna zatrzymuje zbyt dużo RAM po zakończeniu intensywnego workloadu. WSL 2.9.3 zapowiada ulepszone techniki stopniowego i spójnego oddawania pamięci do hosta Windows, gdy nie jest używana przez VM. Dla laptopów developerskich z kilkoma środowiskami, IDE i przeglądarką pełną kart może to być bardzo praktyczna zmiana.
GPU i lokalne workloady AI/ML
WSL Containers wpisują się także w trend lokalnych workloadów AI/ML. W ogłoszeniu pokazano przykład kontenera PyTorch uruchamianego z --gpus all, a notatki wydania WSL 2.9.3 wspominają o GPU-enabled containers z CDI oraz dostępem do bibliotek i narzędzi GPU dla użytkowników nie-root. Dla zespołów pracujących nad inference, testami modeli, przetwarzaniem obrazu albo pipeline’ami danych oznacza to potencjalnie łatwiejsze uruchamianie linuxowych obrazów GPU na stacjach Windows.
Tu jednak trzeba zachować ostrożność. Lokalne GPU w kontenerze to świetne narzędzie developerskie, ale wymaga kontroli wersji sterowników, obrazu bazowego, CUDA/cuDNN, uprawnień i limitów zasobów. Jeśli firma używa różnych generacji GPU albo różnych wersji driverów, warto przygotować małą macierz kompatybilności i test startowy, który jednoznacznie raportuje dostępność urządzenia oraz wersje bibliotek.
# Przykładowy smoke test GPU w WSLC
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \
python -c 'import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))'Co sprawdzić przed wdrożeniem w zespole
Public preview to dobry moment na pilotaż, ale z kontrolowaną listą kryteriów. Nie wystarczy sprawdzić, że nginx odpowiada na porcie 8080. Trzeba porównać WSLC z obecnym runtime’em w realnych przypadkach: prywatne rejestry, obrazy wymagające GPU, montowanie katalogów z repozytorium, lokalne bazy danych, wolumeny, certyfikaty firmowe, proxy, VPN i debugowanie z IDE.
- Wybierz 2-3 reprezentatywne projekty: prostą usługę HTTP, projekt z bazą danych i projekt z dużą liczbą plików.
- Sprawdź pobieranie obrazów z firmowego registry oraz zachowanie po zablokowaniu publicznych rejestrów.
- Zmierz czas builda i startu kontenera na danych przechowywanych po stronie Windows oraz w filesystemie Linuksa.
- Zweryfikuj port publishing, DNS, proxy i dostęp do usług na hoście Windows.
- Przetestuj limity CPU/RAM oraz czyszczenie obrazów, kontenerów, wolumenów i sesji.
- Ustal, czy devcontainery w VS Code mogą wskazywać
wslcjako ścieżkę do narzędzia kontenerowego w danym workflow.
Najważniejsze ograniczenie: to nadal preview
Microsoft deklaruje cel udostępnienia WSL Containers jako general availability jesienią 2026 r., ale na 4 sierpnia 2026 r. mówimy o public preview w pre-release WSL. To oznacza możliwe zmiany API, brak pełnej kompatybilności ze wszystkimi flagami znanymi z innych narzędzi, potencjalne problemy z nietypowymi urządzeniami, USB passthrough, zaawansowaną siecią i workflow opartymi o compose. W praktyce WSLC warto traktować jako technologię do laboratorium, pilotażu i przygotowania polityk, a nie natychmiastowy standard dla całej organizacji.
Nie należy też mieszać pojęć. WSLC nie sprawia, że produkcyjne kontenery przestają być linuxowym problemem. Kernel, namespace’y, cgroups, obrazy OCI, podatności w warstwach i zarządzanie sekretami nadal wymagają tej samej dyscypliny. Zmienia się przede wszystkim miejsce, w którym developer może uruchomić workload, oraz zestaw narzędzi, którymi dział IT może ten workload kontrolować na endpointach.
Podsumowanie praktyczne
WSL Containers z 29 czerwca 2026 r. to jedna z ciekawszych zmian w lokalnych środowiskach kontenerowych dla zespołów pracujących między Windowsem a Linuksem. Warto zainstalować WSL 2.9.3 pre-release na kilku testowych maszynach, uruchomić wslc na realnych projektach, sprawdzić sieć, registry, GPU i polityki GPO/ADMX. Jeśli wyniki będą dobre, można przygotować standard pilotażowy dla developerów. Jeśli pojawią się problemy, lepiej wykryć je teraz, zanim funkcja trafi do wersji stabilnej zapowiadanej na jesień 2026 r.
