Podman 4.3.0 is now available! There’s a lot to be excited about, including numerous new features, over 30 bug fixes, and many other improvements. A major focus of 4.3 has been on improving Docker compatibility, including the addition of many missing options and aliases to Podman’s command line to further our efforts to make transitioning to Podman a seamless change. Podman’s integration with Kubernetes has also seen many improvements, including improved integration with systemd and support for automatic updates. Read on for more details and these changes and more!

The Podman team made improved compatibility with Docker a priority for Podman 4.3. We audited Podman’s commands against the Docker command line tool to identify missing and unsupported options and then set to work adding and fixing differences. As part of these, we added a dozen new options to various Podman commands, with many of these being missing aliases for existing options. A new set of commands, podman context, have been added for compatibility with docker context. These are also aliases (for podman system connection commands), and will usually be hidden as they are only required for scripts originally written to use Docker. We have also removed a known incompatibility with Docker in Podman’s volume handling. Docker compatibility remains a focus for Podman, and we will continue our efforts to make migrating to Podman effortless.

Podman’s Kubernetes integration also saw numerous changes, the biggest of which is the creation of the podman kube command. Previously, Kubernetes YAML was generated with podman generate kube and ran with podman play kube, but users found this confusing - it wasn’t immediately obvious from podman help that the commands existed. By moving the commands to podman kube generate and podman kube play and introducing a new command to tear down pods (podman kube down), we consolidated all Kubernetes commands in one easy-to-find place. The podman generate kube, and podman play kube commands will continue to work, but the new podman kube commands will be preferred.

Of course, we didn’t stop at just renaming commands. We’ve made a number of further additions to podman kube play, most notably improved systemd integration. In Podman 4.2, we added podman-kube@.service to allow pods created with podman kube play to be managed with systemd. With Podman 4.3, we’ve improved this in two significant ways. First, pods using podman-kube@.service can now use sdnotify to verify to systemd that they have started. This laid the groundwork for the following major change: Pods from podman-kube@.service now support Podman’s auto-updated mechanism, enabled using an annotation (io.containers.auto-update). Furthermore, we made several improvements to podman kube play, including support for emptyDir volumes, support for user namespaces via HostUsers, and support for binary data in ConfigMaps.

These are just a few of the over 30 features and bug fixes included in Podman 4.3.0. Be sure to check out the release notes for more details!

Netavark and Aardvark-dns v1.2.0 has been released!​

The underlying network components for Podman have been updated. This consists of two projects:

• Netavark - network configuration tool for Podman
• Aardvark-dns - container domain name resolution server for Podman containers

Podman v4.2.0 has been released!​

Podman 4.2.0, our latest release, is now available. Featuring dozens of new features, including support for the GitLab Runner, significant improvements to podman play kube, and pods in general. We’ve also been working on running Podman on Mac and Windows, with a number of major bug fixes and several new features for podman machine landing. We are also happy to announce an early release of Podman Desktop, a GUI tool for Podman. Read on for more details!

Our new release now supports being used with the GitLab Runner as part of GitLab CI platforms, using the Docker executor. This has been the culmination of months of effort, and required squashing a number of bugs in our REST API. GitLab Runner has been a much-requested feature, and we’re eager to see what users do with it!

As part of the 4.2.0 release, we have made many changes to both Podman pods and the podman play kube command. Pods now have early support for resource limits, allowing CPU and memory use for a pod to be limited. All containers in the pod will share this limit but can still set their own limits. Pods can also be cloned now via the new podman pod clone command. Support for YAML in play kube has also been improved, with additional support for security context settings and the ability to use BlockDevice and CharDevice volumes.

systemd integration with podman play kube has been introduced. Pods launched by podman play kube can be managed by systemd, using the new podman-kube@.service service - e.g. systemctl --user start podman-play-kube@$(systemd-escape my.yaml).service will run the my.yaml file managed by systemd.

Several other features and changes also landed in Podman v4.2.0. Early support for Sigstore signatures is now available in podman push and podman manifest push - expect more in this area in the future as we further integrate Sigstore and Podman. Podman networks can now be isolated (preventing traffic from being sent to other Podman-managed networks) with the --opt isolate= option to podman network create.

