Podman

Docker is like an apartment building with one building superintendent, the daemon, who holds every tenant's spare key and personally manages every unit's plumbing, mail, and locks — if the superintendent quits or gets held hostage, every apartment is affected. Podman is more like a set of standalone houses: each container is its own independent household managed directly by its owner, with no single building-wide manager whose failure or compromise takes down everyone else.

Docker's architecture centers on dockerd, a long-running background process, traditionally running as root, that owns the container runtime, image store, networking, and the API socket the docker CLI talks to. This was simple to build and made features like build caching and centralized logging easy, but it concentrates enormous privilege in one process: anyone with access to docker.sock effectively has root on the host, because Docker will happily let you bind-mount / into a privileged container. Podman was designed specifically to remove that single point of privilege — there's no daemon at all; the podman CLI itself forks the container as a subprocess of your own user session using Linux namespaces, so a rootless podman run never touches root privileges anywhere in the chain.

When you run podman run -d --name checkout-worker nginx, Podman creates a new user namespace mapping your unprivileged UID to UID 0 inside the container, so "root" inside the container is not root outside, sets up network and mount namespaces, and then forks and detaches the container process as a child of a lightweight conmon (container monitor) process rather than a central daemon — conmon stays alive to hold the container's stdio and exit code even if the parent podman process or your shell exits. Because there's no daemon tracking state centrally, Podman reconstructs container state by reading from local files under the user's home directory and querying the kernel directly each time you run a command.

In production, this means a Podman host loses the "one daemon crash kills every container" failure mode entirely — each container is only as fragile as its own conmon process. What to monitor instead: conmon process health per container, storage driver behavior since fuse-overlayfs, used for rootless storage, has different performance characteristics than the daemon-managed overlay2 driver Docker uses and can be slower for write-heavy workloads, and subuid/subgid range exhaustion on hosts running many rootless containers for different users, since each user needs a large enough allocated UID range in /etc/subuid.

The gotcha most teams hit during migration is CI tooling that assumes docker.sock exists — Docker-in-Docker patterns, the original docker-compose, and tools that bind-mount the socket to introspect sibling containers all silently fail under Podman because there is no socket by default. Podman does offer an optional API socket via podman system service that emulates the Docker API for compatibility, but running that service reintroduces a long-lived privileged process, which quietly defeats the daemonless security model teams often migrate to Podman specifically to get.

Imagine a company that gives every employee a name badge that says "Manager" only inside a specific building, but the moment they walk out the front door, security systems automatically read their badge as "temp contractor" instead. Even if that employee tries to abuse their in-building "Manager" title to break down a door, once they're outside the building the real-world consequences are limited to what a low-level contractor could actually do, not what an actual manager could do.

Rootless containers exist because containers are not full security boundaries by default — a process running as root inside a container is still, in an unpatched or misconfigured setup, capable of escalating to real root on the host if it escapes the container via a kernel exploit or a dangerous mount. Podman's rootless mode addresses this by leaning entirely on Linux user namespaces, a kernel feature that lets a process see itself as UID 0 while the kernel actually enforces a different, unprivileged UID outside that namespace, so the "root" identity inside the container is cosmetic from the host's point of view.

When you run a rootless podman run, Podman consults /etc/subuid and /etc/subgid to find the block of UIDs and GIDs your host user has been allocated, for example a user might own host UIDs 100000 through 165536, creates a new user namespace, and maps container UID 0 to your real host UID, with the subordinate range covering additional container UIDs. Storage is handled by fuse-overlayfs, a FUSE-based overlay filesystem implementation, because the kernel's native overlay2 driver historically required real root to mount. Networking for rootless containers runs through slirp4netns or pasta, user-space network stacks that don't require root to create network namespaces or manipulate iptables, which is also why ports below 1024 don't bind directly without extra configuration — binding privileged ports is a real root-only kernel operation that user namespaces can't fake.

In production, what matters is making sure every user running rootless containers has a properly sized subuid/subgid allocation, since /etc/subuid entries are often forgotten when provisioning new CI runner users, causing cryptic "newuidmap: not allowed" errors, and monitoring for storage-layer slowness since fuse-overlayfs adds a userspace round-trip per filesystem operation compared to native overlay2, which shows up as elevated I/O latency for write-heavy workloads like build caches or database containers.

The subtle gotcha experienced engineers hit is that "rootless" does not mean "safe from all container escapes" — it means a successful escape lands as an unprivileged user instead of root, which is a real improvement but not a guarantee. A container escape can still access and potentially corrupt anything that unprivileged host user can read or write, including SSH keys, other rootless containers' storage under the same user's home directory, or CI credentials mounted into the user's environment. Rootless is a blast-radius reduction, not a full isolation boundary.

