Podman 6's machine work targets the VM friction behind Docker Desktop alternatives
The October 2025 change makes the CLI see machines across WSL, QEMU, libkrun and AppleHV instead of trapping users in provider state.
By Ryan Merket ยท Published
Why it matters
Podman's machine-provider cleanup shows where developer-tool alternatives win or lose: not only on architecture, but on whether desktop and CLI workflows share the same reality.
Brent Baude laid out a Podman 6 change on October 31, 2025 that makes Podman machine behave less like a provider switchboard and more like the container runtime developers expect when they move between desktop and terminal workflows.
In the Podman blog post, Baude described a specific failure mode in Podman 5: Podman Desktop could create or run a Linux VM under one machine provider, while the Podman CLI looked only at the default provider configured in ~/.config/containers/containers.conf. The result was a machine that existed and could be running, but that the CLI still reported as missing when a user tried to stop it by name.
That is the kind of edge case that matters for Podman because Podman is not just another container CLI. It is a Red Hat-created open source project positioned as a daemonless, rootless-capable, OCI-compatible alternative in a Docker-shaped world, with support for legacy Docker containers, docker-compose files and Kubernetes-oriented workflows. On Linux, that pitch can stay close to the metal. On macOS and Windows, it depends on a Linux virtual machine, which means the quality of the abstraction determines whether Podman feels like a Docker Desktop substitute or a system integration chore.
The old problem was provider leakage
Podman machine is built around providers, Baude wrote. In the post's table, Windows supports WSL and HyperV, Linux supports QEMU, and macOS supports libkrun and AppleHV. The defaults also shift in Podman 6: WSL on Windows, QEMU on Linux and libkrun on macOS, while AppleHV is marked as the Podman 5 default for macOS.
In Podman 5, the default provider was hardcoded in the Podman binary, though users could override it in containers.conf. Baude's example sets libkrun as the default provider while an applehv machine is already running. podman machine ls --all-providers can show both the AppleHV machine and the default libkrun machine. But podman machine stop applehv-machine-1 fails with an error saying the VM does not exist.
That is not a theoretical polish issue. Podman Desktop and the CLI serve different parts of the same workflow. If the GUI can create state that the CLI cannot see without an extra provider-wide flag, the abstraction has already broken. The user is forced to learn Podman's provider model at the moment the tool should be making Linux VM plumbing disappear.
Podman 6 makes provider state less visible
Baude said Podman 6 is making an "overt push" to reduce the prominence of the provider concept. For commands such as rm, stop and start, the intended behavior is that a user supplies the machine name and Podman acts regardless of the provider. His post shows this in podman version 6.0.0-dev, where stopping applehv-machine-1 succeeds even though the example default provider remains libkrun.
Podman 6 also changes discovery. Baude wrote that --all-providers has been removed from the machine command because podman machine ls now shows machines across all supported providers by default. That is a small CLI change with a clear product judgment behind it: a provider is implementation detail until the user explicitly chooses to care about it.
The second related change is creation. Podman 6 adds a --provider flag to podman machine init, letting users create a machine in a non-default provider without changing global configuration. In Baude's example, podman machine init --now --provider applehv applehv-machine-2 creates and starts an AppleHV-backed VM while libkrun remains the default.
The work was still development-branch work when Baude published the post. He noted that Podman's upstream repository had switched over to Podman 6 development, and the example version string is 6.0.0-dev. The Podman site later listed a May 2026 post titled "Podman 6 Release Delayed", so the October post should be read as a product-direction marker, not proof of a final stable release or an unchanged shipping surface.
The competitive read is Docker Desktop, not just CLI cleanup
The change sits inside Podman's broader attempt to make Docker-compatible local development feel native without requiring Docker itself. Podman's homepage emphasizes Docker compatibility, Kubernetes readiness, rootless containers and Podman Desktop as a tool for managing containers across engines, even when Podman is not the engine.
That positioning creates a high bar for desktop usability. Developers evaluating a Docker Desktop alternative will tolerate a different architecture. They are less likely to tolerate a workflow where the desktop app and terminal disagree about whether a VM exists.
Baude's provider changes do not add a new runtime, a new packaging model or an adoption metric. They remove a place where Podman's internals leaked into daily use. For an open source infrastructure project competing on trust, security posture and compatibility rather than venture-funded distribution, that kind of repair is product strategy: fewer concepts at the boundary, fewer traps for users moving between GUI and CLI, and a better chance that Podman Desktop feels like one surface rather than two tools sharing a name.