These are just a few of the 40 new features and 50 bug fixes included in Podman 4.2.0. Be sure to check out the release notes for more details!

Along with the release of Podman 4.2.0, a new version of Podman Desktop is available. If you are not yet aware of Podman Desktop, it’s a new project under the container organization to help developers work with containers in their local environment with a desktop UI. Podman Desktop is still in its early days. Still, it already provides capabilities to list your images, interact with containers (access logs, get a terminal), connect to registries (pull private images, push your images) and configure podman settings (proxies). An early adopter program has also been set up. Feel free to sign up if you are interested in testing Podman Desktop, providing feedback, and speaking about your ideas, experiences, and pain points! If you are interested in contributing to the tool, your help would also be appreciated. Feel free to investigate the project’s Github.

Podman v4.1 has been released!​

The new Podman v4.1.0 release is now available. This release is all about new features, with some of the most exciting being improved support for running on Mac and Windows, and adding support for Docker Compose v2.0. These are just the beginning, though, as this release also includes the ability to clone containers, significant improvements to checkpointing, and over 25 bug fixes. Read on for more details!

Podman’s support for running on Mac and Windows via podman machine has seen a number of major improvements, chief among them support for mounting the host machine’s home directory into the podman machine VMs by default. Also, on Windows, you can now refer to arbitrary Windows drive paths in your volume mount expressions. This allows containers run by Podman to use mounts from the host, an often-requested feature. Additionally, we’ve added a podman machine inspect command to inspect existing VMs, and support for modifying the CPU, memory, and disk limits of existing VMs using the podman machine set command. Support for non-Linux operating systems continues to be one of our main focuses, and we’re committed to improving our user experience here - stay tuned for more details!

Podman v4.1 is also our first release to support Docker Compose v2.2.0 and up. Since our v3.0 release over a year ago, Podman has supported Compose v1, but the rewritten Compose v2 required further work in Podman to support. Please note that it may be necessary to disable the use of the BuildKit API by setting the environment variable DOCKER_BUILDKIT=0; we’re looking into improving our Buildkit support in the future, so this is not necessary.

There are numerous other changes and improvements to all parts of Podman packed into this release. We’ve added several new commands, including podman volume mount and podman volume unmount (to allow easy copying of files to and from volumes without using them in a container) and podman container clone (creates a copy of an existing container, with the ability to change many settings while doing so). Checkpoint and restore have seen a major improvement with the ability to store checkpoints as OCI images, allowing them to be distributed via container registries. Finally, Podman has gone on a diet - we set out to reduce or eliminate many of our dependencies and managed to reduce our binary size by 8MB shaving off 15% of the original binary size. There are many more changes - too many to list all of them here - so be sure to check out the release notes!

Podman v4.0 has been released!​

Podman v4.0.0, a brand-new major release, is now available. Podman 4.0 is one of our most significant releases ever, featuring over 60 new features. Headlining this release is a complete rewrite of the network stack for improved functionality and performance, but there are numerous other changes, including improvements to Podman’s Mac and Windows support, improvements to pods, over 50 bug fixes, and much, much more!

Podman now features support for a new network stack based on Netavark and Aardvark, in addition to the existing CNI stack. The new stack features improved support for containers in multiple networks, improved IPv6 support, and improved performance. To ensure that we don’t break existing users, the old CNI stack will remain the default on existing installations, while new installs will use Netavark. We’re planning an in-depth dive into the networking changes in a future blog, so look forward to more details there!

Support for Podman on Windows and OS X has also been a top priority, and we have made several major improvements for Podman 4.0. Chief among them is support for mounting the Podman API socket on the host system, allowing tools like Docker Compose to be used on the host system instead of inside the podman machine VM. Also, podman machine can now use WSL2 as a backend on Windows, greatly improving Podman’s support for Windows. More features, including support for volume mounts from the host, are planned for Podman v4.1, so stay tuned for more updates.

Podman Pods have seen numerous new features added to allow sharing resources between containers in the pod. The --volume and --device options to the podman pod create command allows volumes and devices to be mounted to every container in the pod, and the --security-opt and --sysctl options allow these configurations to be set for every container in the pod. Again, these changes are just the beginning of what we have planned - eventually, we aim to have almost every option from podman run available to pods to allow easy sharing of configuration options among containers within them.

