Difference Between Docker and Podman (Ultimate Guide)

Podman is an open-source container management tool that provides a way to create, manage, and run containers on your Linux systems. Sounds familiar, right? If you’ve ever used Docker in your life, you can relate to their similarities.

But hold your horses as you read this entire article. You will find amazing new technology, which I personally find to be very useful, especially in the days ahead.

In this article, you will learn what Podman is, the difference between Podman and Docker, their command differences, and when you should use Podman or Docker.

What is Podman?

Podman is a Red Hat product first released in 2017, around four years after Docker was released in 2013. The intention of Podman’s development was to make developing, managing, and running containers on your Linux systems more secure and efficient [1].

The key feature of Podman was its ability to run containers without needing any daemons and providing ways to run rootless containers (as they market themselves).

• Install Podman on Your Favorite Linux Distribution

To make it simple for beginners to exactly understand the key difference between Docker and Podman, including all other common questions, they are answered in the next section.

The Key Difference Between Podman and Docker

Many folks may promote that Podman is better than Docker with different points to compare, but from my point of view, I personally find the following key differences that could be the reason for you to switch from Docker to Podman right away:

• Daemonless Architecture
• Rootless Containers
• Systemd Integration

Here are a few key advantages you’ll enjoy when you make the switch to Podman.

• Docker Compatibility
• OCI Compatibility
• Toolchain Compatibility

Now, listing this point may not give you clear context. So, let me explain the main difference highlighted with practical examples.

1. Daemonless Architecture

If you’ve ever heard of the “dockerd” term, then understand that it’s a Docker daemon, which runs in the background and manages all your containers like a father, and containers are its children.

Now, our father, in this case, our “dockerd“, requires root privileges, as your daemon cannot be run without these privileges. So, if there is any problem, let’s say our father gets sick and all the containers running under our daemon start crashing.

And getting sick is not always the fault of the system; sometimes, attackers will try to penetrate the Docker daemon, and if they by chance get access to it, they will have complete control over all the child containers (and also your system 😓).

To determine if the Docker daemon is running, just execute this command.

$ systemctl status docker

Output:

Now, when you inspect Podman using systemctl, you’ll discover it’s also operating in the background.

$ systemctl status podman

Output:

Because of this one factor, you could mistakenly assume that Podman operates as systemd services and runs a daemon as the root user, but that’s not the case.

Look, when you see Podman listed in “systemctl” on your Linux system, it typically means that Podman is using a socket-activated service. This service starts only when needed and automatically stops when it’s no longer in use.

It is not a long-lived background daemon like Docker’s “dockerd“, and due to this socket-activated service, Podman is allowed to function similarly to Docker in terms of CLI usage and compatibility.

Let’s look at another example where we’ll inspect both Docker and Podman processes using the ps command.

$ ps aux | grep docker
$ ps aux | grep podman

Output:

As you can see from the above image, “dockerd” is continuously running as a background process, while there is no process running for Podman (the one that is shown is the PS command itself).

Now, when you take a close look at the user running the “dockerd” process, you will discover it is none other than our root user 😎.

$ ps -U root -u root

To wrap up, the Docker daemon keeps running in the background as the root user, giving it superuser privileges, unlike Podman, which only uses socket-activated services to start only on demand and doesn’t run any continuous processes in the background like “dockerd“.

2. Rootless Containers

Running a rootless container with Podman means that you are starting a container without requiring root (administrator) privileges.

This is the key feature of Podman that enhances security by reducing the attack surface 🥷 and isolating the container 🥹 from the host system.

To give you an example, I’ll run the nginx container using Docker and Podman together.

$ sudo docker run -dp 80:80 nginx
$ podman run -dp 8080:80 nginx

Output:

As you can see from the image above, Docker requires sudo privileges, while Podman executes without them, which means Docker containers are running at the root level while Podman containers are running at the current logged-in user level.

In the future, if attackers find a way to penetrate the Docker container, they can easily access the whole system, while the Podman attack surface limits access only to the current user running the Podman container.

However, there is one more thing you should note: ports under 1024 cannot be used while running Podman at the user level, as shown.

$ podman run -dp 80:80 nginx

Output:

This is not an issue with Podman, as ports under 1024 are considered privileged ports and cannot be accessed without root privileges.

To resolve this, you can either use ports above 1024 or add the desired port as an exception to “net.ipv4.ip_unprivileged_port_start=80” in your “/etc/sysctl.conf” file.

Also, you can run that particular Podman command with sudo privileges, but it’s not recommended.

3. Systemd Integration

As I stated earlier in the Daemonless Architecture section, Docker continuously runs as a daemon in the background, while podman does not. Let’s discuss the advantages of this particular Docker feature.

First and foremost, both Docker and Podman lack built-in mechanisms for automatic container updates. However, in Docker, you can leverage tools such as Watchtower to monitor the latest version of an image and automatically spawn a container with the updated image when a new release becomes available.

And this is only possible because Docker is running continuously in the background as a daemon, while Podman is not. As a result, when an image’s developer discovers a bug or security flaw, they publicly announce it and make a patched version of the image available for use.

Docker can easily update the container with the latest available patched image, but how does Podman do it?

The answer is quite simple: Podman has systemd integration, which means you can run containers and pods as systemd services.

This integration allows you to manage containers and pods using systemd, making it easier to control their lifecycle, handle dependencies, and integrate them into your system’s service management.

Apart from that, you can also create a systemd service unit file to run a container as a systemd service. Your service unit file will look like the one below.

[Unit]
Description=Nginx Container

[Service]
ExecStart=/usr/bin/podman run --rm -p 80:80 nginx
Restart=always
User=your_username

[Install]
WantedBy=multi-user.target

After creating the service unit file, you can reload your systemd to read the new unit file:

$ sudo systemctl daemon-reload

Then start the service and enable it to start at boot by running:

sudo systemctl start nginx-container.service
sudo systemctl enable nginx-container.service

I hope you now understand how systemd integration allows you to have more control over containerized applications and easily manage their lifecycle alongside other system services.

4. Docker Compatibility

Apart from a few things, Docker and Podman share a similar command-line interface; even on the Podman official site, they mentioned that you can easily create an alias for your Docker command.

I won’t be doing that 🤷‍♂️, and I don’t recommend you do it either, as it could lead to confusion later on.

Also, when you take a look at the Podman help section, you’ll notice that Docker and Podman provide similar output, and it was done intentionally for a smoother transition for Docker users to adopt Podman.

5. OCI Compatibility

Podman uses the Open Container Initiative (OCI) standards for container images and runtimes, ensuring compatibility with other containerization tools and technologies.

6. Toolchain Compatibility

Podman has a growing ecosystem of tools and utilities, including Podman Compose (similar to Docker Compose) for defining and running multi-container applications.

Although advanced front-end tools like Portainer are not perfectly compatible with Podman out of the box (yet you can give it a try), impressive options such as Watchtower exist. I hope in the future there will be some solid alternatives or that they will officially provide support for Podman.

Common Questions

The following are some questions that might tingle in your head; let’s encounter each one of them one by one.

So, that’s all the difference between Podman and Docker that a beginner should know. If any question is still on your mind, then do tell us in the comment section.

Till then, peace!