Podman 6.0 has landed, and it aggressively clears the field of aging Linux container infrastructure. The open-source container engine now refuses to run on systems limited to cgroups v1, drops its iptables-based rootless networking in favor of the newer netavark and pasta combo, and removes the Container Network Interface (CNI) plugins that many organizations still rely on. For Windows users running Podman inside WSL2 or via Podman Machine, the upgrade isn’t optional—it’s a forced modernization that demands immediate action.

This release is not a gentle nudge. It’s a deliberate break with the past, designed to propel Podman into a world where rootless containers are secure by default, networking is faster, and resource control uses the kernel’s cgroups v2 unified hierarchy. The Podman team has been warning about these changes for over a year, and with version 6.0, the warnings became reality.

The Big Three Removals: What Vanished in Podman 6.0

Three long-standing components are gone, and their absence will break containers, pods, and CI/CD pipelines if you don’t prepare.

1. cgroups v1 Support Evaporates

Podman 6.0 requires cgroups v2 on the host. If your Linux VM or WSL2 instance is still using the legacy cgroups v1 hierarchy, Podman will refuse to start. The error message is unmissable: FATAL: cannot set up cgroup v2 manager. This affects a surprising number of environments—older RHEL 7 derivatives, custom minimal Linux distributions, and long-running Ubuntu LTS installs that haven’t explicitly switched to v2. On Windows, the current WSL2 kernel (5.15.x and later) defaults to cgroups v2, so most users are safe, but older custom WSL2 kernels or explicitly configured cgroups v1 setups will break.

cgroups v2 delivers finer-grained resource control, better support for rootless containers, and aligns Podman with Kubernetes’ preferred cgroup driver. The trade-off: if your monitoring tools, custom scripts, or third-party orchestrators still assume cgroups v1 file layouts, they’ll need rewriting.

2. iptables Rootless Networking Is Replaced

Perhaps the most disruptive change is the removal of the --network=slirp4netns option and the iptables-based rootless networking backend. Podman 5.x and earlier used iptables rules injected by the podman binary to enable outbound connectivity and port forwarding for rootless containers. In Podman 6.0, that logic is gone. Instead, rootless networking is now handled exclusively by netavark (the network setup tool) and pasta (the user-mode networking daemon). This duo doesn’t touch iptables, avoiding firewall complexities and reducing the attack surface.

For users, this means iptables rules previously created by Podman will no longer appear. If you relied on custom iptables chains or third-party tools that inspected Podman’s iptables entries, those integrations stop working. Any network profile that explicitly set --network-opt=... with iptables-specific options will be ignored. The default rootless network now uses pasta, which provides native NAT, port forwarding, and IPv6 support without kernel firewall manipulation.

3. CNI Plugins Are Ejected

Podman 6.0 no longer ships or supports CNI plugins. The cni directory (/etc/cni/net.d) and the cni-podman0 bridge are relics. If your upgrade silently carried over CNI configuration files, Podman will ignore them, potentially leaving containers stranded with no network connectivity. The replacement is netavark, which uses a different configuration format (/etc/containers/networks) and a YAML-based JSON schema. Netavark is faster, supports DHCP and dual-stack IPv4/IPv6 networks, and integrates natively with systemd-resolved for DNS.

Migration means manually converting any custom CNI configurations. For most users, the default netavark network (podman) works out of the box. But environments with complex multi-tenant networking, VLAN bridging, or specific MAC address assignments will need to rewrite configurations.

What Else Changed: New Defaults and Deprecations

Beyond the headliners, Podman 6.0 tweaks several defaults that could catch unwary upgraders:

  • Quadlet moves front and center: Podman’s systemd generator for containerized services is now enabled by default. If you have leftover legacy podman-generate-systemd files, they may conflict with Quadlet’s directory-based discovery.
  • The podman-plugins package is gone: All volume and authentication plugins that were previously separated are now baked into the main binary, simplifying packaging but potentially breaking paths in custom deployment scripts.
  • API version bumps: The REST API has matured to version 5.2.0, with several endpoints retired. Tools like podman-compose or custom clients that anchored to older API versions will need updates.

Windows Users: Podman Machine and WSL2 Survival Guide

On Windows, Podman runs inside a managed Linux VM via podman machine. The 6.0 release includes a new default machine image based on Fedora 40 with cgroups v2, netavark, and pasta preconfigured. If you’re upgrading an existing machine, you must recreate it—the old image won’t survive the removal of iptables and CNI.

Steps for a clean Windows upgrade:

  1. Stop and remove the current machine: podman machine stop then podman machine rm podman-machine-default. This deletes the old VM disk image.
  2. Install Podman 6.0: Download the Windows installer from the GitHub releases page or use winget install RedHat.Podman if the package is updated.
  3. Initialize a fresh machine: podman machine init. This pulls the new Fedora 40 image with all defaults aligned to 6.0.
  4. Start and verify: podman machine start then podman run hello-world. Check that networking works and cgroups v2 is active (podman info | grep -i cgroup).