These changes are just the tip of the iceberg - there’s far more packed into this release, including major updates to checkpoint and restore, improvements to podman generate systemd and podman play kube, and so much more. Find out more in the release notes.

Podman 3.3 has been released!​

A new Podman release is available, featuring a number of exciting new features, including improved support for running Podman on OS X, support for restarting containers after a system restart, improved support for checkpointing and restoring containers, and 60 bug fixes and stability improvements. Read on for more details!

Podman’s support for running on non-Linux operating systems via the podman machine command continues to improve in v3.3.0. When containers are run inside a virtual machine created by podman machine, port forwarding from the host to the container is now supported - that is, a container that forwards port 8080 on the host to port 80 in the container will now be accessible not just from port 8080 in the Podman-managed virtual machine, but also from port 8080 on the host system. Stability also continues to improve, with many fixes being made to both podman machine itself and the remote Podman client.

Podman now supports restarting containers created with the --restart option after the system is rebooted. Containers created with --restart=always can be automatically started when the system boots if the podman-restart.service systemd unit is enabled. Our main focus continues to be on managing containers directly with systemd via podman generate systemd, which has always allowed containers to be automatically started after boot and provides greater flexibility than the --restart option, but the addition of podman-restart.service will be useful for those seeking improved compatibility with Docker. The podman generate systemd command also saw several improvements, and will not default to using SDNotify instead of PID files, producing smaller and easier-to-understand unit files.

Support for checkpoint and restoring containers has seen several new additions, most notably the ability to checkpoint and restore containers that are part of pods. Additionally, when restoring containers, you can now alter what ports the container publishes via the --publish option. Together, these greatly increase the flexibility of checkpoint and restore.

This release also includes numerous other changes, features, and fixes. Find out more in the release notes.

Podman 3.1 has been released!​

The new Podman release includes a number of exciting new features, including the podman secret command for managing secrets, support for a volume chown option to fix permissions automatically, improved support for volumes in podman generate kube, and over 60 bug fixes, many to the HTTP API. Read on for more details!

Secrets support has been a frequent request for Podman, and 3.1.0 features the first step toward fulfilling it. Secrets add a way to easily add confidential data into containers, by having Podman-managed secret files, which can easily be added to containers. We have added a suite of new commands - podman secret create, podman secret ls, podman secret inspect, and podman secret rm - to manage these secrets, and a --secret flag to podman create and podman run to mount secrets into containers. Please note that the initial implementation of secrets does not encrypt secrets at rest - look for this in an upcoming release.

Podman can now automatically change volume ownership to match the user a container is running as. The new :U mount option for volumes made with the -v flag to podman create and podman run will chown paths mounted into containers to ensure that the user in the container can access the volume. This is very useful with rootless containers, where the rootless user namespace can make it difficult to tell what user on the container will access a directory.

The podman generate kube command can now generate PersistentVolumeClaim volumes for Podman named volumes attached to containers. These have been supported in podman play kube since v2.2.0, but until now, Podman has not been able to create YAML with these volumes. This important addition restores symmetry between generate kube and play kube.

This release also includes numerous other changes, features, and fixes. Find out more in the release notes.

Podman 3.0 has been released!​

This new major release features several exciting new features, including support for Docker Compose, improved security around image pulls by short name, improved networking support, and over 100 bug fixes. Podman v3.0 also features numerous improvements to our REST API and the Podman remote client.

The headlining feature of Podman 3.0 is the addition of support for Docker Compose which can now run against the Podman REST API. There are no changes needed as Compose won’t even realize it’s using Podman. Compose is only supported when running Podman as root; we aim to support it with rootless Podman in a future release.

Podman 3.0 also enables secure short name aliasing by default, a feature that debuted in experimental form in Podman 2.2. With short name aliasing enabled, every time a user-facing Podman process pulls an image by a short name for the first time (e.g. podman pull fedora), it will prompt to ask the user where they want to pull from. This removes several potential ways an attacker could manipulate where an image was pulled from to cause Podman to pull a malicious image.

