Ditching Docker: Why Podman’s Rootless, Daemonless Model Wins

The author argues that Docker’s root-privileged daemon is an avoidable risk and operational liability, pointing to notable CVEs and API-abuse incidents. Podman’s daemonless, rootless model improves security, resilience, and system integration while maintaining Docker-like CLI compatibility. A practical FastAPI migration guide shows that moving is straightforward and yields better production operations via systemd, pods, and Kubernetes-aligned tooling.

Key Points

Docker’s root-privileged, always-on daemon increases attack surface and creates a single point of failure; recent CVEs and API-abuse campaigns underscore the risk.
Podman’s daemonless, rootless-by-default model reduces host compromise risk, isolates failures, and trims idle resource usage.
Podman integrates cleanly with Linux operations: systemd unit generation, native pods, and Kubernetes-aligned workflows (generate/play kube).
Switching is largely seamless: Podman mirrors Docker’s CLI, works with existing Dockerfiles, and can expose a Docker-compatible socket when needed.
A step-by-step FastAPI guide demonstrates parity (build/run), better production management with systemd, pod-based multi-service setups, and practical fixes for ports, volumes, and legacy tooling.

Sentiment

The community is moderately positive toward Podman's design philosophy, recognizing rootless and daemonless operation as genuine improvements over Docker's architecture. However, enthusiasm is tempered by pragmatic concerns about real-world compatibility gaps, particularly around Docker Compose, distribution packaging outside the Red Hat ecosystem, and edge-case container incompatibilities. The prevailing tone is constructive and technically nuanced rather than dogmatic, with many commenters expressing variants of 'I prefer Podman in principle but Docker still works better for my specific needs.' OrbStack on macOS and alternative container approaches also receive notable support as competing solutions to the same problems.

In Agreement

Podman's rootless daemonless architecture genuinely reduces attack surface by eliminating the persistent root daemon that Docker requires
Docker Desktop's commercial licensing changes make Podman an attractive free alternative for organizations
The CLI is nearly a drop-in replacement for Docker making migration straightforward for basic use cases
Systemd integration via quadlets and socket activation is elegant and production-ready
Rootless containers are essential for multi-tenant HPC environments where users cannot have root access
Podman's fork/exec model means containers survive independently and there is no single point of failure
Resource usage is lower without a persistent daemon running in the background

Opposed

Docker Compose compatibility is incomplete with podman-compose missing key features like watch and some service conditions
Ubuntu and Debian ship outdated Podman versions and lack official package repositories making installation difficult outside the Red Hat ecosystem
SELinux combined with rootless containers and non-root users creates complex permission issues that frustrate even experienced administrators
Volume and filesystem permissions with user namespace remapping remain a known pain point requiring workarounds
Some containers that assume root access simply do not work correctly in rootless mode requiring dual rootful/rootless setups
GPU passthrough and buildx support are weaker or unreliable compared to Docker
Third-party tools that interact with Docker's socket API do not always work with Podman's compatibility layer
Docker itself now supports rootless mode reducing one of Podman's key differentiators