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 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 .
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 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 childs.
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, 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
Now, when you inspect Podman using systemctl, you’ll discover it’s also operating in the background.
$ systemctl status podman
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
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 😎.
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 “
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
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
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 “
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 daemon in the background, while podman does not. Let’s discuss the advantage 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 the 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
Than 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
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 compatible with Podman out of the box, impressive options such as Watchtower exist. I hope in the future there will be some solid alternatives or they will officially provide support for Podman.
The following are some questions that might tingle in your head; let’s encounter each one of them one by one.
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.
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.
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 the Docker is 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 a beginner should know. If any question is still in your mind then do tell us in the comment section.
Till then, peace!