Podman vs Docker

Overview: Why Compare Podman and Docker?

Podman and Docker both run containers and use the same underlying technologies (namespaces, cgroups, images, etc.), but they differ in architecture, security model, and how they integrate with the OS. Understanding these differences helps you:

• Choose which one to use on a given system.
• Port workflows and scripts between them.
• Use Podman on systems where Docker is unavailable or not desired.

This chapter assumes you already understand basic container concepts and how to run simple containers (covered earlier under Docker fundamentals and container basics). Here we focus on differences and practical migration considerations.

Architecture and Daemon Model

Docker: Central Daemon

Docker uses a long-running root-owned daemon:

• dockerd runs as root (often via a systemd service).
• The Docker CLI (docker) is a client that talks over a UNIX socket (usually /var/run/docker.sock) to the daemon.
• All container lifecycle operations go through that daemon.

Implications:

• Single control point: easier to manage centrally, but also a single point of failure.
• Root daemon risk: compromise of the daemon or access to the Docker socket may lead to full root access on the host.
• Multi-user separation is weak: multiple users talking to the same daemon share control plane and resources unless extra isolation is added.

Podman: Daemonless (By Default)

Podman is designed around a daemonless model:

• The podman CLI talks directly to the container runtime libraries (e.g., crun, runc) and storage.
• No always-on root daemon is required for rootless containers.
• For root containers or remote management, Podman can use podman system service, but this is optional and scoped.

Implications:

• Per-user processes: containers you create as a regular user belong to your user session.
• Better multi-user isolation: each user has separate container, image, and volume namespaces (rootless).
• Less background overhead: no mandatory permanent daemon.

API Compatibility and Services

Docker provides the Docker Engine API via the daemon. Many tools (Compose, CI systems, IDEs) expect this API.

Podman offers:

• A Docker-compatible REST API via podman system service, usually on a UNIX socket such as unix:///run/user/$UID/podman/podman.sock.
• Ability to be used as a "drop-in" for tools that expect the Docker API, within limits.

Key point: Podman’s API is optional and per-user rather than a single system-wide root socket.

Rootless vs Rootful: Security and Permissions

Rootless Containers

Both Docker and Podman support rootless containers now, but:

• Podman was designed around rootless from the start.
• Docker’s rootless mode is newer and more limited in some areas (especially around networking and certain storage operations).

Podman rootless features:

• Uses user namespaces to map container root to an unprivileged host user.
• Each user has separate images and containers in ~/.local/share/containers by default.
• No central privileged daemon needed for most tasks.

Rootless advantages:

• Reduced risk: escaping a container doesn’t automatically mean full system compromise.
• Better suited for shared multi-user systems (e.g., university clusters, dev servers).

Rootful Use Cases

Some tasks still work best as root:

• Low-level networking (custom bridges, host networking).
• Direct device access (/dev devices).
• Certain filesystem mounts (bind-mounting system paths, fuse-based volumes).

Both Docker and Podman can run containers as root. With Podman:

• sudo podman ... uses a separate root container storage and environment.
• You can clearly distinguish root vs non-root containers by how you run the command.

Pods and Kubernetes Alignment

Podman Pods

Podman implements the Kubernetes Pod concept natively:

• A Pod is a group of one or more containers that share:
• Network namespace (same IP, ports).
• Some IPC and optionally other namespaces.
• Podman has podman pod subcommands:
• podman pod create
• podman pod start, podman pod stop
• podman pod ps, podman pod inspect

Example:

podman pod create --name webpod -p 8080:80
podman run -d --pod webpod --name nginx nginx:alpine
podman run -d --pod webpod --name sidecar busybox sleep 3600

Both containers share the same IP; only port 8080 on the host is mapped.

Docker and Pods

Docker does not have a native "Pod" object:

• To emulate Pods, you typically:
• Run one container per service.
• Use --net=container:other_container or docker-compose for grouping.
• Kubernetes adds Pod semantics on top of container runtimes, not via Docker itself.

Podman’s pod model aligns more closely with how Kubernetes conceptualizes workloads, which can simplify migration to Kubernetes.

CLI Compatibility and Differences

Podman’s CLI is intentionally similar to Docker’s, making migration easier. Many basic commands are nearly a drop-in replacement:

• docker run → podman run
• docker ps → podman ps
• docker images → podman images
• docker exec → podman exec
• docker logs → podman logs
• docker pull → podman pull
• docker push → podman push

Direct Command Substitution

On many distributions you can install a symlink or alias:

alias docker=podman

Or install the podman-docker package which provides a docker wrapper that calls Podman.

Notable CLI Differences

While basic commands are similar, some behaviors differ:

• Default networking:
• Docker often uses the bridge network by default.
• Podman’s rootless containers use a user-mode networking stack (e.g., slirp4netns), with some limitations (e.g., no direct --net=host in rootless mode on some systems).
• System-wide vs per-user:
• Docker CLI commands always operate through the system daemon.
• Podman commands operate per-user unless using sudo or a system service.

Where Docker has docker compose (plugin) or docker-compose (legacy Python), Podman uses podman-compose (separate Python project) and native pod support. Compose syntax is mostly compatible but may require adjustments.

Image Format, Registries, and Storage

Shared OCI Image Formats

Both Docker and Podman use OCI-compatible image formats:

• You can generally pull the same image from a registry with either tool:
• docker pull nginx
• podman pull nginx
• Images built with docker build are typically usable by Podman, and vice versa, when exported/imported or accessed from a shared registry.

Local Image Storage and Layout

Storage backends can differ:

