Docker vs Podman vs containerd: Container Runtimes Compared

Three tools, three different layers of the same stack. Knowing which layer each one occupies is the whole answer.

Docker — the original full-stack container platform

• Provides a CLI, a build system, a daemon (dockerd), and image registry tooling all in one product; runs as root by default and requires the daemon to be running for any container operation
• Still the most widely-used local development tool because Docker Desktop has the best macOS and Windows polish; the licensing change in 2021 (paid for companies above 250 employees) accelerated migration to alternatives
• Under the hood, modern Docker uses containerd as its runtime — the dockerd daemon now mostly translates Docker-specific concepts to containerd calls

Podman — the daemonless, rootless alternative

• Drop-in CLI compatibility (alias docker=podman works for 95% of commands); the differences appear in compose files, healthcheck parsing, and edge-case volume behavior
• Daemonless model means each podman run is its own process; combined with rootless mode, a compromised container cannot escalate to root on the host — the security default on Red Hat distributions
• First-class pod abstraction (matching Kubernetes pods) and systemd integration via Quadlet make Podman a better fit for single-host production than docker-compose

containerd — the runtime under everything

• Implements the Container Runtime Interface (CRI) that Kubernetes uses to manage pods; since K8s 1.24 removed the dockershim, containerd is the standard CRI runtime in EKS, GKE, AKS, and most self-managed clusters
• You rarely interact with containerd directly — nerdctl is a Docker-compatible CLI for it; ctr is the low-level CLI mostly used for debugging
• The shift from dockershim to containerd was invisible to almost all workloads: OCI images, Kubernetes manifests, and application code all behave identically