Windows has been my primary workstation for years. I bounce around Linux and macOS from time to time, but I always come back to my comfort zone, Windows. Docker Desktop has been my default container solution on Windows. As an indie developer, my workflow is very trusting Docker Compose stacks. I keep myself up to date with WSL development and it has made Linux development on Windows much easier. Docker Desktop, though, hasn’t changed. Microsoft’s new WSL Containers feature, Announced at Build 2026aims to blur the line between the two. With the new wslc command, I won’t have to rely on a separate program to burn the container.
Feature not yet shipped; A public preview is expected later this month, so this isn’t a hands-on experience.
I never chose Docker Desktop
I’ve been building and shipping apps for a long time now. From no container to single container and then multi-container projects, it’s been a journey. me first started using the dishes as projects became more complex – databases, APIs, Redis and supporting services became commonplace. And it slowly became the easiest way to create reproducible development environments. I haven’t followed the trend of Docker adoption. It was a really reliable way to manage dependencies in my projects, so it became part of my daily workflow without me deciding.
Managing Docker Desktop was the easiest way to manage multi-container projects, so it became an integral part of my development toolkit. After Microsoft open source last year Windows Subsystem for Linux (WSL) In Build 2025, I looked into running Docker within WSL, but Docker Desktop was still easy. With a good GUI, simple setup, a default tutorial program, and a larger community, Docker Desktop felt like the best fit at the time. Docker Desktop was not something I carefully chose after evaluating the alternatives. It was simply the best solution for me.
Docker Desktop became part of my installation on each machine. I bought a new car. I installed Windows, followed by VS Code, Termius, Git, and Docker Desktop. In an instant it became automatic. I wasn’t asking myself if I needed Docker Desktop, but when I should install it. Well, Docker Desktop was working fine. Most of my workflow was based on the Compose stack, multiple services talking to each other, and Docker Desktop handled that pretty well. But at the same time, it was another setup, another update cycle, and another layer sitting between the containers and the host.
Over the years, Microsoft has invested heavily in WSL, which has greatly improved Linux development on Windows. But when it came to container workflow, it was exactly the same as before. I was still addicted to the Compose stacks. Even after WSL became a capable Linux environment, Docker Desktop still felt like something I couldn’t replace. Overall, WSL was headed for a brighter future, but it still couldn’t touch my dependence on Docker Desktop.
WSL containers may eventually change that – but not yet
I am excited. I’m not uninstalling Docker Desktop yet.
This year’s Build 2026 was full of surprises, both good and weird. Coreutils for Windows and WSL containers were among the original highlights. I still don’t understand why I want my terminal to be smart – I prefer simplicity myself, doing exactly what I want. Yes, that’s a fight for a different article. Going back to the WSL announcement, the new wslc (WSL Container) command looks like something we’ve been waiting for a long time. Not a separate desktop program, but a simple, OCI-compliant command shipped via WSL updates – this is the best package.
As soon as I heard about it, it immediately caught my attention. Why, you ask? Today, I already rely on WSL for my workflow indirectly through Docker Desktop. Behind the scenes, Docker Desktop already relies heavily on WSL. I use WSL implicitly every time Docker Desktop starts a container. With WSL Containers, Microsoft wants to cut out the middleman and become the container platform itself. And for the first time I think I can connect directly to WSL instead of sitting under Docker Desktop.
I don’t need the full Compose stack when developing all my projects. For example, in some of my projects I run a frontend and sometimes even a backend for direct reloading, and the only thing Docker does is spin PostgreSQL. For a project like this where I only need one container, Docker Desktop is more difficult to install and maintain. In this use case WSL Containers look really attractive and It can completely replace Docker Desktop.
But for more complex projects where the dependencies are not only PostgreSQL, but also backend, Redis and other supporting services, and they need to communicate via the Compose network, I can’t get ahead with just one container. These projects aren’t just “run a container and forget it” workloads. In this use case I would still go with Docker Desktop.
WSL Containers do not support the Compose stack and it does not yet have a mature ecosystem. Well, it’s too early to judge; this was just an announcement and the real use case will appear once it gets into the hands of developers. Another reason to work with Docker Desktop is the GUI. For a multi-container project, I would still prefer a UI to interact with.
Again, I’m excited about WSL containers. Microsoft brings containers closer to the operating system with fewer dependencies and simple additions; A more direct path to containers from Windows. But one thing I know for sure: for many developers, Docker Desktop may be more of a choice than a requirement.
It is not a substitute. Not yet, anyway.
This wasn’t a Docker Desktop replacement story. At least not yet. For workflows that require composition, Docker Desktop will still be an easy call. Microsoft’s announcement of WSL Containers bridges the gap between hosts and containers by turning WSL into a container platform. It’s interesting, but I won’t be uninstalling Docker Desktop anytime soon. WSL has evolved from a compatibility layer to a development platform, and containers feel like the logical next step. I look forward to trying it when it arrives.
