Podman – A Docker Alternative


Whenever you hear the term container in technology, Docker is always the first thing that comes to mind. However, after a decade of reign, new alternatives are emerging. One of those is Podman.

I know you’re all excited to hear about Podman, but to understand why such a new alternative tooling exists, we need to know what Docker is and what it does.

Docker is a pioneer in Linux container technology. In 2013 they started the development of a containerised application model, which changed the landscape of software development and delivery ever since.

Why was Docker created?

Docker, an open-source containerization technology, enables developers to package their applications and dependencies into standardized, lightweight containers, effectively solving the problem of software dependencies and streamlining application development. These containers can be readily deployed and run on any Docker-enabled systems, regardless of the underlying operating system or hardware. Additionally, Docker offers isolation and scalability features that simplify the management and scaling of distributed applications.

What is Docker?

Docker is both the name of a technology and the name of a company that was founded in 2010. When we talk about technology, it is composed of these core components.

  • Docker Engine or docker daemon which is a background process that runs on the host machine and manages the lifecycle of Docker containers. Aside from providing the API and command-line interface or CLI, it also sets up the networking for containers, manages the storage of data in the host system and it provides security features that isolate the containers from each other and from the host system.
  • Another critical component of Docker is the Docker container runtime which is the software that actually runs the docker container themselves.
  • Docker also incorporated the two above, Docker CLI and other tools in Docker Desktop which is an application that provides a user-friendly GUI for building, testing and deploying docker container applications on a local machine.


Teams have benefited from these technologies to rapidly develop and operate in an environment that is very close to production. One of its advantages is the code’s ability to execute in various environments, including physical and virtual computers, as well as the cloud. In addition to running in isolation from the host system, Docker engine manages the containers resources including the file system, network interface, RAM, CPU and more. Docker engine also handles container modularity that enables application systems to be broken down into smaller, easier-to-manage components. This simplifies the development and testing while easily facilitating the scaling up and down production applications.

Is Docker the only tooling in this containerisation field?

Docker technology is still the leading player in containerisation land, but slowly the competitions are catching up. For some people, containers and images are synonymous with Docker but these technologies are not exclusive to Docker. There are projects that follow The Open Container Initiative or OCI and create alternative tools that challenge Docker as the de facto in application containerisation space.

In this blog I am going to focus on Podman as an alternative tool to Docker and Docker desktop, and discuss their differences and similarities.


Podman (or the POD manager) is an open-source and OCI-compatible containerisation tool that claims to be more secure, flexible and lighter. RedHat released Podman in 2018 as a Docker alternative, which quickly gained popularity among developers and DevOps engineers due to its lightweight nature and robust security features. It comes with Podman CLI and Podman Desktop which has all the things you need to develop and run containers in any platform.

Running a container

These are the example commands of running a container with the image localhost/my-node-app using Docker and Podman.


# Using Docker
$ docker run –name docker-node-js-container -p 3000:3000 localhost/my-node-app
$ docker ps
5e73f71a0cb3   localhost/my-node-app:latest   “node app.js”   50 seconds ago   Up 49 seconds   3000/tcp   docker-node-js-container
$ docker stop 5e73f71a0cb3

# Using Podman
$ podman run –name docker-node-js-container -p 3000:3000 localhost/my-node-app
$ podman ps
CONTAINER ID  IMAGE                     COMMAND  CREATED    STATUS     PORTS               NAMES
1f00579fe43d  localhost/my-node-app:latest  node app.js  9 seconds ago  Up 10 seconds>3000/tcp  podman-node-js-container
$ podman stop 1f00579fe43d


Podman has a daemonless architecture, which is designed to run without a central daemon process. This is unlike Docker, which uses dockerd daemon where all processes are part of a larger daemon process.

Under the hood, Podman runs containers on individual child processes to manage the container’s system resources. This improves the security because each container is isolated so a compromised container won’t propagate the attack to other processes or in the host machine.

In addition, Podman also uses a client-server architecture in which the Podman client interacts directly with the container runtimes runc or conmon. As a result, Podman containers don’t require a background process to run continuously or to use up system resources; instead, they can be started and stopped whenever necessary.


