Learn Podman - Modern Features & Roadmap

#Introduction

In episode 20 you built the observability and operations foundation: stats, events, healthchecks, and troubleshooting. Episode 21 looks ahead: what the modern Podman releases bring, and where this project is heading. You won't just know how to use Podman today, but also where Podman is going — important for future adoption and upgrade decisions.

#Podman 6.0 (June 2026)

Podman 6.0 is the major release shipped in June 2026. Many changes from 5.x affect how configuration, systemd units, and networking work.

#Config File Rework

One of the biggest changes is the configuration file rework. Previously configuration was spread across several files: containers.conf, registries.conf, storage.conf, and policy.json. In Podman 6.0, this configuration is tidied into a more unified whole, and per-user settings are honored via XDG_CONFIG_HOME — user configuration is stored in the XDG-standard directory, not scattered in ad hoc places.

For those of you with custom configuration from older versions, this means there may be files that need migration or adjustment. This is the main reason why reading the release notes before upgrading is strongly recommended:

podman version
podman info

#Quadlet Overhaul

Quadlet — the way to declare containers, pods, and volumes as systemd units — received a major refresh. Better unit generation, more supported directives, and improved integration with machine features. For those who followed episode 17 on systemd integration, the new Quadlet means cleaner generated units with less manual adjustment needed.

#Machine Improvements

Podman Machine was also improved: smoother VM image updates, better provider support on macOS (Apple Virtualization) and Windows (WSL2), and cleaner handling when a VM must be reset or upgraded. The laptop user experience now approaches the Linux server experience.

#Docker API Parity

Docker API parity is a major focus: the podman system service endpoints align ever more closely with the Docker Engine API. The goal is clear — tooling written for Docker (like Docker Compose, GUIs, and automation scripts) can run on top of Podman without changes. This is Podman's long-term strategy to stay compatible while remaining daemonless.

#Netavark and aardvark-dns v2

Podman's modern networking stack — netavark (network configuration) and aardvark-dns (per-pod DNS) — ships as a rebuilt v2. Improvements include better firewall handling and more consistent support for rootless networking, including the direction toward more solid IPv6. Because networking is a highly sensitive layer, make sure your netavark and aardvark-dns versions match Podman 6.0.

#Volume and Container Handling

Volume and container handling was also refined: more consistent volume ownership, more predictable lifecycle when containers are stopped or removed, and safer behavior on operations that previously could "silently fail". Small changes like these are usually the most noticeable in production.

#Legacy Platforms Dropped

Alongside a major release, legacy platforms are dropped. This means support for certain operating systems or architectures ends, and deprecated flags/APIs are removed. For a safe upgrade, first check the list of no-longer-supported platforms and make sure your systems are among those still maintained.

#Podman 6.1

The 6.1 maintenance release adds several practical, long-awaited capabilities:

• podman volume rename — rename a volume without recreating it, very helpful when naming standards change.
• Machine restart — a restart command for Podman Machine that simplifies the VM lifecycle.
• Rootless IPv6 forwarding — IPv6 forwarding support in rootless mode, closing the gap that previously limited IPv6 deployments for rootless users.
• Safer network and manifest commands — operations like podman network and podman manifest are made harder to trigger by mistake, reducing incidents caused by configuration errors.

podman volume rename mydb-data db-prod
podman machine restart

The first line renames a volume without losing data; the second restarts the machine VM — two small examples that immediately improve day-to-day work. The main focus of podman volume rename is keeping data intact, so volumes bound to a Quadlet unit or image references stay valid after the naming is updated.

#Roadmap

Beyond releases, the project's long-term direction is also worth watching because it affects adoption choices.

#Toward CNCF Incubation

Podman was accepted as a CNCF project, and the next direction is incubation. CNCF status means more mature governance, a broader community, and long-term assurance for organizations using Podman in production.

#composefs

composefs — a filesystem storage for images that enables cross-container deduplication and strong content verification — continues to be pushed toward default use. When complete, OCI images can be shared at the filesystem level, saving significant disk space and speeding up container startup.

#zstd:chunked Partial Pull

Partial pull with zstd:chunked (learned in episode 18) is expected to become the default experience: only changed chunks are downloaded when an image is updated. The combination of composefs and partial pull is the two biggest planned efficiency changes.

#BuildKit API Support

Finally, there's an effort toward BuildKit API support — the modern Docker build protocol used by Docker Buildx. This opens up the possibility of using BuildKit tooling to build images on top of Podman, expanding the CI/CD pipeline choices that can run on the Podman ecosystem.

#Summary of Modern Features

#Closing

In episode 21 you understood Podman's modern direction: config file rework, Quadlet overhaul, machine improvements, Docker API parity, netavark/aardvark-dns v2, and legacy platform drops in 6.0; the practical capabilities of 6.1 like podman volume rename, machine restart, rootless IPv6 forwarding, and safer network/manifest commands; plus the roadmap toward CNCF incubation, composefs, zstd:chunked partial pull, and BuildKit API support.

The key points to take home:

• Podman 6.0 changes the configuration foundation — check the release notes before upgrading, especially regarding config and networking.
• Docker API parity is the long-term strategy — compatibility without sacrificing daemonless.
• 6.1 is the practical release — volume rename, machine restart, and rootless IPv6 are immediately useful in production.
• The roadmap centers on efficiency — composefs, partial pull, and the BuildKit API shape the next adoption direction.

In Episode 22 — the final episode of this series — we do a thorough reflection: Ecosystem, Alternatives & Final Reflections — comparing Podman with Docker Engine, containerd, and Kubernetes/CRI-O, determining when to choose Podman, summarizing the entire journey from episode 0 to 21, and closing with a production checklist.