By Podman 6.0 is landing this week, and it removes three things your containers might still depend on. slirp4netns is gone. cgroups v1 support is gone. BoltDB is gone. If you’ve been running Podman since the 4.x era without touching your configuration, one of those removals is probably a problem for you. Here’s exactly what changed, who gets hit, and the safe upgrade sequence.
Three Things That No Longer Exist in Podman 6
This isn’t a list of deprecated warnings that still limp along — these subsystems have been physically removed from the codebase. Podman 6 will refuse to use them. Here’s the quick rundown before the details:
- slirp4netns — the legacy rootless networking backend, replaced by Pasta in Podman 5.0
- cgroups v1 — all cgroups v1 code paths and tests are gone; cgroups v2 is now required
- BoltDB — the embedded key-value database tracking container state, replaced by SQLite since Podman 4.8
The first two you’ve probably anticipated. The third one is the quiet killer.
BoltDB: The Breaking Change That Bites Without Warning
If you installed Podman before version 4.8 and never ran a database migration, you’re still on BoltDB. Podman has been warning about this for a while — but not loudly enough. When you upgrade to 6.0 on a system still running BoltDB, Podman 6 simply cannot read that database. Your containers appear to not exist. They’re still on disk. Podman just doesn’t know about them anymore.
The safe path runs through Podman 5.8. Upgrade to 5.8 first, then reboot — Podman 5.8 introduced automatic BoltDB-to-SQLite migration that runs at boot time. One reboot and it’s done.
# Verify your database backend before upgrading
podman info --format '{{.Host.DatabaseBackend}}'
# Should return: sqlite
# If automatic migration did not run, force it manually
podman system migrate --migrate-dbDo not skip 5.8 and jump directly from an older version to 6.0. That path loses your container state. Back up your container configs before any major Podman upgrade — a podman inspect dump for your important containers costs nothing.
slirp4netns: Check Your CI Scripts and Compose Files
If you’ve never explicitly set --network=slirp4netns in a podman run command, a Containerfile, or a compose override, you’re probably fine. Pasta has been the default rootless networking backend since Podman 5.0.
The danger lives in scripts, GitLab CI configurations, and older Quadlet files that hardcoded slirp4netns for reproducibility. Those will now throw an unknown network mode error. Grep your repo:
grep -r "slirp4netns" . # Find any hardcoded referencesRemove those references and install passt if it’s not already on your system:
sudo dnf install passt -y # Fedora / RHEL
sudo apt install passt -y # Debian / Ubuntu
sudo pacman -S passt # ArchPasta is an improvement in real terms. No NAT by default means source IPs are preserved through port forwarding — something slirp4netns couldn’t do cleanly. Native IPv6 also works without hacks.
nftables Is Now Mandatory for Root-Mode Networking
Netavark, Podman’s container networking library for root-mode containers, drops its iptables backend entirely in Podman 6. nftables has been the Fedora default since Fedora 41 and is standard across modern distributions, but if you’re on an older host, verify nftables is available:
nft list tables # Should not errorIf your host firewall uses iptables rules that interact with container network traffic, those rules will need updating. This is the most infrastructure-specific change in Podman 6.
cgroups v1 removal works similarly: it affects a narrow slice of users on genuinely old systems. Check which generation you’re on:
cat /sys/fs/cgroup/cgroup.controllers # File exists = cgroups v2If you’re on cgroups v1 and can’t upgrade the kernel, Podman 6 is not an option. Stay on 5.8 until your infrastructure catches up.
The Safe Upgrade Sequence
Follow this sequence to avoid data loss and network errors. The official Fedora change documentation covers the full technical rationale for each step.
- Check your version:
podman --version - If below 5.8: upgrade to 5.8 first via your package manager
- Stop all containers:
podman stop --all - Reboot the system (triggers automatic BoltDB to SQLite migration)
- Confirm:
podman info --format '{{.Host.DatabaseBackend}}'returns sqlite - Audit scripts for slirp4netns references and remove them
- Verify nftables and cgroups v2 are available on your host
- Upgrade to Podman 6 via your package manager
- Run a test container with a port mapping to confirm networking works
Who Should Wait
For developers on modern Linux running Podman 5.x with default settings, the upgrade should be smooth — most breaking changes were already the default behavior in 5.x. The risky path is upgrading a production system that hasn’t been touched since Podman was first installed years ago.
If you manage container infrastructure for a team, run the checklist above on a staging machine first. Most footguns in this release are well-documented, and Podman’s team added migration tooling specifically to catch common failure cases. The podman system migrate command is your safety net — use it before the upgrade, not after things break.