Rootless. Podman is the first tool to adopt a rootless mode in containers and became its fundamental feature. This allows non-root users to run containers without elevated privilege. In terms of security, Podman follows the least privilege principle, which advocates granting specific permissions to applications rather than full access.

In a compromised Docker container, the attacker can elevate its privilege and can target the host system. If a Podman container is compromised, it can still deal damage to the system but it is limited to the capabilities of a non-root user.

In the previous versions of Docker, it allows root privileges to run containers which can create security risks and operational issues. But Docker started to experiment with the rootless mode feature in Docker engine version 19.03, it was stabilised in December 2020 and now part of the Docker toolset since version 20.10.

Building images

Podman is specialised in running containers, but with the help of another open-source tool called Buildah, it can also build images within the Podman CLI. Buildah is also OCI-compatible, so any of your Dockerfile can be built to a container image right away without changing any codes.

The Docker ecosystem already comes with the ability to build container images in Docker CLI and you don’t have to worry about installing another dependency for this purpose.


# Using Docker
$ ls
Dockerfile   app.js   package.json yarn.lock
$ docker build -t my-node-app .
Sending build context to Docker daemon  88.06kB
STEP 1/7: FROM node:16
STEP 2/7: WORKDIR /usr/src/app
–> 4a8fe550d3a5
STEP 3/7: COPY package*.json ./
–> 959ec3788496
STEP 4/7: RUN npm install

added 58 packages, and audited 59 packages in 9s

8 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
npm notice
npm notice New major version of npm available! 8.19.4 -> 9.6.6
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v9.6.6>
npm notice Run `npm install -g npm@9.6.6` to update!
npm notice
–> 00f9d76c072b
STEP 5/7: COPY . .
–> 61e044e5d1da
STEP 6/7: EXPOSE 3000
–> 1d3ba2e64ad3
STEP 7/7: CMD [ “node”, “app.js” ]
COMMIT localhost/my-node-app:latest
–> eb3cab3e3db2
Successfully tagged localhost/my-node-app:latest
Successfully built eb3cab3e3db2
Successfully tagged my-node-app

# Using Podman
$ podman build -t my-node-app .
STEP 1/7: FROM node:16
STEP 2/7: WORKDIR /usr/src/app
–> Using cache adb9a7b79444d309f5309cb4d15e05a132c76cc6d2b7c77842e194a5ec92156e
–> adb9a7b79444
STEP 3/7: COPY package*.json ./
–> Using cache 40e0b16a844ea6619abe9345667d952ce9074039d9490b8810d4f515f4234459
–> 40e0b16a844e
STEP 4/7: RUN npm install
–> Using cache 3f712ae3adbab266faf4eb6b863ed89b9fc571992e4bbf53a4538a940c3a0bba
–> 3f712ae3adba
STEP 5/7: COPY . .
–> Using cache a38ee14a46bd7a622f5574bee939bff28b2ed2fdf49e43374f125146a7cf94de
–> a38ee14a46bd
STEP 6/7: EXPOSE 3000
–> Using cache 77e4cb844f2508df3b9e72040af73a267591b143977c2a4a2fc137425b474896
–> 77e4cb844f25
STEP 7/7: CMD [ “node”, “app.js” ]
–> Using cache 2954473d869bbe6a225c246255b5a1799ecf95e307d14670850365a6bed458fd
COMMIT my-node-app
–> 2954473d869b
Successfully tagged localhost/my-node-app:latest


Within the Docker ecosystem, Docker Swarm and Docker Compose serve as tools for container orchestration. Docker’s tooling is obviously more mature and has been the go-to solution for a lot of people. On the other hand, The Podman community developed Podman Compose, a lightweight tool focused on running Podman commands directly, offering essential orchestration capabilities. Furthermore, you can generate Podman codes to make it runnable in Kubernetes if that’s your orchestration tool of choice.

The Podman-compose team provided an example of a simple two-tier application using docker-compose.yaml. It creates two containers or services, one is a Redis database and the other is a web application with python as a back-end. It’s a simple application that counts every page visit, it records and retrieve the data in Redis.

Podman-compose demo


