Difference Between Docker and Podman (Ultimate Guide)

Linux TLDR
Last Updated:
Reading time: 6 minutes

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.

podman vs 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).

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


Checking the docker daemon is running

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

$ systemctl status podman


Checking podman running in background

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


Checking docker and podman services in background

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 😎.

Checking the user running dockerd processes
Pro tip!

Run the following command to list all processes running as root:

$ 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.

Docker can also run containers as non-root, but Podman makes it a more prominent feature.

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


Running docker and podman containers and comparing them

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.

Additionally, it’s important to mention that Docker itself doesn’t request root privileges. However, the Docker command attempts to connect to Docker socks, which are set to permission “600 root:docker“, requiring root access. Nevertheless, this requirement can be bypassed by including the user in the Docker group.

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


running podman container without port under 1024 without sudo

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.

Description=Nginx Container

ExecStart=/usr/bin/podman run --rm -p 80:80 nginx


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.

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

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.

creating alias of docker for podman

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.

Podman help section

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.

Q1. Is Podman a Docker replacement?

Yes, that was the straight answer; even the development of Podman was to replace Docker with a more secure way to create, manage, and run containers with daemonless and rootless features.

Q2. Is Podman better than Docker?

Almost yes, but it still lacks the diversity of Docker-specific tools like Portainer, Watchtower, etc., yet it does not require a separate daemon to run containers, which reduces the attack surface for potential security vulnerabilities.

Q3. Should I directly switch from Docker to Podman?

No, as Podman provides more security out of the box. Nothing is guaranteed to be 100% secure, so for any security reason, I would not recommend directly switching from Docker to Podman. If the features of Podman over Docker are required and only Podman is solving the specific problem you are facing in Docker, then you should transition to Podman.

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!

Join The Conversation

Users are always welcome to leave comments about the articles, whether they are questions, comments, constructive criticism, old information, or notices of typos. Please keep in mind that all comments are moderated according to our comment policy.

2 thoughts on “Difference Between Docker and Podman (Ultimate Guide)”

  1. In the chapter “2. Rootless Containers” using “sudo docker […]” is not required, because docker runs as root. It’s because the “docker” command needs to connect to the /run/docker.sock unix-domain socket. Its permissions are “660 root:docker”. You can run “docker” without sudo, by adding your user to the “docker” group.