Learn Podman - Core Concepts & Key Architecture

#Introduction

Episode 1 explained why Podman exists: as a daemonless alternative to Docker. Episode 2 opens the hood — how the daemonless architecture really works, who the ecosystem components are, and why OCI standards connect everything together. After this, you will no longer see Podman as just a command, but as an architecture.

#Daemonless and Fork/Exec

Podman's main claim is that it uses no daemon. How is that possible? The model used is called fork/exec.

When you run the podman run command, the flow looks like this:

1. The podman client does a series of preparation steps: reads configuration, prepares storage, and loads the image.
2. The client process forks a child process, which then executes the container runtime.
3. The runtime — either crun or runc — runs the container as a child process directly from that process.
4. The small conmon process monitors the container, forwards logs, and keeps the container from becoming a zombie process.

Because there is no central daemon, each container is a direct descendant of the process that requested it. Compare that with Docker, which must communicate with an always-running daemon:

#Two Runtime Options

Podman supports more than one runtime, and both are implementations of the same standard:

• crun — written in C, tends to be lighter and faster; it's the default on many modern distros.
• runc — written in Go, the runtime Docker itself has used for years.

The difference in programming language doesn't change the behavior from your perspective — both run containers according to the same standard. What matters is that both run as child processes, not under a single daemon.

You can prove this model yourself: run a container, then observe its processes from the host:

podman run -d --name web nginx:latest
ps -ef | grep conmon
ps -ef | grep nginx

You will see the conmon process and the nginx process running as regular processes on the host — not under a single daemon process. This is the most tangible proof of the fork/exec model.

#The Container Project Ecosystem

Podman is just one of several projects that make up Red Hat's container ecosystem. Each holds a specific role:

This division of roles lets each project focus on one job: Podman for runtime operations, Buildah for building images, Skopeo for moving images, and CRI-O for Kubernetes' container engine.

#Relationships Between Projects

These projects don't work in silos. A concrete example of their collaboration:

• Buildah builds, Podman runs — images built by Buildah are consumed directly by Podman without conversion, because both share the same image format.
• Skopeo moves, Podman uses — Skopeo can copy images between registries and even between formats, and the result is then pulled by Podman.
• CRI-O in the cluster, Podman on the laptop — both use the same OCI runtime, so images that run on Podman also run on Kubernetes.

This workflow is why you often see Podman, Buildah, and Skopeo installed side by side on one machine. In episode 4, you will use Skopeo directly.

#Storage and Registry Config

Behind the scenes, Podman reads configuration to determine where images are stored and where they come from. Storage is managed in containers/storage, while registries are managed through registries.conf:

registries.conf

[registries.search]
registries = ["docker.io", "quay.io"]
 
[registries.insecure]
registries = []

registries.search determines the registry search order when you pull an image without a full prefix, like podman pull nginx. The insecure section holds registries allowed to use HTTP without TLS — it's best to leave it empty in a production environment.

#OCI Compliance

For all these projects to work together, there is one binder: the standards from OCI (Open Container Initiative). There are two core specs that matter:

• Runtime spec — defines how a container is executed: namespaces, cgroups, mounts, and what process runs. crun and runc are implementations of this spec.
• Image spec — defines the image format: how layers are structured, manifests, and metadata. Images that comply with this standard can be run by any runtime that also complies.

This OCI compliance is what lets you run images built with Buildah using the crun runtime, or images from Docker Hub loaded into Podman.

Its most important side effect is compatibility with Kubernetes: because CRI-O uses the same runtime and image format, containers you run on your laptop with Podman can move to a Kubernetes cluster without format changes. This same standard is also what lets Docker and Podman share images with each other.

#Closing

Episode 2 reveals Podman's architecture: the fork/exec model that runs each container directly via the crun or runc runtime as a child process with no central daemon, the Podman-Buildah-Skopeo-CRI-O ecosystem where each has its own role, and the OCI standard that unifies them all.

The key points to take home:

• Fork/exec replaces the daemon — each container is a child process of the process that requested it.
• Ecosystem separated by role — Podman runs, Buildah builds, Skopeo moves, CRI-O serves Kubernetes.
• OCI is the bridge — runtime spec and image spec make images work across runtimes and tools.
• registries.conf controls where Podman looks for images.

The next episode, Episode 3, gets down to practice: you'll start living with the basic container management commands — run, pull, ps, logs, exec, inspect, stop, rm, stats — plus lifecycle and cleanup.