# Using docker-compose
$ docker-compose up -d
[+] Running 1/8
⠴ web Pulling
⠿ redis Pulled
  ⠙ ca04d454c47d Download complete
  ⠇ 08409d417260 Download complete
  ⠦ e438114652e6 Download complete
  ⠴ 80fd0bfc19ad Download complete
  ⠴ 35afda5186ef Download complete
  ⠴ ebab1fe9c8cc Download complete
  ⠋ b64252cb5430 Download complete
=> [internal] load build context
=> => transferring context: 1.91kB
=> [2/5] WORKDIR /usr/src/app
=> [3/5] COPY requirements.txt ./
=> [4/5] RUN pip install –no-cache-dir -r requirements.txt
=> [5/5] COPY . .
=> exporting to docker image format
=> => exporting layers
=> => exporting manifest sha256:ffe4a15cd79725e1699b38b5ca5f42a5e2654b065d1d630f74024606bb7415f8
=> => exporting config sha256:f05731bf754286c0f5dab16017f580d6d8dda0a18175755e4b039ac4c5d15b8d
=> => sending tarball
=> importing to docker
[+] Running 3/3
Network hello-python_default    Created
⠿ Container hello-python-redis-1  Started
⠿ Container hello-python-web-1    Started

# Using podman-compose
$ podman-compose up -d
podman-compose version: 1.0.6
[‘podman’, ‘–version’, ]
using podman version: 4.5.0
** excluding:  set()
[‘podman’, ‘inspect’, ‘-t’, ‘image’, ‘-f’, ‘{{.Id}}’, ‘hello-py-aioweb’]
Error: inspecting object: unable to inspect “hello-py-aioweb”: failed to find image hello-py-aioweb: hello-py-aioweb: image not known
podman build –f ./Dockerfile -t hello-py-aioweb .
STEP 1/7: FROM python:3.9-alpine
Resolved “python” as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/python:3.9-alpine…
Getting image source signatures
Copying blob

STEP 5/7: COPY . .
–> 5a10210fa778
STEP 6/7: CMD [ “python”, “-m”, “app.web” ]
–> ff2ff52c502e
STEP 7/7: EXPOSE 8080
COMMIT hello-py-aioweb
–> 17e2c72f2444
Successfully tagged localhost/hello-py-aioweb:latest
exit code: 0

[‘podman’, ‘network’, ‘exists’, ‘hello-python_default’]
podman run –name=hello-python_web_1 -d —readonly –label io.podman.compose.config-hash=018b2aa823efe20b9a7028e87c264668d3e92c1d52d052f1f736a7e520764c5a –label io.podman.compose.project=hello-python –label io.podman.compose.version=1.0.6 –label PODMAN_SYSTEMD_UNIT=podman-compose@hello-python.service –label com.docker.compose.project=hello-python –label com.docker.compose.project.working_dir=/Users/code/Sites/podman-compose/examples/hello-python –label com.docker.compose.project.config_files=docker-compose.yaml –label com.docker.compose.container-number=1 –label com.docker.compose.service=web –e REDIS_HOST=redis –net hello-python_default –network-alias web –p 8080:8080 hello-py-aioweb
exit code: 0

Desktop Application

Docker developed Docker Desktop which is a user-friendly GUI (Graphical User Interface) to help developers manage containers, applications, and images directly on their local machines, it can be used side by side with the Docker CLI. In August 2021, Docker implemented a paid licensing model in their product. In a nutshell, smaller companies can still enjoy using Docker Desktop without paying for a subscription but larger companies need to pay and they will get added features and support. You can learn more about the pricing model on their FAQ page.

In October 2022, at KubeCon North America 2022, the Podman community announced Podman Desktop. Podman Desktop is an open-source graphical tool enabling you to seamlessly work with containers and Kubernetes from your local environment. It is available in Windows, MacOS and Linux. This tool directly competes with Docker desktop and it even has documentation to migrate from Docker.

Podman Desktop also has a Docker compatibility mode that allows Podman to be used as a drop-in replacement for Docker. It uses the Docker socket helper included with Podman to manage the local configuration of the Podman path to the Docker socket.

Monolithic vs Modular

Docker offers an all-in-one OCI-compatible ecosystem that includes all the things you need in software development and delivery. This will save you a lot of time from trying and deciding different tooling in the container development workflow.

