Docker vs Podman: how to choose
Podman runs OCI containers without a persistent daemon and without requiring root. Docker uses a long-running daemon that has historically run as root, which means a user in the docker group is effectively root on the host — a detail that matters a great deal on shared build machines.
For everyday use the two are close enough that Podman ships a Docker-compatible CLI, and most commands transfer unchanged. The differences appear at the edges: anything that talks to the Docker socket, anything expecting Docker Compose semantics, and anything relying on the daemon to restart containers after a reboot.
Podman's pod concept, which groups containers sharing a network namespace, maps directly onto the Kubernetes pod, and it can generate Kubernetes manifests from a running pod. That makes it a natural local environment for people whose production target is Kubernetes.
Frequently asked questions
Is Podman a drop-in replacement for Docker?
For the CLI, largely yes — aliasing docker to podman works for most everyday commands. It breaks where something expects the daemon socket, such as Testcontainers or a CI tool that mounts the socket to build images. Podman can expose a compatible socket to cover many of these, but it is a configuration step rather than something that works untouched.
What does rootless actually protect against?
Container escape becoming host root. In rootless mode the container runs as an unprivileged user mapped through user namespaces, so a breakout lands as a normal user rather than root. It also removes the docker group problem, where group membership is equivalent to root because the daemon executes requests with full privilege.
What are the downsides of rootless containers?
Ports below 1024 cannot be bound without extra configuration, some storage drivers behave differently, and filesystem ownership across the user-namespace mapping confuses bind mounts until you understand it. Networking is also slower in the default rootless path because traffic goes through a userspace proxy rather than the kernel bridge.
How does Podman handle Docker Compose?
Two ways. podman-compose reimplements the interface and covers common cases, while the compatible socket lets the real Docker Compose talk to Podman. The second is generally more faithful. Podman also offers Quadlet, which runs containers as systemd units — a better fit than Compose for anything that needs to survive a reboot on a server.
Which should I use in CI?
Whichever your runner supports without privileged mode. Podman's rootless model is a real advantage for shared runners because it removes the need to mount a root-owned socket into a build. If your pipeline depends on Testcontainers or socket-mounting tooling, verify compatibility before committing to a migration.
