Dora NodaFor a decade, "I develop on Windows" meant a Docker Desktop install was step zero of any container workflow — and for anyone at a company above Docker's free tier, step zero came with a per-seat invoice. On June 29, 2026, Microsoft removed that step. WSL Containers reached public preview in WSL 2.9.3, a few weeks after its unveiling at Build 2026, giving Windows 11 a built-in way to build, run, and manage OCI-compatible Linux containers with no third-party runtime installed first. One command — wsl --update --pre-release — and a Windows machine grows a container CLI called wslc.exe (aliased as container.exe) whose commands mirror Docker's almost one-for-one: wslc run, wslc build, wslc container list.
TL;DR for the git-push crowd: if your deploy pipeline starts with "build an OCI image on a Windows laptop," that step no longer needs Docker Desktop, its license, or its VM. The images wslc build produces are just OCI images — registries and PaaS builders cannot tell them apart from Docker-built ones. The table below is the whole story; the rest of this post fills in the two under-the-hood upgrades that make the loop genuinely good, the licensing math it sidesteps, and what's still preview-shaped.
| Step of the Windows dev loop | Before (Docker Desktop) | Now (WSL Containers preview) |
|---|---|---|
| Build a Linux image locally | docker build via Docker Desktop's VM + license | wslc build, same Dockerfile, no extra install |
| Iterate with bind mounts | 9P filesystem round-trips to Windows files | virtiofs default, 2x faster Windows file access |
| Pull/push behind corp VPN | NAT networking vs enterprise proxies, often broken | consomme mode relays through the Windows stack |
| GPU workloads (local AI) | Docker GPU passthrough config | GPU passthrough built in |
| License for a 30-dev team | Paid seats (see the math below) | Included with Windows |
What actually shipped
WSL Containers has two faces. The first is the CLI: wslc.exe ships with the WSL pre-release update and speaks Docker-like verbs, so muscle memory transfers directly. Hands-on reports from July confirm the shape — build an image from a Dockerfile, run any OCI-compatible Linux container, check logs with wslc logs --timestamps --since, view container stats — without Docker Desktop, Podman Desktop, or anything else in the loop.
The second face is the API: a Microsoft.WSL.Containers NuGet package exposing the container operations to native Windows apps in C, C++, and C#, with MSBuild and CMake integration so container build-and-deploy steps become lines in a project file rather than manual shell steps. That matters less for the git-push loop (you will use the CLI) and more for teams shipping Windows desktop software with a Linux sidecar — but it signals how Microsoft sees containers on Windows: a platform primitive, not a third-party accessory.
Underneath both faces are the two upgrades that decide whether this is a toy or a tool. virtiofs becomes the default filesystem for WSL containers, and Microsoft's number is concrete: Windows file access twice as fast as the old path. For a PaaS developer that number lands directly in the inner loop — bind-mounted source trees, live-reload dev servers, and volume-heavy test suites all pay the filesystem tax on every save. The second upgrade is consomme, a new networking mode that relays Linux container traffic through the Windows networking stack instead of the older NAT setup, so containers inherit the host's VPN, proxies, and enterprise security policies. Anyone who has debugged "registry pull works on my home network but not on the corporate VPN" knows exactly which pain this targets. Both are currently exclusive to WSL Containers, with Microsoft saying it wants to bring them to regular WSL distros eventually.
The fourth item in the box deserves its own paragraph for the AI-agent crowd: GPU passthrough. WSL Containers exposes the host GPU to Linux containers, which means local inference, model fine-tuning sidecars, and GPU-backed test suites run inside wslc-managed containers without Docker's GPU passthrough configuration. For developers building agent sandboxes or inference endpoints destined for a PaaS with GPU nodes, that closes a real parity gap — the container you test locally can use the same accelerator path it will use in production, on a Windows laptop with an NVIDIA card, with no third-party runtime negotiating the passthrough.
The new loop, end to end
Concretely, a Windows-first developer targeting a self-hosted git-push PaaS now works like this: write code, wslc build the Dockerfile locally to verify it, wslc run to smoke-test the result, push the image to the team's registry (or let the PaaS build from the git push — either way the local image is the source of truth for "does this container work"), then git push to deploy. Nothing in that chain requires a Docker daemon owned by a third party, because at no point does anything need to know which tool produced the image. OCI is OCI.
That last sentence is doing the load-bearing work in this post, so stress-test it. Could a PaaS builder reject or mishandle a wslc-built image? Only if the image violated the OCI image spec, which is exactly what "OCI-compatible" in Microsoft's announcement promises it won't. Registries accept any spec-compliant push; Kubernetes, buildpacks-based builders, and Dockerfile-based builders consume the config and layers, not the provenance. The realistic failure modes live one level down — a Dockerfile that assumes BuildKit-specific flags, a multi-arch manifest assembled differently — and those are Dockerfile-portability questions that predate wslc and apply equally to Podman, nerdctl, or any Docker alternative. For the standard single-arch Linux image a git-push PaaS consumes, the producer is interchangeable.
There is one gap worth naming honestly: orchestration. Docker Desktop ships Compose; the wslc world has community efforts like wslc-compose filling that hole, and no first-party Kubernetes story (no minikube/kind equivalent wired into WSL Containers yet). If your local loop is "spin up the app plus Postgres plus Redis with one command," you are either keeping a Compose-compatible tool around or waiting for the ecosystem to catch up. For the narrower loop this post is about — build the app image, verify it runs, push — wslc is already sufficient.
The licensing math it sidesteps
Here is the part self-hosted PaaS docs targeting Windows-using teams should call out explicitly. Docker Desktop is free for personal use, small businesses, education, and open source — and paid for everyone else, after price increases in December 2024 pushed Pro up roughly 80 percent. Current list pricing runs from about 9 dollars per user per month for Pro to 24 dollars per user per month for Business. Docker's paid threshold bites at 250 employees or 10 million dollars in revenue, and as this blog's earlier licensing breakdown calculated, a 30-developer team at a company over that line pays roughly 5,400 to 8,640 dollars a year for seats alone — before any audit lookback.
WSL Containers costs whatever Windows costs, which for the team's existing laptops is zero marginal dollars. For a 5-developer startup under the free threshold, the savings are zero — Docker Desktop was already free, and this changes nothing financially. For a 30-developer team at a 300-person company, dropping Docker Desktop for wslc deletes a five-figure-ish annual line item (8,640 dollars at Business list) plus the license-tracking overhead. For a 200-developer enterprise, the same arithmetic at 24 dollars a seat is 57,600 dollars a year. The honest framing is a range, not a headline number: the bigger the Windows-using team past Docker's free line, the more this preview is worth — and Microsoft even shipped group policy (ADMX) support in 2.9.3, so IT can manage the rollout the same way it manages everything else on the fleet.
Note what this doesn't change: Docker Engine on Linux servers, CI runners, and PaaS builders is unaffected — this is purely a Windows developer-workstation story. Teams already building images in CI never paid the seat tax for that step. The winners are teams whose Windows devs build locally, which in practice means most teams with Windows laptops and a Dockerfile in the repo.
What's still preview-shaped
Public preview means real but unfinished, so calibrate before rewriting your onboarding docs. WSL Containers requires the WSL pre-release line (2.8 or later, preview in 2.9.3) — not the stable WSL your IT department auto-updates — and GA timing is unannounced. The consomme networking mode is explicitly experimental. The Compose and local-Kubernetes gaps above are ecosystem holes, not roadmap promises. And "twice as fast" filesystem access is Microsoft's number on Microsoft's benchmarks; independent measurements of virtiofs vs 9P on real dev-tree workloads are still thin.
None of that disqualifies the preview for evaluation today. Install it on one Windows machine, wslc build your production Dockerfile, push the result to a staging registry, and deploy it to your PaaS. If the app boots, you've just proven the license-free loop works for your stack — and you can put the Docker Desktop renewal conversation on the calendar with an actual alternative in hand.
Windows devs building OCI images license-free and pushing them to machines they own is exactly the workflow Bex.co is built for: push a git repo, get a running HTTPS service on your own hardware — no per-seat anything. Star the repo on GitHub or deploy your first app today.
