Learn Podman - History, Background & Why You Need Podman

#Introduction

In episode 0 you set up a Podman environment on Linux or macOS and ran podman --version for the first time. Now it's time to ask: where did this tool come from, and why should you care? Episode 1 tells the history and background of Podman, then maps out the problems it set out to solve.

By understanding the reasons behind Podman's birth, you will find it easier to predict the design of every command you'll learn in later episodes. Most of Podman's design decisions are direct answers to a single problem in Docker.

Keep this pattern in mind as you read the series — almost every Podman feature can be traced back to one concrete problem it was designed to solve.

#A Brief History of Podman

Podman was born at Red Hat, built on top of two other projects: libpod, the core library for managing containers and pods, and containers/common, which contains shared configuration such as registries and storage. Together they gave birth to Podman as a complete container engine.

Podman's emergence was initially a response to Docker. Docker popularized containers, but its design used a central daemon running as root. Podman came as a daemonless alternative: each container is handled directly without a daemon process supervising all containers at once.

Podman's evolution can be summarized in the following table:

Version	Year	Key Points
Podman 4	2022	Maturity of pods and networking features
Podman 5	2024-2025	Networking and tooling refinements
Podman 6.0	June 2026	Latest major release with continued development

In addition, the Podman project is on track toward CNCF incubation — recognition as a community-managed cloud-native project. This signals that Podman is not a passing experiment, but a project with a growing ecosystem and support.

#The Ecosystem Around Podman

Podman was not built in isolation. It grew within Red Hat's container project ecosystem, developed openly and in a coordinated way. Its foundation is shared libraries:

libpod — the library that acts as Podman's brain in managing containers and pods.
containers/common — shared configuration and utilities, including registry and storage settings.

Because this foundation is open and shared, other tools like Buildah and Skopeo speak the same format. As a result, you can mix commands from different projects without worrying about format incompatibilities — something that will be demonstrated directly in episode 2.

#Problems It Solves

Podman's presence answers four major problems inherent in Docker's design.

#No Daemon: Safer and Lighter

Docker uses a client-server architecture: a daemon runs continuously, and every client command communicates with it. Podman removes that layer.

Aspect	Docker	Podman
Architecture	Client-server with a central daemon	Daemonless, direct fork/exec
User	Daemon runs as root	Rootless by default
Daemon lifecycle	Containers depend on the daemon	Containers run without a daemon
Attack surface	Root daemon is the main target	No daemon waiting to be attacked

Without a daemon, there is no central process always running as root — so the attack surface is smaller and the footprint is lighter. This fork/exec model will be dissected further in episode 2.

#Rootless by Default

With Docker, container operations generally require root privileges because the daemon runs as root. Podman flips this assumption: regular users can run containers without sudo, thanks to user namespace remapping. You will learn the mechanics in episode 5.

#Kubernetes-Style Pods

Podman borrows the pod concept from Kubernetes: a group of containers that share a network namespace and resources. This bridges the mindset of developers who write Kubernetes deployments with the same tools on their laptops. The pod concept will be explained in episode 6.

#Drop-in Docker-Compatible CLI

Podman commands are deliberately made as close to Docker's as possible:

CLI comparison

docker run -d -p 8080:80 nginx:latest
podman run -d -p 8080:80 nginx:latest

You can even create an alias so your docker typing habit keeps working:

Aliasing docker to podman

alias docker=podman

With this compatibility, anyone already familiar with Docker can be productive with Podman immediately, without learning from scratch.

Note

podman run -d -p 8080:80 nginx:latest will be used as a recurring example in this series. Get used to reading it: -d runs in the background, -p maps a host port to a container port, and nginx:latest is the image name.

#Summary of Problems and Solutions

To make it easy to remember, here is a map from problem to Podman's answer:

Problem in Docker	Podman's Answer
Root daemon always running	Daemonless, fork/exec
Needs sudo to run containers	Rootless by default
Single-container mindset	Kubernetes-style pods
Proprietary CLI	Drop-in Docker-compatible

Whenever you encounter the question "why is this command designed this way", try to trace it back to the table above — there is almost always a Docker problem being answered.

Tip

If you come from Docker, don't throw away old habits — bring them along. alias docker=podman in ~/.bashrc makes the transition feel seamless while you absorb the daemonless concept little by little.

#Closing

Episode 1 answers the question "why Podman": born at Red Hat on top of libpod and containers/common as a daemonless answer to Docker, evolving from Podman 4 to 6.0, heading toward CNCF incubation, and solving the problems of a root-running daemon, the need for sudo, the pods mindset, and CLI compatibility.

The key points to take home:

Daemonless is the main differentiator — no central daemon means safer and lighter.
Rootless by default — regular users run containers without sudo.
Kubernetes-style pods — Podman bridges the laptop to the cluster.
podman run -d -p 8080:80 nginx:latest is a line you will come to know well.

The next episode, Episode 2, unpacks the architecture behind the daemonless claim: how each container is launched directly by the runtime as a child process, who the members of the ecosystem are, and why adherence to OCI standards makes it all interoperable.