Docker vs. Podman: Rootless Containers and the Daemon-less Architecture

Docker popularized containers, but its architecture — a long-running privileged daemon (dockerd) that every docker command talks to over a socket — carries security and operational trade-offs that Podman was built specifically to address. Understanding the actual architectural difference, not just the CLI compatibility, is what determines which one fits a given deployment.

Docker’s architecture: a client talking to a daemon

Every docker command is a thin client sending requests over a Unix socket (/var/run/docker.sock) to dockerd, a long-running background daemon, typically running as root, which itself does the actual work of creating namespaces, cgroups, and managing container lifecycles.

docker run -d --name web nginx
docker ps

That daemon is a single point of failure (if it crashes or is restarted, in older configurations all containers could go down with it) and a significant privilege concentration — anyone who can talk to that socket effectively has root-equivalent access to the host, since the daemon itself runs as root and will do whatever a client asks of it.

Podman’s architecture: no daemon at all

Podman’s podman run directly forks and execs the container process itself — there’s no persistent background daemon brokering the request. Each podman invocation is a self-contained operation, using the same underlying kernel primitives (namespaces, cgroups) but without a privileged intermediary process sitting between the command and the container.

podman run -d --name web nginx
podman ps

This is why Podman containers, once started, are just ordinary child processes of whatever started them (or of systemd, if managed as a service) — there’s no separate daemon process to restart, monitor, or worry about as a shared failure domain across every container on the host.

Rootless containers: the security payoff

Podman was designed from the outset to run rootless — as a completely unprivileged user, using user namespaces to map a container’s internal root (UID 0) to an unprivileged UID on the host, exactly the user-namespace mechanism covered in the Linux namespaces internals.

podman run --rm -it alpine id
# uid=0(root) gid=0(root) — inside the container
# but mapped to an unprivileged host UID outside it

Docker has since added rootless mode too, but it remains a secondary configuration bolted onto an architecture originally built around a root daemon — Podman’s rootless-by-default design reflects that this was the starting assumption, not a later retrofit.

systemd integration: podman generate systemd

Because Podman containers are just processes (not children of a separate daemon), they integrate naturally with systemd as regular supervised services — podman generate systemd produces a real unit file wrapping a container’s lifecycle in ordinary systemctl start/stop/enable semantics:

podman generate systemd --new --name web > /etc/systemd/system/web-container.service
systemctl enable --now web-container.service

This gives containers the exact same restart policies, dependency ordering, and logging integration (journalctl -u web-container) as any other systemd-managed service — no separate container-specific supervision layer required.

Pods: Podman’s Kubernetes-shaped primitive

Podman natively supports pods — groups of containers sharing a network namespace, directly mirroring Kubernetes’ own pod concept, which makes local development against a pod-shaped mental model more direct than Docker’s flatter container/network model:

podman pod create --name mypod -p 8080:80
podman run -d --pod mypod --name web nginx
podman run -d --pod mypod --name sidecar my-logging-agent

CLI compatibility: podman as a drop-in

Podman’s CLI deliberately mirrors Docker’s closely enough that alias docker=podman works for a large share of everyday usage, and Podman also ships a Docker-API-compatible socket mode for tools that specifically expect to talk to /var/run/docker.sock:

systemctl --user enable --now podman.socket
export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock

Choosing between them

For a single-host development environment or CI runner where rootless operation and reduced attack surface matter, Podman’s daemon-less design is a direct security win with essentially the same day-to-day CLI experience. Docker’s daemon-based model still has real advantages in mature, already-Docker-centric orchestration tooling, extensive documentation, and Docker Desktop’s polished cross-platform developer experience — the choice increasingly comes down to whether an organization already has deep Docker-specific tooling investment (favoring Docker) or is optimizing specifically for rootless security posture and systemd-native service integration (favoring Podman), rather than either being categorically better across the board.