Last checked and updated on April 15, 2026What Is New in Podman 5.0
Podman 5.0 delivers a major architecture shift with a new container engine and significant networking improvements. This release focuses on performance, stability, and enhancing the developer experience with new commands and features.
| Category | Key Highlights |
|---|---|
| New Features | New container engine (netavark, aardvark-dns), Quadlet, podman machine on Linux, podman pod clone |
| Networking | Default network stack overhaul, improved port forwarding, DNS resolution for containers |
| Developer Experience | New podman image scp command, Auto-update support, Docker Compose enhancements |
| Changes & Deprecations | New default configuration file location, deprecation of older network drivers |
What is the new container engine in Podman 5.0?
The core change is the integration of a new networking stack consisting of netavark and aardvark-dns. This replaces the previous CNI stack as the default for rootless and rootful containers. In practice, this new engine is written in Rust and provides a massive boost in performance, especially when dealing with a large number of containers and networks.
It also fixes long-standing issues with DNS resolution for containers on user-defined networks. Now, containers can resolve each other's names by default, which finally brings feature parity with Docker's user-defined network behavior. This is a foundational change that makes the entire networking experience more robust and predictable.
How does Podman 5.0 improve networking?
Networking gets a complete overhaul with the new default stack. The netavark plugin handles network setup and teardown, while aardvark-dns provides embedded DNS resolution. This combination offers faster operations and fixes the infamous DNS bugs that plagued previous versions.
Key Networking Improvements:
- Dramatically faster network creation and container startup times.
- Built-in DNS for all user-defined networks, enabling automatic container name resolution.
- Improved port forwarding reliability and performance.
- Better support for IPv6 and dual-stack networks.
What new commands can developers use?
Podman 5.0 introduces several new commands that streamline workflows. The podman image scp command allows you to securely copy images between systems, which is a game-changer for air-gapped environments or moving images across different hosts.
The new podman pod clone command lets you create a copy of an existing pod, which is incredibly useful for testing and debugging. For system-level management, Quadlet allows you to generate systemd unit files from container definitions, making it easier to run containers as system services.
# Copy an image to a remote host
podman image scp myimage:latest root@server:/tmp
# Clone an existing pod
podman pod clone mypod newpodWhat about Podman Machine on Linux?
The podman machine command, previously exclusive to macOS and Windows, is now available on Linux. This lets Linux users manage virtualized Podman environments, which is perfect for testing different configurations or isolating development environments without affecting the host system.
You can spin up a VM with a specific OS and Podman version, test your workloads, and then tear it down. This brings a consistent experience across all operating systems and is a great tool for CI/CD pipelines where you need a clean, isolated environment for builds.
Are there any breaking changes?
Yes, the most notable change is the new default location for the containers-storage configuration file. It has moved from /etc/containers/storage.conf to /usr/share/containers/storage.conf. You'll need to update any scripts or tools that directly reference the old path.
The legacy CNI networking stack is now deprecated. While you can temporarily revert to it by setting network_backend="cni" in your configuration, the new netavark stack is the future and offers significant advantages. It's recommended to switch and test your workloads with the new backend.
# To temporarily revert to the old CNI backend (not recommended)
echo 'network_backend="cni"' > /etc/containers/containers.confFAQ
Do I have to migrate my existing containers and networks to the new networking stack?
Yes, for the best experience. While you can revert to CNI, the new stack is the default and future. Existing containers will continue to work, but for new containers and networks, you'll be using netavark. It's best to test your setup and migrate.
How do I use the new built-in DNS for container name resolution?
It just works now. Create a user-defined network with podman network create mynet, then run containers with --network mynet. Containers on that network can ping each other by name without any extra configuration.
My scripts reference /etc/containers/storage.conf, what should I do?
Update them to point to the new location: /usr/share/containers/storage.conf. Alternatively, you can place a copy of your configuration at the old path for backwards compatibility, but updating is the preferred long-term solution.
Is Quadlet replacing podman-generate-systemd?
Not immediately, but it's the intended successor. Quadlet provides a more declarative way to create systemd services for containers by writing simple unit files instead of generating complex ones. It's worth learning for new deployments.
Can I use podman machine on Linux to run a different Linux distribution?
Absolutely. That's the primary use case. You can specify the OS image when initializing a new machine, allowing you to test your containers on distributions like Fedora, Ubuntu, or others without needing a physical box or complex local setup.