Podman is a container engine—a tool for developing, managing, and running containers and container images. Containers are standardized, self-contained software packages that hold all the elements necessary to run anywhere without the need for customization, including application code and supporting libraries. Container-based applications have revolutionized software development over the past decade, making distributed and cloud-based systems easy to deploy and maintain.
Podman is a project from Red Hat that is open source and free to download. It is a relative newcomer to the containerization scene, with version 1.0 being released in 2019. Podman has since made great strides, and its rise has been compounded by the gradual decline of Docker, the project that in many ways created the world of containers as we know it today.
Podman and Kubernetes
If you're even slightly familiar with container-based development, you'll know the name Kubernetes. As containerized applications grew more complex, developers needed tools that could coordinate containers that interacted with each other while running on different virtual machines, or even on different physical machines. Such a tool is called a container orchestration platform, and Kubernetes is by far the most prominent example. Kubernetes can work with any container that meets the Open Container Initiative (OCI) image specification, which Podman's containers do.
One of the important features of Kubernetes is the concept of a pod, an ephemeral grouping of one or more containers that is the smallest unit of computing that Kubernetes can manage. Podman is also centered on the idea of a pod, as its name implies. A Podman pod also includes one or more containers, which are grouped together in a single namespace, network, and security context. This similarity makes Podman and Kubernetes a natural fit, and from the beginning one of Red Hat's goals was to have Podman users orchestrate containers with Kubernetes.
Podman vs. Docker
The other big name from the world of containers that you've almost certainly heard is Docker. Docker wasn't the first container engine but in many ways it has come to define containerization. Much of how Docker works is the de facto standard for container-based development—enough so that many people use "Docker" as a shorthand for containers.
While Docker and Podman occupy a similar space in the container ecosystem, they are not the same, and they have different philosophies and approaches as to how they work. For instance, Docker is an all-in-one platform with tools for specific tasks, whereas Podman collaborates with other projects for certain purposes—for instance, it relies on Buildah to build container images.
There are also architectural differences: Docker has no native concept of pods, for instance. Another important difference is that Docker relies on a continuously running background daemon program to create images and run containers, whereas Podman launches containers and pods as separate child processes. This aspect of Docker's design has important implications for security, which we'll discuss shortly.
Docker commands on Podman
By design and necessity, Podman and Docker are overall compatible. Part of that compatibility can be attributed to adherence to open standards. Because both engines work with containers that conform to the OCI standard, you can create a container with Docker and modify it in Podman, or vice versa, then deploy either container onto Kubernetes.
When Podman rolled out in 2019, Docker was so dominant that its command-line interface had become a part of many developers' programming routines and muscle memory. In order to make a potential move to Podman more seamless, Podman's creators made sure that its commands and syntax mirrored Docker's as much as possible. They went so far as to make it possible to set an alias that re-routes Docker commands to Podman.
Better security with rootless containers
With Podman and Docker working so similarly in so many ways, why would you choose one over the other? Well, one important reason is security. Remember how Docker relies on a daemon to do much of its ongoing work? That daemon runs as root, which makes it a potential entry point for attackers. This isn't an insurmountable obstacle to secure computing, but it does mean that you have to put some thought into navigating Docker security issues.
In some situations, you'll want to run a container with root privileges on its host machine, and Podman lets you do that. But if you would rather keep your containers safely restricted to user space, you can do that as well, by running what's called a rootless container. A rootless container has no more privileges than the user that launched it; within the container, that user has root privileges. You can also use command-line flags to add privileges to your containers in a granular way.
What about performance?
One area where Docker has a leg up on Podman is performance, at least according to some. While there's little concrete information on this subject, it's not hard to find frustrated developers on Hacker News, Stack Overflow, and Reddit complaining about Podman's performance, especially when it's running rootless. Some Swedish university students ran a benchmark suite on several different container platforms and found Podman lacking, though this was admittedly an older pre-1.0 version of Podman. While there's not a lot of technical information on this topic, anecdotally Podman gets dinged for its performance.
Will Podman replace Docker?
From the discussion so far, it may not sound like any great vibe shift is in the works to replace Docker with Podman. But a major change is coming that will displace Docker from one of its longtime niches: Kubernetes itself.
Kubernetes and Docker have for years been the twin giants of the container world. But their coexistence was always somewhat uneasy. The rise of Kubernetes came after Docker was well established in its niche—indeed, you could say that Kubernetes became popular in part because Docker wasn't up to the task of managing all the containers that needed to be coordinated in a large, distributed application.
Docker (the company) developed its own container orchestration platform in 2015, dubbed Swarm, that was designed to play to Docker's strengths. Swarm was launched with great fanfare, but never quite caught up to Kubernetes. While Swarm still has devotees, Kubernetes has become the de facto standard for container orchestration, just as Docker became the de facto standard for other aspects of the container ecosystem.
Additionally, Docker never quite played nice with Kubernetes in terms of its container runtime, the low-level component of the container engine that, among other tasks, works with the underlying operating system (OS) kernel and mounts individual container images. Both Docker and Kubernetes conform to the OCI image spec, which Kubernetes uses to coordinate images built to containers. But Kubernetes also relies on container runtimes compatible with a standardized plugin API called the Container Runtime Interface (CRI), which Docker has never gotten around to implementing.
For a long time, Docker's popularity forced Kubernetes to use Dockershim, a CRI-compliant layer that was an intermediary between Kubernetes and the Docker daemon. This was always something of a hack, however, and earlier this year, Kubernetes jettisoned support for Dockershim. (Podman, by contrast, uses the compatible CRI-O runtime from the Cloud Native Computing Foundation.)
This is part of a larger story about Docker trying and failing to become an enterprise company. In short, Docker was never fully able to break away from Kubernetes. Kubernetes, meanwhile, no longer needs Docker to the extent it once did.
Whether Podman will replace Docker is unclear, but it will definitely be one of the contenders. It helps that Podman is not a flagship product looking to be monetized, but rather a single open source technology offering from a much larger company. We can expect Podman and Kubernetes to remain intertwined for some time to come.
Which container engine should you use?
Hopefully, this discussion gives you a sense of the factors to help you choose between these two container engines. Podman is based on a more secure architecture, while Docker has a deeper history. Podman is native to Kubernetes, whereas Docker also works with Docker Swarm. Docker includes all the functionality you need for many container-related tasks. Podman is modular and lets you experiment with different tools for different purposes.
With that said, the "Podman vs. Docker" question is on some level a false choice. Both platforms create images that conform to the OCI spec, and both are driven by many of the same commands, so you can move seamlessly between the two. You may, for instance, want to use Docker for local development, then use Podman to deploy the containers you built inside Kubernetes.
One feature that sets Docker apart is that it comes with paid support. But even this has a flipside: as Docker (the company) tries to monetize its flagship offering, it has started charging for the Docker Desktop development environment. Red Hat, on the other hand, seems content to leave Podman free (as in beer) for now.
Jacqueline Primavera is a technical writer and editor in Los Angeles.