WSL 3 upgrade guide: release date, how to update, and your first wslc commands

WSL 3.0.1, the first release of the Windows Subsystem for Linux with the 3.0 version number, came out on September 29, 2026, and wsl --update is all it takes to get it. The release marks the built-in container tool wslc as generally available, so you can run Linux containers on Windows without installing a separate engine. This guide covers the release date, who can upgrade, the update steps, a first session with wslc, how Windows files reach containers, and what is still missing. Every command and version below was checked against Microsoft’s documentation or the microsoft/WSL releases page on October 18, 2026. For the news angle, see our WSL 3.0 release report.

Key points

• Release date: 3.0.1 was published on September 29, 2026. 3.0.2 followed on October 5 as a pre-release, and 3.0.3 on October 9 is the latest listed release, with the kernel at 6.18.54.1.
• Upgrade command: wsl --update from PowerShell, then wsl --version to confirm. wslc needs WSL 2.9.3 or higher per Microsoft Learn, so anything on 3.0.x qualifies.
• Not everything is there yet: wslc compose is not available, and Microsoft calls it the most requested feature and the focus of upcoming work.

Release dates by version

WSL 3.0 is a version number, not a separate product you install next to WSL 2. The GitHub releases page lists the 3.0.x line like this.

Version	Date	Status on the releases page	What it carries
3.0.1	Sep 29	Release	“WSLc is generally available”; STDIN support in the SDK; VM termination timeout raised to 30 seconds
3.0.2	Oct 5	Pre-release	wslc events --format json, container health notifications, kernel headers and perf tools exposed to distributions
3.0.3	Oct 9	Latest	Kernel 6.18.54.1, build context read from stdin, fixes to event filters

If you searched for a “WSL 3 release date”, the answer is September 29, 2026. The distinction matters when you update: a plain wsl --update gives you the newest non-pre-release build, while wsl --update --pre-release opts into previews.

Who can upgrade

WSL’s own install page states that the commands require Windows 10 version 2004 (build 19041) or later, or Windows 11. Microsoft’s announcement does not name a Windows version for wslc. Our news entry originally said Windows 11 only; we corrected it on 2026-10-18 because the primary sources above do not say that. Windows Latest, which tested the release, reported that wslc ran on Windows 10 and that a Microsoft program manager said WSL containers work wherever WSL is supported today. Treat that as a reported result, not a guarantee, and check wsl --version after updating on a Windows 10 machine before you plan around it.

Per Microsoft Learn, the container feature itself requires WSL 2.9.3 or higher, so any machine that already runs a recent Store-delivered WSL only needs the update.

Upgrade steps

Updating WSL takes two commands in PowerShell, and the second one confirms what you got.

1. Back up any distribution you cannot afford to lose. wsl --export <Distribution Name> <FileName> writes a snapshot to a tar file (Microsoft’s basic commands reference documents it).

2. Run the update:

   wsl --update
   

3. Check the result:

   wsl --version
   

4. If the Microsoft Store route is blocked on your network, wsl --update --web-download downloads the update from GitHub instead.

To try a preview build without joining the Windows Insider program, Microsoft documents wsl --update --pre-release.

First wslc session

wslc.exe ships inside WSL, so after the update there is nothing else to install. These commands come from Microsoft’s getting-started tutorial.

wslc version
wslc run --rm hello-world
wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"
wslc run -d --rm -p 8080:80 --name web nginx
curl localhost:8080
wslc container list
wslc exec web cat /etc/os-release
wslc container stop web

The first command prints the version, the second pulls and runs a test image, and the nginx lines show a published port reachable from Windows at localhost:8080. --rm removes the container once it stops. To build your own image, put a Containerfile in the project folder and run wslc build -t helloworld-django ., then start it with wslc run -d --rm -p 8000:8000 --name django helloworld-django.

Handy follow-ups from the same tutorial: wslc --help, wslc image list, wslc container list --all, wslc stats, wslc container logs <id>, and wslc container prune plus wslc image prune to reclaim disk space. The announcement also notes that container.exe is an alias for wslc.exe.

To change CPU, memory or storage for the container session, run wslc settings. It creates %LOCALAPPDATA%\wslc\settings.yaml, and the settings page says .wslconfig does not apply to wslc. Stop a running session with wslc system session terminate so new values load.

virtiofs and file access

Windows folders reach containers over virtiofs. The architecture write-up on the Windows Command Line blog says volumes are virtiofs shares mounted inside the Linux VM and attached to containers as bind mounts, and it describes virtiofs as about twice as fast as the plan9 protocol that regular WSL uses. Microsoft has not published the test conditions, so read that as a vendor figure and measure on your own repository.

Its example mounts a Windows folder like this:

wslc container run -v C:\Windows\System32\drivers\etc:/volume -it debian:latest ls /volume

Microsoft’s tutorial still advises keeping project code on the same file system as the tools that use it: edit in the Linux distribution when you use Linux tools. For volumes that need a native Linux file system, the deep dive describes VHD-backed volumes created with wslc volume create --driver vhd.

Known limits and rollback

Several gaps are documented or reported, and you should check them before moving a team over.

• wslc compose does not exist yet. The announcement says the goal is to run existing compose.yaml files unchanged, with no date.
• Windows Latest relays a Microsoft statement that --privileged is not there yet, which matters for tools that run clusters inside containers. This is second-hand, so verify it against your workload.
• Microsoft Learn says the C++/WinRT projection of the container API is in preview and may break.

On rollback, I found no documented command in Microsoft’s docs that downgrades WSL to an earlier version. The releases page lists each version, but Microsoft does not describe a downgrade procedure, so I won’t give one. The safe path is the wsl --export snapshot from step 1 before you update. If you hit a problem, report it in the microsoft/WSL issue tracker, which Microsoft links as the feedback channel on its pages.

Run the update on one machine first, work through the hello-world and nginx examples above, then test your real bind mounts and your Compose-dependent workflows before you roll it out wider.