Podman networking has seen numerous fixes as part of Podman 3.0. We have added a new command, podman network reload, which recreates firewall rules for Podman containers. Previously, reloading the system firewall would render all containers running as root unusable until they were restarted; podman network reload fixes this. Networks created by podman network create also now support labels, and the podman network ls command can filter using these labels.

Podman v3.0 includes the latest version of Buildah along with updates to our other container libraries. Buildah 1.19.2 includes many new features and fixes, including improved support for building multi-platform container images.

Podman v3.0 also includes a fix for CVE-2021-20199. This is a security issue where rootless Podman would rewrite the source address on traffic from published ports to 127.0.0.1, which could cause an authentication bypass on certain images. We strongly suggest upgrading if you use rootless Podman.

As part of 3.0, Podman has dropped support for the legacy Varlink API, which we deprecated in Podman 2.0. We recommend all users of the Varlink API upgrade to the new REST API.

Dozens of other features, changes, and bug fixes are all included to improve stability, performance, and compatibility. These include numerous additional commands and options as well as API changes and fixes. You can read more here.

Podman 2.2 has been released!​

Podman v2.2.0 has been released! Featuring numerous new features and over 80 bugfixes, the new Podman offers a number of often-requested features and improved stability. Read on for more details!

Some of our most exciting new features include support for network aliases and the network connect and network disconnect commands. Network aliases are additional names that containers can be accessed through when using DNS. The network connect and network disconnect commands allow running containers to be added to and removed from networks. These have been frequent requests from users, and significantly improve our compatibility with Docker in networking.

Podman 2.2 also comes with initial support for short name aliasing. This feature, explained more fully here, enhances the security of short names in the podman pull and podman run commands (e.g. podman pull ubi8) by ensuring that that the image we pull is actually the image the user wanted. This feature is purely opt-in for now but will be enabled by default in Podman 3.0.

The podman generate kube and podman play kube commands also saw numerous improvements, most of which were provided by the community. Both generate kube and play kube now support resource limits for containers. We’ve also gained support for Kubernetes’ persistent volume claims and configmaps in podman play kube. We now offer increased control over the containers created by play kube as well, with a --start option (defaulting to true) controlling whether they are started immediately after being created, and the ability to set what log driver they use to improve the ability of podman play kube to integrate with systemd unit files.

We’ve also added several other improvements. The --mount option to podman create and podman run can now mount a container image into a container using the type=image argument. Additionally, the podman inspect command now works with more objects (networks, pods, and volumes) instead of just containers and images. Finally, more Podman commands (podman mount, podman diff, podman container exists) can now work with Buildah and CRI-O containers, in addition to Podman containers.

Numerous bug fixes to APIV2 to better support docker-compose and docker-py.

Podman 2.1 has been released!​

Podman v2.1.0 has just been released! This is one of our largest releases ever, and features numerous new features, over 50 bugs fixed, and extensive work on the REST API. Read on for more details!

Our biggest announcement is that rootless Podman now supports inter-container networking. Previously, it was impossible for rootless Podman containers to communicate directly with each other without using pods. Now, by joining rootless containers to a network, they can communicate with other containers in the same network in the same manner as containers running with full root privileges. This is a major improvement to rootless networking, and addresses one of the largest gaps between running Podman with and without root.

We’ve also enabled a number of new features for images. Podman can now mount images (read-only) so their contents can be viewed without creating a container based on the image, using the podman image mount command. Additionally, podman save and podman load can now work with archives containing multiple images, instead of only one at a time. Finally, Podman’s pull logic has been reworked to retry pulling images when a pull fails due to network issues.

The podman play kube command has also been a focus of attention. It now handles many additional options from Kubernetes YAML. These include support for new volume types (mounting sockets into your pods and setting volumes as read-only), setting restart policy for pods, adding entries to /etc/hosts, and many more. These features are available to anyone using podman generate kube as well.

In addition, there are numerous small improvements. Volume mounts can now use the :O option to be created as overlay mounts - mounts where changes made by the container will not be propagated back to the host. Podman now supports setting the timezone of containers (using the --tz flag). The podman ps command now supports a --storage option which will display all containers on the system, even those not managed by Podman (e.g. Buildah and CRI-O containers).