Podman: Containers Without a Daemon or Root

Actualizado: 2026-05-03

Podman^[1] is the Docker alternative that has matured most in recent years. Backed by Red Hat and shipped by default on RHEL and Fedora, it’s a technically solid option — especially if security is the priority or you work in environments where a daemon running as root is a problem.

Key takeaways

• The key architectural difference: Podman runs containers as direct child processes of the user, without a central daemon.
• Rootless mode is the main security advantage: a container that escapes doesn’t get host root.
• CLI compatibility with Docker is essentially total; the differences lie in Compose and Swarm.
• Buildah, Skopeo, and Podman are three separate tools where Docker uses one — modularity with CI advantages.
• The most practical coexistence strategy: Podman for development and CI, Docker in production if already established.

The Architectural Difference

Docker has a daemon (dockerd) that runs as root and through which all CLI commands flow. Podman, in contrast, runs containers as direct child processes of the user invoking the command. There is no central service.

Four consequences of this change:

• No single point of failure. If the daemon dies, all containers die. In Podman, each container is independent.
• Rootless by default. Podman can run containers without root privileges using user namespaces. Docker has supported this since 2020 too, but requires additional configuration.
• systemd integration. Podman can generate systemd units to manage containers as system services. No need for restart: always or an orchestrator.
• Cleaner auditing. Each container appears in ps under the user that launched it, not as a child of the daemon.

Docker Compatibility

CLI compatibility is essentially total:

alias docker=podman

For most basic commands (run, build, pull, push, exec, logs), Podman is drop-in. It also consumes Dockerfile without modifications, supports the same OCI image format, and uses the same registries (Docker Hub, Quay, GHCR).

Three relevant differences:

• Compose. podman-compose exists but doesn’t have Docker Compose’s polish. For complex multi-service stacks, the experience isn’t on the same level — though it improves each release.
• Swarm. Podman has no equivalent. If you rely on Docker Swarm mode, this isn’t a direct replacement.
• Docker Desktop. Podman Desktop exists and is also open-source, but with a smaller extension ecosystem.

The Security Argument

If you work in regulated sectors, rootless mode is likely the main reason to consider Podman. Three concrete advantages:

• A container that escapes doesn’t get host root, only the privileges of the user that launched it.
• No daemon exposed at /var/run/docker.sock that any process with socket access can control.
• More granular auditing — each podman run appears as a syscall by the real user, traceable in auditd logs.

For a development environment where multiple developers share a server, this drastically reduces the attack surface. For a production server running only your own stack, the difference is smaller but not zero.

Buildah, Skopeo, and Separated Responsibilities

Red Hat split the functions Docker bundles in one binary into three separate tools:

• podman: runs containers.
• buildah^[2]: builds images (more flexible than docker build, with support for scripted builds without Dockerfile).
• skopeo^[3]: copies images between registries and inspects without pulling.

This modularity has practical advantages: for a CI pipeline that only needs to build images, installing buildah is lighter than full Docker. And skopeo lets you inspect remote images without pulling them — useful for signature and SBOM validation pipelines.

Cases Where Podman Is the Obvious Choice

Five scenarios where Podman clearly wins:

• Environments without root access. Corporate servers where each user has their sandbox.
• Dev workstations on RHEL/Fedora. Pre-installed, natural integration.
• Rootless CI pipelines. Some Gitea, GitLab, and Jenkins runners avoid elevated privileges.
• Systems already using systemd heavily. Generating units for containers feels native.
• Regulatory auditing. When “a daemon running as root” doesn’t pass security review.

When to Stick With Docker

Four cases where migration doesn’t make sense:

• Production with Swarm. No direct replacement.
• Teams with many Docker Desktop integrations. Migration isn’t trivial.
• Complex Compose stacks in production. podman-compose parity isn’t total yet.
• When your team’s ecosystem is mature on Docker and switching gain doesn’t justify the friction.

Reasonable Coexistence

An intermediate option that works well in practice: use Podman on dev workstations and CI, keep Docker in production if already consolidated. Image compatibility is total — what buildah builds runs in Docker without issue. This delivers security benefits where they impact most (shared environments) without migrating production all at once.

For a new project starting from scratch, it’s worth trying Podman from the beginning. Coming from an established Docker ecosystem, there’s no rush to migrate.

Integration with Trivy and Grype for image scanning works the same as with Docker — both tools are engine-agnostic. Podman’s rootless approach complements the principles of SLSA Level 3 by reducing the blast radius of a build environment compromise. For Rust services with axum, Podman with buildah is a lightweight alternative to Docker for the image pipeline.

Conclusion

Podman is no longer “the Red Hat experiment” — it’s a real alternative with clear advantages in security and architecture. Docker compatibility is high but not complete, and it’s good to know the limits before promising global migrations. For specific use cases — rootless, auditing, daemonless environments — it’s the best option available. For Swarm production, it’s still not a substitute.

1. Podman
2. buildah
3. skopeo