Think of a Podman pod like roommates who share a single apartment lease, the network namespace — they each have separate bedrooms, their own container filesystem and process space, but share one front door, one street address, and one mailbox, meaning anyone can walk between rooms using just "down the hall," or localhost, instead of needing the building's full address.

Kubernetes needed the Pod abstraction because some workloads only make sense as tightly coupled groups — a main application container plus a logging sidecar, for instance, need to share localhost and sometimes a volume, but shouldn't be merged into one container image. Podman adopted the exact same grouping concept locally, specifically so developers could design and test multi-container, sidecar-style architectures on a laptop without needing a real cluster, and so that the resulting design translates directly into deployable Kubernetes manifests instead of needing to be re-architected later.

Under the hood, podman pod create starts an infra container, functionally identical to Kubernetes' pause container, whose only job is to hold open the shared network namespace; every container subsequently added via podman run --pod joins that same namespace instead of creating its own, which is why containers in the same pod can reach each other over localhost on their respective ports. Running podman generate kube <pod-name> walks the pod's containers, volumes, and port mappings and serializes them into a standard Kubernetes Pod, Deployment, or Service YAML manifest, because Podman's internal pod model was deliberately built to be a structural subset of the Kubernetes Pod spec. podman play kube does the reverse — it reads a Kubernetes YAML file and reconstructs the equivalent Podman pod locally, letting engineers run real cluster manifests without a cluster.

In practice, teams use this workflow to validate sidecar patterns, such as an application container plus a log-shipping sidecar reading from a shared volume, entirely locally before committing YAML to a GitOps repository, catching port conflicts, missing environment variables, or volume mount mistakes early. What to watch for: podman generate kube output is a snapshot, not a live sync — if you keep editing the running pod with more podman run --pod commands, you must regenerate the YAML, since Podman doesn't track drift between the running pod and previously exported files.

The non-obvious gotcha is that podman generate kube output is intentionally conservative and doesn't capture everything a production Kubernetes deployment needs — resource requests and limits, liveness and readiness probes, and Kubernetes-specific scheduling fields like node affinity have no local Podman equivalent and are either omitted or filled with defaults, so engineers who treat the generated YAML as "done" rather than "a starting draft" end up deploying pods to production clusters with no resource limits at all, a very common and expensive mistake.

Migrating from Docker to Podman in CI is a bit like switching a delivery fleet from gas trucks to electric trucks that use the exact same steering wheel and pedals — most drivers, the build scripts, won't notice the difference and can keep driving the same way, but the depot's gas pumps, the Docker daemon and its socket, are gone, so anything that specifically depended on stopping by the gas pump, rather than just driving the truck, needs a new plan.

Podman was deliberately built to be a drop-in CLI-compatible replacement for Docker specifically to make this kind of migration low-friction; podman build, podman push, and podman run accept the same flags and Dockerfile syntax as their Docker equivalents. This matters in CI/CD because most pipeline YAML is just shell commands invoking the docker binary, so an alias docker=podman, or symlinking the binary, silently redirects the vast majority of a pipeline's build and push steps with zero changes.

The migration breaks down into three real steps. First, alias or symlink docker to podman in the CI runner image so existing docker build and docker push invocations work unmodified. Second, handle Docker Compose: docker-compose itself expects a Docker daemon API to talk to, so teams either install podman-compose, a Python wrapper translating compose YAML into sequential Podman commands, or start Podman's Docker-API-compatible socket service via podman system service and point DOCKER_HOST at it so the original docker-compose binary keeps working unmodified. Third, and most often missed, is ensuring the CI runner's user has a valid /etc/subuid and /etc/subgid allocation, because rootless Podman refuses to create the user namespace mapping without it, and container-based CI runners frequently run as a freshly created user with no such allocation configured in the base image.

In production CI fleets, the practical issues that surface are storage driver differences, since some runner images bake in overlay2 assumptions that don't hold for Podman's fuse-overlayfs default under rootless mode, causing slower image layer extraction, CI plugins that specifically shell out to docker binary paths or check docker version output format for parsing, and multi-stage build caching behaving slightly differently since Podman's build cache invalidation logic isn't byte-for-byte identical to Docker's BuildKit. Teams should run a subset of pipelines in shadow or parallel mode against both engines for a few weeks before fully cutting over, watching build duration and cache hit rate as the key regression signals.

The gotcha that catches teams off guard is that some third-party Docker plugins and vulnerability scanners integrate via the Docker socket protocol specifically, not just the CLI, and silently produce empty or wrong results against Podman's compatibility socket if the socket path or API version isn't set exactly right — the scan appears to run successfully but silently returns zero findings, which is far more dangerous than an outright failure because nobody notices the security gate stopped actually checking anything.