Last checked and updated on April 15, 2026What Is New in Podman 4.3
Podman 4.3 delivers a substantial update focused on enhancing container management, improving the user experience, and expanding system capabilities. This release introduces new commands, refines existing features, and addresses a number of user-reported issues.
| Category | Key Highlights |
|---|---|
| New Features | New podman events backend, podman cp enhancements, improved secret handling. |
| Improvements | Better Docker Compose integration, volume management upgrades, and networking refinements. |
| Bug Fixes | Numerous fixes across containers, pods, images, and the underlying codebase. |
| Deprecations | Marking older APIs and commands for future removal. |
What's the new events backend all about?
The new podman events backend is a major architectural shift. It replaces the previous file-based logging system with a journald-driven approach, which is far more robust and efficient for streaming container lifecycle events.
In practice, this means events are now written to the system journal, making them easier to collect, filter, and forward using standard Linux tooling. This is a foundational change that improves reliability, especially for systems that need to process a high volume of events.
How has file copying been improved?
The podman cp command received significant attention. It now properly handles copying files between the host and containers that are not running as root, a common pain point for user namespaces.
Furthermore, the command now supports the -L flag to follow symlinks in the source directory, aligning its behavior more closely with the standard cp tool. These fixes make data transfer into and out of containers much more predictable.
What's new with secrets management?
Secrets management is now more integrated and user-friendly. A key addition is the --secret option for the podman run and podman create commands, allowing you to inject a secret directly into a container at launch.
This streamlines the process of providing sensitive data like API keys or certificates without having to use environment variables or bind mounts. The secret is mounted inside the container at /run/secrets by default.
Are there networking upgrades?
Yes, the networking stack saw several important upgrades. The podman network reload command was added, allowing you to update a container's network configuration without a full restart—this is huge for maintaining service availability.
DNS resolution within user-defined rootless networks was also fixed. Containers can now reliably resolve each other's names, which is critical for microservices communication in a Compose setup.
How does Docker Compose support look now?
Docker Compose support is maturing rapidly. Podman 4.3 includes numerous bug fixes for podman-compose, improving its compatibility with existing docker-compose.yaml files.
Specific improvements include better handling of volume definitions, service dependencies, and environment variable interpolation. For developers transitioning from Docker, these fixes make the switch to Podman nearly seamless for local development.
FAQ
Do I need to migrate my existing events when upgrading to 4.3?
The new journald backend operates independently. Old events from the previous file-based system will not be migrated to the journal. You'll only see new events generated after the upgrade in podman events.
Will the new `podman cp` behavior break my existing scripts?
It fixes previous broken behavior, so your scripts should become more reliable, not less. The change primarily affects copying to/from rootless containers, which should now work as originally intended.
Is the `podman network reload` command available for rootless containers?
Yes, the podman network reload command works for both rootful and rootless containers, making it a universally useful tool for updating network settings on the fly.
What happens to my existing secrets created with older Podman versions?
They remain fully functional. The new --secret flag for podman run is an additional way to consume secrets, not a replacement. All existing secrets and their management commands are unchanged.
Has the path for secrets inside the container changed?
No, the default mountpoint remains /run/secrets. This maintains consistency with established conventions and avoids breaking applications that expect to find their secrets in that location.