What if you could try an application without installing its database, web server, and language runtimes directly on your Windows PC?
Containers make that possible for many workloads. An image packages an application and its user-space dependencies, while the container runtime provides the environment in which it runs. External services, persistent data, and security settings still need deliberate configuration.
On September 29, 2026, Microsoft announced the general availability of WSL containers. Windows users have a WSL-native way to build and run Linux containers without installing Docker Engine or Docker Desktop for these workflows.
I have been building WSL Container Desktop to make that experience more approachable. It is a native WinUI 3 application for managing containers, images, storage, and networks. It is my independent community project, not a Microsoft product, and is not affiliated with, endorsed by, or supported by Microsoft.
What Went GA
There are three distinct layers: Microsoft’s WSL containers engine, the community desktop application, and the software you choose to run inside containers. Their support arrangements and prerequisites are not interchangeable.
Microsoft’s announcement identifies the wslc.exe CLI, its built-in container.exe alias, and an API for native Windows applications. GA capabilities include container restart, file copying, environment information, live events, health checks, network attachment and detachment, and configurable storage placement.
Microsoft’s architecture deep dive, published September 29, describes session operations running in a less-privileged per-user process. Its Consomme networking model routes traffic through a Windows process acting for that user, improving compatibility with VPNs and firewalls. Compatibility is not a reason to skip testing your organization’s network controls.
The GA announcement also lists WSL Container Desktop among community integrations, alongside integrations with tools such as VS Code and Aspire. That recognition is not a Microsoft product endorsement.
Start With the Right Prerequisites
The community project’s documentation requires WSL 3.0.1 or later. On a PC where WSL is already installed, check its version from PowerShell:
| |
If an update is needed and your organization permits it, run the following from an elevated PowerShell window, then check the version again:
| |
These commands are documented in Microsoft’s WSL command reference. Managed-device users should follow their IT team’s update process rather than bypass policy.
As of October 2, 2026, the project’s latest release is 2.0.1, published October 1. Its installation instructions use a sideloaded package and a self-signed publisher certificate. Obtain organizational approval before trusting that certificate or installing the application.
WSL containers do not require you to install a separate Linux distribution. The app’s optional Kubernetes feature is different: its single-node k3s installation requires a suitable WSL 2 distribution with systemd. That feature is not needed for the examples below.
Container Images Still Matter
Not requiring Docker Desktop does not mean abandoning images and registries. Docker Hub is a registry, distinct from the Docker Desktop application. Images, applications, and registries retain their own licensing, authentication, and usage terms.
Do not assume that every existing image, command, integration, or Compose project works unchanged. Choose supported workloads and review compatibility before deployment. For repeatable workshops and development, record the image versions you use and prefer immutable image digests where supported; a floating tag does not identify permanent image contents.
What the Desktop Application Adds
The capabilities below come from the community project’s README, not from a Microsoft support commitment.
| Need | Documented app capability |
|---|---|
| Start a useful workload | A templates gallery containing databases, developer environments, Azure emulators, and multi-service stacks. |
| Find an application’s address | An Endpoints dashboard showing published ports and convenient localhost links. |
| Understand a failure | Container status, streaming logs, terminal access, CPU and memory metrics, and an activity feed. |
| Prepare an image for sharing | Build, tag, and push workflows. |
| Retain application data | Volume management, with backup remaining a separate responsibility. |
| Reclaim disk space | A cleanup view showing resource usage and asking for confirmation before pruning. |
The app can manage public and private registries. Its Add from Azure workflow requires the Azure CLI and uses your Azure identity to access Azure Container Registry; you still need the appropriate registry permissions.
An optional AI assistant is off by default. Review its provider, permissions, and data-sharing behavior before enabling it. Masking recognized secrets is not a guarantee that logs or configuration contain no sensitive information.
Useful Scenarios for Developers
A database for each project. The gallery offers database templates, and repeated deployments receive separate names, ports, and volumes. Use disposable sample data when exploring schema changes or upgrades. A separate deployment helps organize work, but it does not replace access controls or backups.
A repeatable development environment. The project’s developer sandbox templates provide toolchains and persistent workspace storage. Keep source code under version control and document dependencies so that another developer can reproduce the environment.
Local Azure-service development. The app lists templates for Azurite, Azure Cosmos DB, Service Bus, and Event Hubs emulators. These are development aids, not complete copies of the cloud services. Azurite supports Blob, Queue, and Table storage, with Table support still in preview. It does not support Azure Files or Data Lake Storage Gen2 and provides no performance guarantee.
Persistence also differs by emulator. Microsoft’s Service Bus and Event Hubs documentation warns that data and entities do not persist after a container restart. A volume alone cannot override an application’s documented behavior.
A complete stack for debugging. Import a supported Compose project, review the app’s compatibility assessment, inspect logs, and manage related services together. The project documents its own orchestration layer; it is not a drop-in replacement for Docker Compose. Microsoft’s September announcement describes native Compose support as roadmap work, not a shipped GA capability.
Build locally, publish when ready. The app can build and push images to a registry such as Azure Container Registry. Test again in the intended Azure deployment environment before treating a local result as production-ready.
Useful Scenarios Beyond Development
A practice website. The project’s WordPress + MySQL template provides a place to draft pages or learn the editor without changing a live site. Treat it as a learning environment, not production hosting. Review credentials and network exposure before starting it.
A local AI learning environment. The project’s Open WebUI + Ollama template combines a browser interface with a model runtime. Open WebUI’s documentation supports local and hosted providers, and Ollama’s FAQ distinguishes local inference from cloud-hosted models. Select a genuinely local model and endpoint, and disable external integrations when local-only processing is required. Initial downloads require connectivity, and hardware needs depend on the model.
A database learning lab. The PostgreSQL + pgAdmin template combines a database with browser-based administration. Use synthetic data for SQL practice and destructive experiments, not copies of sensitive agency records.
A repeatable workshop. Prepare approved images in advance, record their versions, and preserve learners’ work outside disposable container layers. Test the complete exercise offline if connectivity will be limited; downloading images in advance does not eliminate every application dependency.
Two Short Walkthroughs
These flows use the app’s documented template interface. Review configuration before deployment rather than assuming the default settings fit your environment.
Developer: PostgreSQL + pgAdmin
- Confirm the WSL prerequisite and open the approved desktop application.
- In Templates, open Settings for PostgreSQL + pgAdmin. Review credentials, published ports, and storage, then inspect the Compose compatibility review before approving deployment.
- Find the services in Containers and open pgAdmin from Endpoints. Sign in with the configured pgAdmin credentials and use the database connection details from your template configuration.
- Inspect logs or resource usage while working with sample data. When finished, use the containers’ Stop action if you intend to retain them.
Non-developer: WordPress practice site
- Open Settings for WordPress + MySQL and review credentials, storage, port bindings, and the compatibility result before deploying.
- Open the WordPress endpoint, complete its initial setup, and draft a sample page.
- Stop the containers when finished if you plan to return to them. Back up anything you want to keep before cleanup.
Do not confuse Stop, Down, and Remove. The project’s README says Compose Down removes containers and networks but preserves volumes. Compose Remove additionally deletes project-created volumes. Removing a container also discards its writable layer. Read the actual confirmation before approving any cleanup operation.
Why This Matters for Government
State and local agencies can use disposable environments for staff training, application modernization, and Azure-service development without making every experiment a shared deployment. Budget planning should still account for endpoint capacity, image maintenance, security administration, and support ownership.
Microsoft’s GA announcement describes Intune controls for allowing WSL containers and restricting image pulls to approved registries. According to the community project’s documentation, its app respects those policies and disables image builds when a registry allow list is active. An approved registry is not proof that every image in it is trustworthy.
The Microsoft Defender for Endpoint WSL plug-in documentation supports container visibility, but specifies Defender for Endpoint Plan 2, host onboarding, and plug-in prerequisites. It excludes ARM64 and multi-session Windows devices. Its WSL visibility is not equivalent to every Defender protection or response capability. Administrators should validate the supported configuration and resulting telemetry before relying on it.
Use NIST SP 800-190, Application Container Security Guide, to inform risk review. Neither general availability nor local execution demonstrates CJIS, IRS Publication 1075, or HIPAA compliance. Obtain the appropriate agency approval before introducing regulated data.
Start With One Approved Workload
Choose a database lab, a practice website, or an AI experiment using synthetic data. Limit mounted folders and published ports, review image provenance, and plan backups. A localhost link does not prove that a service is inaccessible from other machines.
Keep the desktop application running if you rely on its app-owned restart supervision or auto-heal. Those features are not an unattended hosting service.
WSL containers provides the engine. WSL Container Desktop is my community contribution toward making it easier to see and manage. Explore the project through the repository linked above, and report engine issues to Microsoft’s WSL repository.