Podman and Buildah

Podman runs the same OCI images with a Docker-compatible CLI, but with no central daemon: each podman run forks the container as a child of your shell, and it runs rootless by default. That architectural difference removes the root-owned dockerd socket that Chapter 1 and Chapter 10 flagged as a root-equivalent risk.

Where Docker bundles build, run, and image transfer into one binary, Podman splits them across focused tools: Podman runs, Buildah builds, and skopeo moves images between registries and stores. Three tools, the same OCI artifact, no always-on root process owning everything.

Daemonless, Fork/Exec

There is no podman daemon owning your containers. Podman forks and execs each container directly via runc or crun, so a crashed Podman does not take the containers with it, and there is no always-on root socket to compromise. The container is a child of the process that launched it, which is a smaller attack surface and a simpler failure model than a central daemon that everything routes through.

$ podman run -d -p 8080:8080 \
    --name driftwood-web \
    registry.driftwood.example/driftwood/web:1.4.0
$ podman ps

# most existing Docker commands work unchanged:
$ alias docker=podman
$ docker build -t driftwood/web:1.4.0 .

# run a Linux host's containers as services, surviving logout/reboot:
$ podman generate systemd --new --name driftwood-web > driftwood-web.service

The alias covers the common path, but it is not byte-identical to Docker — Compose, the socket API, and a few flags differ. Treat alias docker=podman as a strong default that you verify, not a guarantee, especially for any script that talks to docker.sock directly.

Rootless by Default

Podman runs as your user using user namespaces — the rootless model Chapter 10 presented as an opt-in is Podman's default. A container breakout therefore lands as an unprivileged user, not as host root, which shrinks the blast radius of an escape to whatever your own account can touch. This is the single biggest reason to reach for Podman on a multi-user or hardened host: there is no root daemon to compromise in the first place.

Pods — A Kubernetes-Shaped Primitive

Podman groups containers into a pod sharing a network namespace — the same concept Kubernetes uses, and the source of the name. podman generate kube emits Kubernetes YAML from running containers, and podman kube play runs a Kubernetes manifest locally. That round-trip makes Podman a natural on-ramp to the sibling Kubernetes course: you model the workload in the same shape locally before a cluster ever enters the picture.

Buildah and skopeo — Unbundled

Buildah builds OCI images, either from a Dockerfile or scriptably step by step without a full Dockerfile at all. skopeo inspects and copies images between registries and stores without a daemon and without running anything — skopeo copy moves driftwood/web from one registry to another, and skopeo inspect reads a manifest without pulling it. Docker folds these jobs into one engine; Podman splits them into tools you can use independently in CI.

systemd and Quadlet — Running Containers as Services

Because there is no daemon to own restarts, Podman integrates with systemd. A Quadlet unit file declares a container as a native systemd service with restart policies and dependencies, so the OS — not a container daemon — handles bringing Driftwood's containers up at boot and back after a crash. A container started loose in your shell does not survive logout; a Quadlet unit survives logout and reboot because systemd owns it.