Podman 6.0: Breaking Changes to Audit Before You Upgrade

Podman 6.0 landed June 24, and if your pipeline or distro is already shipping it, you have five breaking changes to audit before you run that upgrade. The short version: cgroups v1 is gone, iptables is dead, CNI support is removed, slirp4netns is history, and BoltDB will leave your container state unreadable if you skip a single migration step. The new features are legitimate—AMD GPU support, improved Docker API compatibility, experimental Pesto rootless port forwarding—but none of that matters if your containers lose network connectivity the moment you upgrade.

The Breaking Changes, Ranked by How Much They Will Hurt You

1. CNI Removal: The Silent Network Killer

This is the one that will catch teams off guard. CNI networking is gone. Netavark is now the only supported backend. The dangerous part: Podman does not error out if it finds old CNI configuration files. It silently ignores them. Your containers start, appear healthy, and have no network connectivity. No error message. No warning.

Before upgrading, run podman system migrate and podman network migrate to convert your CNI network definitions to Netavark YAML. If you skip this on a production host, you will be debugging network failures with no obvious cause.

2. BoltDB Is Gone—Upgrade to 5.8 First

BoltDB is completely removed. SQLite is the only database backend in Podman 6. If you upgrade directly from Podman 5.x below 5.8 while still on BoltDB, your entire container state—images, volumes, running containers—becomes unreadable.

The safe path: upgrade to Podman 5.8 first, reboot, let the automatic BoltDB-to-SQLite migration run, then upgrade to 6.0. Before you do anything, verify your current backend:

podman info --format '{{.Host.DatabaseBackend}}'

If that returns sqlite, you are ready. If it returns boltdb, stop and upgrade to 5.8 first.

3. cgroups v1 and iptables: A Two-Part System Check

Podman 6 will not start at all on a cgroups v1 system. Additionally, the Netavark networking library has dropped its iptables backend entirely in favor of nftables. These are two separate issues that often hit together on older hosts.

Check your cgroups version:

cat /sys/fs/cgroup/cgroup.controllers

If that file exists and returns controller names, you are on cgroups v2. If the file does not exist, you are on v1 and Podman 6 will refuse to run. For iptables, audit any custom firewall rules or tooling that inspects container network traffic—those integrations stop working without any graceful fallback.

4. slirp4netns: Check Your Scripts and Quadlet Files

slirp4netns is gone. Pasta is now the default rootless networking stack. For most users this change is invisible—Pasta just works. But if you have Quadlet unit files, Compose configurations, or CI scripts that hardcode --network=slirp4netns, those will throw unknown network mode errors after the upgrade.

Search your repository and CI configurations for any slirp4netns references and remove them. Pasta handles the same use cases with better performance and no extra configuration needed.

The Safe Upgrade Order

Do not just run dnf upgrade podman and hope for the best. Follow this sequence:

1. Confirm cgroups v2 is active: cat /sys/fs/cgroup/cgroup.controllers
2. Check database backend: podman info --format '{{.Host.DatabaseBackend}}'
3. If on BoltDB, upgrade to Podman 5.8 and reboot first
4. Run podman system migrate to migrate container state
5. Run podman network migrate to convert CNI networks to Netavark
6. Audit scripts, Quadlets, and CI configs for slirp4netns references
7. Review custom iptables rules for container network interaction
8. Recreate Podman Machine VMs if on Linux or macOS (systemd volume changes require it)
9. Upgrade to Podman 6.0

macOS users get an additional note: Intel Mac support is dropped. If you are still on Intel, Podman 6 is not available to you. Apple Silicon users get libkrun as the new default VM provider.

What’s Actually New

The breaking changes dominate the conversation, but Podman 6.0 delivers real improvements worth the migration effort.

AMD GPU support is the headline new feature. The --gpus flag now works with AMD graphics processors in podman run and podman create. For teams running containerized AI inference on AMD silicon, this is significant—rootless containers with GPU access without the NVIDIA-only dependency. Red Hat has a configuration guide for AMD GPU access on RHEL that covers the device passthrough setup.

Pesto rootless port forwarding (experimental) solves a persistent problem with rootless containers obscuring client IP addresses in logs. Enable it by setting rootless_port_forwarder="pasta" in the [network] section of containers.conf.

Multiple static IP addresses per container are now supported, along with blackhole routes to block container access to specific networks—both useful for multi-network setups that were previously awkward to configure.

Docker API compatibility has improved, reducing friction between Compose files and Podman’s Docker-compat layer. The AlternativeTo coverage of the Quadlet evolution is worth reading if you use systemd-integrated container management.

The Bottom Line

Podman 6 is a generational cleanup. Dropping cgroups v1, iptables, CNI, slirp4netns, and BoltDB in a single major version is aggressive—but these were all deprecated components that should have been removed years ago. The team is making the right call. The problem is that major version releases in container runtimes have a way of quietly wrecking pipelines when teams do not read the release notes carefully.

Read them. Run the migration commands before upgrading. Check the official Podman 6.0 release notes for the full dependency version matrix—Buildah 1.44, Skopeo 1.23, Netavark/Aardvark 2.0 must all be upgraded in sync. And if you want a broader picture of where Podman sits in the container runtime landscape today, the LWN.net coverage of the release is a solid read.