For WSL2 users who run Podman directly inside a distribution without podman machine, the host WSL2 kernel must support cgroups v2 and provide the necessary modules. Most modern WSL2 kernels (5.15.y and later) do, but you can confirm with grep cgroup /proc/filesystems. If cgroups v2 isn’t listed, update your WSL2 kernel via wsl --update.

Networking Pitfalls on Windows

If you previously opened ports using iptables-based forwarding in WSL2, those rules vanished with the 6.0 upgrade. You must now rely on pasta’s inherent port forwarding, which mirrors the host’s localhost. For example, to expose container port 8080, simply use podman run -p 8080:80 .... Pasta will bind to the WSL2 VM’s localhost; to access from the Windows host, connect to localhost:8080 directly thanks to WSL2’s automatic localhost forwarding.

Custom DNS setups that relied on editing /etc/resolv.conf inside the WSL2 distro may need adjustment, because pasta now manages DNS resolution for containers by default. It forwards queries to the host’s systemd-resolved, which in WSL2 typically uses the Windows DNS settings. This should be seamless for most, but if your environment uses split-horizon DNS or private internal zones, you may need to configure pasta’s --dns and --dns-search options.

Practical Migration Checklist

Before pulling the trigger on Podman 6.0, run through this checklist to avoid downtime:

  • Audit cgroup version: On Linux/WSL2, run mount | grep cgroup. If you see cgroup2 on /sys/fs/cgroup, you’re good. If only tmpfs or v1 lines appear, you must enable v2 via kernel parameters (systemd.unified_cgroup_hierarchy=1) and reboot.
  • Inventory iptables rules: iptables -L -n -t nat | grep podman will show any leftover rules. Understand what they provided (port forwards, NAT) and replicate with pasta configurations if needed.
  • Convert CNI configs: Locate custom CNI files in /etc/cni/net.d or /etc/containers/networks directories and translate them to netavark YAML. Netavark’s schema is documented at man containers-netavark.5.
  • Test with a non-critical container: Before upgrading production workloads, run a minimal container with networking and cgroup checks: podman run --rm -it alpine ip a and podman run --rm -it alpine cat /proc/self/cgroup.
  • Update orchestrators: If you use Kubernetes via kind or Minikube on top of Podman, ensure their node images and networking plugins are compatible with netavark and cgroups v2.
  • Review Quadlet configs: Check /etc/containers/systemd/ and ~/.config/containers/systemd/ for .container files. Quadlet is now the preferred way to run persistent containers; legacy podman-generate-systemd scripts should be retired.

Performance and Security: The Upside of the Breakage

This aggressive cleanup isn’t just architectural housekeeping. It unlocks tangible benefits:

  • Faster container startup: Netavark configures networks up to 40% faster than CNI in benchmark tests, because it bypasses the JSON serialization and shell-outs that plagued the old cni-podman0 bridge.
  • Lower CPU overhead: Pasta handles all port forwarding in userspace with zero kernel iptables rules, reducing interrupt storms on high-traffic servers.
  • True rootless security: No iptables means no privilege escalation path through firewall rule injection. Combined with user namespace mapping, Podman containers are now as isolated as sandboxed browser tabs.
  • Unified resource accounting: cgroups v2 provides a single, coherent view of CPU, memory, and I/O limits, making it easier to set and monitor pod-level resource constraints that align with Kubernetes resource requests.

What the Community Says (and What to Watch For)

The Podman community has generally welcomed the changes, but early adopters have reported edge cases:

  • Networking with VPN clients: Pasta currently has issues when the host uses a VPN that modifies routing tables dramatically. Some users have had to switch to the pasta user-mode program with explicit --network flags, or fall back to slirp4netns emulation (still available via an external binary, but no longer built-in).
  • DHCP assignments: Netavark’s DHCP support is solid for IPv4 but can be flaky with IPv6 on certain routers. Podman maintainers recommend static IPs or SLAAC for IPv6 in production.
  • Rootless port binding below 1024: Pasta, like its predecessor, can’t bind to privileged ports (below 1024) without sysctl tweaks. The workaround (sysctl net.ipv4.ip_unprivileged_port_start=0) remains the same.

Podman’s GitHub issues list shows active discussion around these topics, and the development team is responsive with workarounds. Users are advised to monitor the official Podman blog for 6.x patch releases that may smooth out remaining rough edges.

Forward Look: What Podman 6.0 Means for Windows Containers

Podman’s convergence with modern kernel features mirrors what’s happening in the Windows container space. Microsoft’s own container tools (Moby, Docker Desktop) are gradually adopting cgroups v2 in WSL2, and the removal of iptables dependency in Podman could inspire similar cleanups in Windows-native networking. For developers straddling both OSes, Podman 6.0 provides a consistent, daemonless container runtime that behaves identically from a Windows command prompt as on a Linux server.

The takeaway is clear: Podman 6.0 is a breaking release that forces a long-overdue modernization. The pain is proportional to how much you customized the old defaults. If you lived in the default configuration, the upgrade is a near-seamless dependency refresh. If you maintained hand-tuned iptables rules or exotic CNI plugins, your weekends are about to get busy. Either way, the container landscape just became cleaner, faster, and more secure—and that’s a win for everyone building on the Windows platform.