Podman guide

What Podman does in production

Podman runs containers the same way Docker does at the OCI level — images, layers, namespaces, cgroups — but without a long-running dockerd daemon. Containers can run as your user (rootless) instead of requiring root or the docker group. That model fits hardened servers, systemd services, and environments where a shared daemon socket is undesirable.

Podman vs Docker

• No daemon — Podman CLI talks to storage and runtime directly; no /var/run/docker.sock
• Rootless by default — run containers as a normal user on supported distros
• Docker-compatible CLI — most docker commands have podman equivalents
• Pods — group containers sharing network/namespace (Kubernetes-like)
• systemd native — generate unit files; Quadlet for declarative services

Shared concepts (images, volumes, networks, Compose) are covered in the Docker lab. This guide focuses on Podman-specific behavior.

How a container runs (daemonless)

When you podman run:

1. Image resolve — pull or use local image from container storage
2. Conmon — tiny monitor process supervises the container lifecycle
3. crun/runc — OCI runtime creates namespaces and starts the workload
4. Storage — overlay (or fuse-overlayfs rootless) for filesystem layers
5. Networking — CNI plugins attach the container to a virtual network
6. Exit — container stops when PID 1 exits; conmon records state for podman ps

Rootless containers

Rootless Podman maps container UIDs to unprivileged host UIDs via /etc/subuid and /etc/subgid. Storage lives under ~/.local/share/containers/. Networking uses slirp4netns or pasta (user-space) instead of bridge setup requiring root. Some operations differ: binding privileged ports (< 1024) needs root or sysctl caps; volume permission mapping needs attention.

Check mode: podman info | grep -i rootless.

Storage and image tooling

• Podman — run and manage containers
• Buildah — build images (often podman build wraps Buildah)
• Skopeo — copy and inspect images between registries and storage without running containers

Image storage: rootful /var/lib/containers/storage; rootless under the user's home. List with podman images; prune with podman system prune.

Pods

A pod is a group of containers sharing the same network namespace (and optionally IPC/PID). Create with podman pod create, add containers with --pod. Useful for sidecar patterns and mirroring Kubernetes pod semantics on a single host.

Compose and Kubernetes YAML

podman compose (Compose v2 plugin) runs docker-compose.yml stacks using Podman as the backend. podman play kube runs Kubernetes pod/deployment YAML locally — handy for testing manifests without a cluster.

systemd and Quadlet

Generate a user or system unit from a container: podman generate systemd --name mycontainer --files. Drop the unit in ~/.config/systemd/user/ (rootless) or /etc/systemd/system/.

Quadlet (.container, .volume, .network files in /etc/containers/systemd/) lets systemd start containers declaratively on boot — common on Fedora/RHEL for production services.

Docker socket compatibility

podman socket can expose a Docker-compatible API socket for tools that expect docker.sock (some CI scripts, language Docker clients). Rootless socket is at /run/user/UID/podman/podman.sock. This is optional — native podman CLI is preferred.

Production practices

• Prefer rootless where possible — smaller blast radius than rootful daemon
• Pin image tags — same as Docker; avoid drifting latest
• Log to stdout — podman logs for journal integration
• Auto-restart — --restart=always or systemd/Quadlet for persistence
• Update storage — podman auto-update for registry-driven rollouts (with labels)

Learning resources

• Podman documentation — docs.podman.io
• Rootless tutorial — podman — rootless
• Quadlet — docs.podman.io — systemd units
• Docker lab (shared concepts) — SadServers Docker lab