• Docker typically uses:
• Storage drivers like overlay2.
• Data in /var/lib/docker.
• Podman uses:
• containers/storage (same library as other container tools like Buildah).
• By default:
• Root storage: /var/lib/containers/storage
• Rootless storage: ~/.local/share/containers/storage

These differences matter for disk usage and troubleshooting, but not for image compatibility with registries.

Supported Registries and Auth

Both support:

• Standard image registries: Docker Hub, Quay, GHCR, private registries.
• ~/.docker/config.json-style authentication (Podman can read this).
• Mirrors and insecure registries (configured via /etc/containers/registries.conf for Podman, Docker daemon config for Docker).

Building Images: `docker build` vs `podman build`

Both implement Dockerfile-like builds:

• docker build uses the Docker engine’s build functionality.
• podman build uses Buildah libraries under the hood but exposes a Docker-compatible interface.

Key points:

• Dockerfile compatibility is generally high.
• Podman supports rootless builds, which can improve security in CI environments.
• Podman may also support additional build features via Buildah integration (multi-stage builds are supported by both).

Example:

podman build -t myapp:latest -f Dockerfile .

If you already have a Docker-based CI pipeline, you can often swap docker with podman with minimal changes, especially when using rootless builds.

System Integration and Service Management

Running Containers as System Services

Docker:

• Typically uses docker-compose or docker run --restart policies.
• Relies on the Docker daemon being managed by systemd, but individual containers are not systemd units by default.

Podman:

• Integrates more tightly with systemd:
• podman generate systemd creates unit files for containers or pods.
• These units can be placed in:
• /etc/systemd/system (system-wide)
• ~/.config/systemd/user (per-user)

Example:

podman run -d --name myapp --restart=always nginx
podman generate systemd --name myapp --files

Then you can manage it like any other systemd service:

systemctl enable --now container-myapp.service

This model works well for:

• Rootless container services managed via user-level systemd.
• Integrating containers with standard Linux service management and logging (journalctl).

Podman and Docker in Different Environments

Development Environments

Docker:

• Widely used and well-supported on macOS and Windows (via Docker Desktop).
• Strong ecosystem integration for developers (IDEs, tools, templates).

Podman:

• On Linux, very attractive due to rootless mode and tight OS integration.
• On macOS/Windows, relies on virtual machines (e.g., podman-machine or other backends); Docker Desktop still dominates in those ecosystems.
• For Linux-native dev setups (e.g., WSL2, Linux workstations), Podman is a strong alternative.

Production and Servers

Many Linux distributions (especially enterprise-focused ones) are moving more toward Podman and other daemonless tools:

• Red Hat Enterprise Linux (RHEL), CentOS Stream, Fedora:
• Ship Podman as the primary container engine.
• Focus on rootless and systemd integration.
• Docker is still heavily used in:
• Legacy environments.
• Orchestration setups historically built around Docker Engine.

Podman is often preferred where:

• Security and multi-tenancy are strong concerns.
• Direct Kubernetes alignment (pods, manifests) is valuable.
• Rootless workflows and systemd integration are priorities.

Migration Considerations: Moving from Docker to Podman

CLI and Scripting

Steps to migrate:

1. Install Podman alongside or instead of Docker.
2. Test basic commands by:
• Adding alias docker=podman for interactive use.
3. Update scripts:
• Replace docker with podman.
• Adjust any Docker-specific options (networking, logging drivers, volume semantics).

Watch out for:

• Root vs rootless differences (volumes and port mappings may require permission adjustments).
• Any reliance on Docker-specific features (plugins, swarm mode).

Compose and Multi-Container Apps

Options:

• Use podman-compose with your existing docker-compose.yml files.
• Convert multi-container apps into Pods in Podman directly.
• For Kubernetes-bound applications, generate Kubernetes YAML from Compose with other tools and then use Podman’s Kubernetes integration (e.g., podman play kube).

CI/CD Pipelines

Where CI pipelines invoke Docker:

• Consider swapping docker with podman in build steps.
• Run Podman in rootless mode under the CI user.
• Use the Docker-compatible API if the CI integration expects a Docker socket (start podman system service and point the CI tool at the Podman socket).

This can reduce the need to run privileged Docker-in-Docker setups.

When to Choose Podman vs Docker

Favor Podman When

• You are on a Linux server or workstation and:
• Want rootless operation by default.
• Need clean multi-user separation for containers.
• Prefer strong systemd integration for managing containers as services.
• Are aligned with Kubernetes concepts and want native pods.
• You operate in an environment aligned with Red Hat/Fedora ecosystems where Podman is the standard.

Favor Docker When

• You rely heavily on:
• Docker Desktop on macOS/Windows.
• Tools that tightly integrate with the Docker Engine and its daemon.
• Docker Swarm or cluster setups specifically dependent on Docker’s swarm mode.
• Your existing workflows and teams are already heavily standardized around Docker and you do not yet need what Podman provides.

Summary of Key Differences

• Daemon: Docker requires a root daemon; Podman is daemonless (with optional per-user service).
• Security: Podman was designed for rootless; Docker added it later.
• Pods: Podman has first-class pods matching Kubernetes concepts; Docker does not.
• System Integration: Podman integrates deeply with systemd and user sessions; Docker centralizes through dockerd.
• CLI and API: Similar CLIs; Podman can expose a Docker-compatible API when needed.
• Ecosystem: Docker is more prevalent across platforms; Podman is strong on modern Linux, especially in enterprise/server environments.

Understanding these points lets you choose the right tool for your environment and migrate between them with minimal friction.