VS

Docker uses a daemon, an ongoing program running in the background, to create images and run containers. Podman has a daemon-less architecture which means it can run containers under the user starting the container. Docker has a client-server logic mediated by a daemon; Podman does not need the mediator.

Architecture

Podman, since it doesn't have a daemon to manage its activity, also dispenses root privileges for its containers. Docker recently added rootless mode to its daemon configuration, but Podman used this approach first and promoted it as a fundamental feature. And this is because of the next point.

Root privileges

Podman allows for non-root privileges for containers.Rootless containers are considered safer than containers with root privileges. In Docker, daemons have root privileges, making them the preferred gateway for attackers. Containers in Podman do not have root access by default, adding a natural barrier between root and rootless levels, improving security. Still, Podman can run both root and rootless containers.

Security

Without a daemon, Podman needs another tool to manage services and support running containers in the background. Systemd creates control units for existing containers or to generate new ones. Systemd can also be integrated with Podman allowing it to run containers with systemd enabled by default, without any modification. By using systemd, vendors can install, run, and manage their applications as containers since most are now exclusively packaged and delivered this way.

Systemd

As a self-sufficient tool, Docker can build container images on its own. Podman requires the assistance of another tool called Buildah, which expresses its specialized nature: it is made for running but not building containers on its own.

Building images

Podman does not support Docker Swarm, which may rule it out of the options for projects using this feature since using Docker Swarm commands will generate an error. Podman has recently added support for Docker Compose to make it Swarm compliant, overcoming this limitation. Docker, naturally, works well with Swarm.

Docker Swarm

And maybe this is the crucial difference in both technologies: Docker is a monolithic, powerful, independent tool with all the benefits and drawbacks implied, handling all of the containerization tasks throughout their entire cycle. Podman has a modular approach, relying on specialized tools for specific duties.

All in one vs modular

Sold as the best and easiest to apply alternative to Docker - users can just alias Docker to Podman (alias docker=podman) without any problems, as shown in this presentation - Podman is a more than capable tool for containerization tasks.

Podman vs Docker: Can they work together?

Podman can be a primary containerization technology option if you are starting a project from scratch. If the project is ongoing and already using Docker, it depends on the specifics, but it might not be worth the effort. As a Linux native application, it demands Linux skills from the developers involved.

Is Podman a replacement for Docker?

Developers can combine both tools by relying on Docker in the development stage and later push the project to Podman in runtime environments, benefitting from the added security it provides. And since they're both OCI-compliant, compatibility shouldn't be a problem.

Is Podman a replacement for Docker?

Yes, and quite well. Many developers have been using Docker and Podman in tandem to create safer, more efficient, agile frameworks. They have a lot in common, making the transition from Docker to Podman or their combination quite seamless.

Can Docker and Podman coexist?