Docker and Podman: architecture, compatibility, and coexistence

One image standard, two entirely different philosophies. Understand dockerd and the daemonless model, and you understand the present and future of container engines.

The distinction in one sentence#

graph LR
    subgraph "容器的两个时代"
        D["Docker / 推动容器工作流普及 / Client-Server 架构 / 生态最成熟"]
        P["Podman / OCI 容器引擎 / Daemonless 架构 / 支持 rootless"]
    end
    D -->|"标准化了容器"| OCI["OCI 标准 / 镜像格式 / 运行规范"]
    P -->|"遵循同一标准"| OCI

Docker popularized image and container workflows and helped establish the OCI standards. Podman follows the same standards but reimplements them with a completely different architecture.

Architecture comparison: a concierge vs doing it yourself#

Docker:
  docker CLI  ──REST API──▶  dockerd (ROOT, 常驻)  ──▶  containerd  ──▶  runc
                              └─ 所有操作都经过它
                              └─ 它是唯一的控制点

Podman:
  podman CLI  ──直接 fork/exec──▶  conmon  ──▶  crun/runc
               └─ 每次启动新进程
               └─ 没有中央控制点

What does this difference mean?

An analogy

• Docker is like staying in a hotel: the front desk (dockerd) is staffed 24 hours a day, and everything (check-in, check-out, room service) goes through it. The front desk has a master key (root).
• Podman is like living in your own house: you open the door, turn off the lights, and cook for yourself. Local operations do not need a continuously staffed front desk; rootful operation or an API socket can still grant high privileges.

Compatibility: Docker syntax, Podman engine#

Command-line compatibility

# 这两个命令几乎等价
docker run -d --name web -p 8080:80 nginx:alpine
podman run -d --name web -p 8080:80 nginx:alpine

# 简单 CLI 可用 alias 试验，但脚本/API/Compose/buildx/远程行为需逐项验证
alias docker=podman
docker ps          # 实际跑的是 podman ps
docker build -t myapp .  # 实际跑的是 podman build

Ecosystem compatibility

Compatibility boundaries

Common areas of interoperability (still verify by version):

• Image format (OCI standards)
• Dockerfile syntax
• Basic CLI commands (run, ps, stop, pull, push, build)
• Volumes and bind mounts
• Port mapping (subject to rootless port restrictions)
• Environment variable injection

Incompatibilities:

• Differences in implementation support for Compose deploy; deploy.resources is not exclusive to Swarm and cannot be declared unsupported across the board
• Docker Swarm as a whole
• Multi-driver builds with docker buildx (Podman uses podman build --platform)
• docker context (Docker's feature for switching between multiple environments)

Security: fundamental differences#

# Docker（默认）：docker run 通过 dockerd socket 执行
# 父进程可能是 shim，权限由 daemon/rootless、userns 和容器 USER 等共同决定
sudo docker run -d nginx:alpine
ps aux | grep nginx
# 示意：ps 的 USER 列是进程用户，不显示父进程；查看父关系另查 PPID

# Podman rootless：进程位于用户映射的权限范围，父关系与用户身份不是同一概念
podman run -d nginx:alpine
ps aux | grep nginx
# 示意：宿主可见 UID 取决于用户命名空间映射

Key security facts:

• A user who controls the rootful Docker API can generally obtain capabilities close to host root; a rootless API is limited to the corresponding user's privileges. A rootful administrator can access sensitive host content through operations such as privileged mounts. Rootless operation does not thereby grant arbitrary file-read access
• In rootless Podman, container UID 0 usually maps to the launching user, while other UIDs can map to subordinate IDs. This reduces exposure of host root, but user files, mounts, sockets, and kernel vulnerabilities still present risks

Choosing an engine#

graph TD
    A["我需要什么？"] --> B{"需要 Docker 专属功能？"}
    B -->|"Docker Swarm"| D["用 Docker"]
    B -->|"Docker Build Cloud"| D
    B -->|不需要| C{"运行环境？"}
    C -->|"个人开发机"| E["Podman / 按 rootless 与工具链要求验证"]
    C -->|"生产服务器"| F{"用什么管理？"}
    F -->|"systemd"| G["Podman + Quadlet / 声明式 + 原生集成"]
    F -->|"Compose 文件"| H{"单机还是集群？"}
    H -->|"单机"| I["Docker 或 Podman / 看团队习惯"]
    H -->|"集群"| J["Docker Swarm 或 K8s"]
    C -->|"公司强制"| K["用公司的标准 / 通常 Docker"]

Specific recommendations

History and version boundaries#

Docker began popularizing container image workflows in 2013. The OCI was established in 2015 and accepted contributions including runc. Podman subsequently developed into an OCI engine emphasizing local operation without a persistent central daemon and support for rootless operation. Quadlet, networking, API, and Desktop features continue to evolve; a particular major version number should not be treated as the point when all features first appeared.

Docker Desktop licensing, Hub quotas, and distribution defaults can change; they do not prove container-format compatibility. Check a distribution's default engine and the requirements for coexistence on one machine against actual packages, sockets, and version configuration. Choosing an engine requires checking the actual version, container configuration, and team toolchain.

Coexistence: Docker and Podman on the same machine#

# 两者可在同台机器并存，分别管理存储；端口、CLI/socket 兼容包和资源仍可能冲突
sudo docker run -d nginx:alpine        # Docker 容器
podman run -d nginx:alpine             # Podman 容器（rootless）

# 查看 Docker 容器
sudo docker ps

# 查看 Podman 容器
podman ps

# 镜像互导
podman save nginx:alpine -o nginx.tar
sudo docker load -i nginx.tar
# 反之亦然

Main takeaway#

Docker and Podman share common image standards, registries, and Dockerfile workflows, but their privilege models, APIs, build features, and orchestration are not guaranteed to be fully interchangeable. Choose based on security boundaries, team tooling, platform, and maintenance approach, and test compatibility with the actual application when necessary. Daemonless operation is not an absolute security guarantee, and rootless operation is not unique to Podman.