In contrast, Podman is just a small unit in the open-source container ecosystem; it requires third-party specialised tools to have a complete ecosystem. As we have learned so far, the community has built its orchestration and desktop application, you can even switch the orchestration to Kubernetes or Nomad or you can fully use Buildah to build images. Having a modular tooling lets you have the freedom to explore different technologies and choose the best for you.

Podman in the Cloud


Podman runs on major Operating Systems and you can definitely run it on the popular Amazon Linux on EC2, Ubuntu, RedHat and more. This AWS blog explains how to configure and mount an Amazon EFS file system to a Podman container, enabling the container to access shared file storage. The article also provides step-by-step instructions and examples to help users implement this integration successfully.

For anyone who’s using containers and RedHat in AWS, Podman is well integrated with the RedHat ecosystem. As a matter of fact they have a dedicated documentation on how to build, run and manage containers using the Podman toolset.


If your workload is small and simple enough then this solution can be right for you. However, you cannot use Podman in AWS ECS which is a managed AWS service. As of writing, ECS still relies on Docker technology to manage containers. On the other hand, Podman can still work with AWS EKS but it’s not a straightforward task.

RedHat OpenShift Service on AWS

Podman also works well with RedHat Openshift, which is a managed service on premise or in AWS. RedHat OpenShift Service on AWS or ROSA offers a managed Red Hat OpenShift service that runs natively on Amazon Web Services (AWS), enabling businesses to build, deploy, and scale applications more quickly while also refocusing on innovation.


As the name suggests, Podman might remind you of Kubernetes pods. Well, Podman runs and manages containers that are similar to Kubernetes. Podman pod is a group of one or more containers that are deployed together on the same hosts and share the same network namespace.

If you have a Kubernetes workloads in the cloud, you might want to know that the Kubernetes team has moved away from Docker as the default container runtime since v1.24 in favour of Open Container Initiative (OCI) compatible image specification and Podman is compliant with it. According to the Kubernetes press release:

If you’re using a managed Kubernetes service like Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE), you will need to make sure your worker nodes are using a supported container runtime before Docker support is removed in a future version of Kubernetes.

- Don’t Panic: Kubernetes and Docker

Other notable players in the OCI space

Minikube – is a local Kubernetes solution, focusing on making it easy to learn and develop for Kubernetes. It can run on Windows, MacOS and Linux.

LXD – a next generation system container and virtual machine manager in Linux distributions. It offers a unified user experience around full Linux systems running inside containers or virtual machines.

Rancher Desktop – An open-source desktop application for Mac, Windows and Linux. Rancher Desktop runs Kubernetes and container management on your desktop. 

Final Thoughts

For individuals who are keen to explore, teams that are starting out on a new project, or businesses that are required to leave the Docker ecosystem, Podman can be a good fit and a great alternative to operate OCI-compatible containers and images. However, moving away from Docker can be a complex and challenging process.

Migrating to a new solution is not just all the bells and whistles. Whether it offers better security or it’s cost effective, it is still best to take a backseat, talk to the stakeholders, technical and business people and discuss some of the following considerations:

  • Learning curve – A new tool brings with it new unknowns. You must understand your team’s skills and how quickly they can comfortably adjust to this new tool, as well as the risks and impact on your team’s development and delivery.
  • Compatibility – There are alternate toolings that are drop-in replacement to Docker while there are some that may need configurations to work properly You must extensively verify the Docker alternative’s compliance with your present development workflow and production workloads. During the changeover, a hybrid configuration is also a possibility.
  • Support – When you use free and open source (FOSS) software, you are enjoying it for free, but you must ensure that the community of that tool is mature and that you are receiving adequate assistance.
  • Security – Although Podman claims to be the more secure container technology, Docker may not be far behind. If you are needed by a compliance agency to improve your security in a way that Docker cannot, then an alternative option may be appropriate for you.
  • Integration – You must have built up your development and CI/CD with Docker; if you’re switching to another solution, you’ll need to spend a significant amount of time rewriting your code to work with your current CI/CD, as well as additional time testing the new solution from development through delivery.
  • Cost Savings – Large businesses can utilise Podman to save licensing fees instead of purchasing Docker subscription. It goes without saying that there are more considerations when switching to a new tooling, thus the decision to forego utilising Docker must be thoroughly considered.

Enjoyed this blog?

Share it with your network!

You may also like

Move faster with confidence