Podman 6.0: What's New, Release History & Support Lifecycle

What Is New in Podman 6.0

What platforms and features have been removed in Podman 6.0?

Podman 6.0 drops support for Intel-based Macs, Windows 10, cgroups v1 systems, iptables-based networking, CNI plugin architecture, and the slirp4netms rootless network stack. In practice, these removals reflect the consolidation toward modern Linux infrastructure. If your deployment still relies on cgroups v1, you must upgrade your kernel and userspace tools before moving to Podman 6.0. Windows users need Windows 11 or later. The shift to nftables and Netavark represents a significant architectural cleanup -- watch out for any custom networking configuration that depends on iptables hooks.

Intel Mac users will need to stay on Podman 5.x or switch to native Docker Desktop. The decision to drop Intel Mac support aligns with Apple's own direction but represents a breaking change for teams still on Intel hardware. Most enterprise deployments are already on newer architectures, but verify your developer machines and CI/CD infrastructure before upgrading.

How does Podman 6.0 improve machine virtualization and multi-provider support?

Podman 6.0 fundamentally redesigns machine management to operate transparently across providers. Previously, switching between applehv and libkrun on Mac (or hyperv and wsl on Windows) required explicit provider switching. Now all podman machine commands work with any VM from any provider in a single command line. The default provider controls which backend is used for newly-created VMs, but can be overridden per-command with --provider. This matters if your team uses a mix of virtualization backends or if you want to test Podman behavior on different hypervisors without complex tooling.

The new podman machine os update command allows in-place OS updates without destroying and recreating VMs -- a significant operational improvement for stateful machines. Windows administrators benefit from the new podman system hyperv-prep command, which configures host prerequisites for hyperv-based machines without manual setup. VM boot-time CA certificate importing via --import-native-ca ensures containers inherit the host's trusted root store, reducing friction in enterprise environments with internal PKI.

On Linux, host user configurations are now automatically mounted into machines at /etc/containers, allowing you to edit container runtime configuration directly instead of rebuilding the VM. The downside: existing Linux machines have broken volume mounts after upgrade and require recreation. Most teams should script VM deletion and re-initialization as part of the upgrade process.

What changes in Quadlet design and configuration?

Quadlet's architecture has been redesigned to replace the .app file-based tracking system with subdirectory-based organization. Previously, removing a Quadlet required careful management of associated files because the manifest was stored centrally in a single .app file. In Podman 6.0, each Quadlet and its associated files live in a subdirectory, making manual operations and version control much cleaner. This change reduces bugs related to orphaned files and makes Quadlet management more transparent when using podman quadlet install.

Volume configuration has been significantly enhanced. Quadlet .volume units now support UID=, GID=, and Options= keys, allowing fine-grained ownership and capability control without external scripts. Container units can now mount anonymous volumes using Mount= with no source, simplifying temporary storage patterns. Two new search paths have been added -- /usr/share/containers/systemd/users and /usr/share/containers/systemd/users/${UID} -- allowing distributions to package system and user-level Quadlets separately.

The command line interface expanded with podman quadlet ls as an alias for podman quadlet list, plus --noheading and status= filter options for scripting. Most significantly, podman quadlet list now includes pod membership information, making it easier to understand service dependencies when containers are organized into pods.

How does networking improve in Podman 6.0?

Network isolation now defaults to enabled, improving Docker compatibility while increasing security posture. A workaround for the Docker-compatible API related to disabled isolation has been removed, so any custom integration code relying on that behavior will break. The change is correct but requires audit of deployments using the Compat API with explicit isolation=false expectations.

Containers can now bind multiple static IP addresses in the same network via repeated ip= options: podman run --net mynet:ip=10.0.0.2,ip=10.0.0.3,ip=10.0.0.4. Network route types have been expanded to include blackhole, unreachable, and prohibit routes via podman network create --route 10.20.30.40/24,blackhole, enabling complex routing policies and access control directly within Podman networks without external tooling.

For rootless deployments, an experimental pasta backend for port forwarding preserves client source IP in network traffic, solving a longstanding limitation where rootless port forwarding obscured the client identity. This is available via rootless_port_forwarder="pasta" in containers.conf. An experimental feature using nsfs file handles (Kernel 6.18+) eliminates the need for the pause process entirely, reducing resource overhead and simplifying rootless architecture, though this is currently gated behind an environment variable.

What container management and API improvements should operators know about?

Container creation and management have been refined for production use. The podman exec --no-session option disables API session tracking and database operations, improving performance when session overhead is unwanted. The new nocreate volume mount option allows containers to reference volumes that must already exist -- podman run --mount type=volume,src=myvol,dst=/mnt,nocreate -- preventing accidental volume creation when strict infrastructure-as-code is required.

podman commit now pauses containers during the commit operation, preventing concurrent modifications that could produce inconsistent images. The prior non-pausing behavior can be restored with --pause=false if needed. Container output format has been refined: podman image list --format json now includes Repository and Tag fields for easier tooling integration.

The Docker Compatible API has been bumped to v1.44, with numerous endpoint improvements. The Compat List endpoint for Containers now includes health status, the Compat Create endpoint better handles CDI device qualification, and error responses are more correct. The Libpod Pull endpoint can now report progress and returns proper error codes on failure instead of always returning HTTP 200. All API endpoints now handle empty JSON body parameters gracefully instead of erroring.