Podman 6.0 removes legacy hosts, databases, and network stacks

Podman released version 6.0 on June 24 with a long list of compatibility breaks and new machine, network, volume, and Quadlet behavior. The signed release record makes this a migration release: it removes BoltDB, cgroups v1, CNI, iptables, slirp4netns, Intel Mac, and Windows 10 support.

The supported platform becomes narrower

A Podman 6 host must use cgroups v2, Netavark, nftables, and Pasta in place of the retired paths. Existing BoltDB databases trigger an automatic migration to SQLite at startup, but operators should still back up state and exercise that conversion on a copy before upgrading a long-lived host. The release also requires matching versions of Buildah, Skopeo, Netavark, Aardvark, and containers/common, which makes partial package upgrades risky.

The Go module moved to go.podman.io/podman/v6. Applications embedding Podman or its REST bindings need to compile against the new import path and review API changes rather than treating the engine binary as the only upgrade surface.

Machine and cleanup workflows gain controls

All podman machine commands can now operate across configured providers, and a new OS update command covers supported virtual machines. Hosts can import native certificate authorities into machines at boot. Volume pruning now follows Docker’s anonymous-volume default, with --all for the older broad behavior and --dry-run to preview deletion.

Before rollout, inventory hosts for every removed component, test database migration and rollback, and run representative networking and Quadlet workloads. Confirm automation does not assume the former pruning semantics. Podman 6.0 modernizes its baseline, but the release notes make clear that a successful upgrade is a coordinated host, dependency, and client migration.