Learn Podman - Images & Registry

#Introduction

Episode 3 covered container management. Episode 4 steps up to something more upstream: images — the raw material of every container. You'll learn to pull and push images, tag them, save and load them as files, read layer history, and use manifests for multi-architecture images.

#Working with Images

An image is a read-only blueprint. One image can be used to create many containers, and a container only adds a thin writable layer on top of it. Podman's image commands:

#Pull, Push, and Tag

The most basic flow is pulling an image, tagging it, and pushing it to a registry:

podman pull quay.io/nginx/nginx:latest
podman tag quay.io/nginx/nginx:latest myrepo/nginx:v1
podman push myrepo/nginx:v1

podman tag doesn't duplicate the image — it only adds a name reference. One image can have many tags at once. podman push sends the image to a registry, usually requiring authentication via podman login.

#Save and Load

Sometimes you need to move an image without a registry — for example between servers on an offline network. Podman provides two file storage formats:

podman save --format oci-dir -o nginx-image nginx:latest
podman load -i nginx-image

podman save -o nginx-image writes the image to a directory, podman load -i nginx-image reads it back into local storage. The docker-dir format is useful when the image will be read by tools that don't support OCI yet.

#History, RMI, and Layers

Images are made of stacked layers. To see how an image was built layer by layer:

podman history nginx:latest
podman images

podman history shows every layer, the command that created it, and its size. podman images lists local images with size and tags. To remove an image you no longer use, use podman rmi. Shared layers (for example the same base image) are stored only once in storage — this is why dozens of containers from the same image stay space-efficient.

#Multi-Arch Manifest

Modern images aren't always a single architecture. A manifest holds a list of image variants for different architectures — for example amd64 and arm64 — under one reference. This is what makes podman pull nginx automatically fetch the version that matches your architecture.

#Creating a Manifest

With podman manifest you can combine several images into one multi-arch manifest:

podman manifest create myapp
podman manifest add myapp myapp:amd64
podman manifest add myapp myapp:arm64
podman manifest push myapp docker.io/myrepo/myapp:latest

podman manifest create creates an empty manifest, podman manifest add adds one image per architecture, and podman manifest push sends it to the registry as a single reference.

#Inspecting with Skopeo

To inspect a manifest or image in a registry without pulling it into local storage, Skopeo is the right tool:

skopeo inspect docker://quay.io/nginx/nginx:latest
skopeo inspect --raw docker://myrepo/myapp:latest

skopeo inspect shows image metadata like architecture, layers, and labels. skopeo inspect --raw shows the raw manifest — useful for viewing the list of variants in a multi-arch manifest.

#Image Digest

Every image has a digest, a unique hash of the image's content. Unlike a tag, which can be moved to another image, a digest refers to the same content forever.

podman images --digests

The DIGEST column in the output shows that hash value. You can pull an image by digest reference, for example podman pull nginx@sha256:... — a format that guarantees the image you get is truly the one you expect.

#Closing

Episode 4 completes image management: pull and push, tags as name aliases, save and load with oci-dir and docker-dir formats, layer history via history, removal with rmi, multi-arch manifests, inspect with Skopeo, and digests as immutable references.

The key points to take home:

• Tags are aliases, digests are identity — tags can change, digests never do.
• Layers share storage — the same base image is stored only once.
• Manifests hold multi-arch — one reference for all architectures.
• podman history opens up how an image was built.

The next episode, Episode 5, dives into rootless and daemonless mode: user namespace remapping, resource limits without sudo, networking with slirp4netns and pasta, and podman machine for macOS and Windows.