Podman

What Podman actually is

Podman is a container engine: the piece of software that builds, pulls, runs, and manages OCI containers on a machine you control. Red Hat created it, the first public release (v0.2) landed in 2018, and version 1.0.0 shipped on 16 January 2019. At KubeCon 2024 Red Hat announced it would hand the project to the Cloud Native Computing Foundation, and Podman and Podman Desktop were accepted into the CNCF Sandbox in January 2025. In our view that governance change matters: this is now community-governed infrastructure, not a single vendor's product decision waiting to happen.

Two architectural choices define Podman, and both are worth understanding before you migrate anything. The first is that it is daemonless. Docker routes every command through a persistent, privileged background process (dockerd); Podman forks each command as a direct child process and hands containers to the host's init system — systemd, in practice — for lifecycle management. There is no privileged socket for a user to talk their way into, and no daemon crash that takes every container on the box with it. The second choice is rootless operation: a regular, non-root user can create, run, and manage containers using Linux user namespaces and subuid/subgid ID mapping. If a container is ever escaped, the attacker inherits user-level privileges, not root on the host. Docker later added a rootless mode too, but it is a configuration option layered on the daemon; in Podman the rootless path is the default design.

Compatibility is the third pillar. Podman's command line mirrors the Docker CLI — podman run, podman build, podman pull, podman push behave like their Docker counterparts — and its REST API is deliberately Docker API-compatible, so tooling written against the Docker socket can usually point at Podman's socket instead. alias docker=podman remains the honest summary of most migration experiences: most scripts run unchanged. Podman also models Kubernetes-style pods natively (groups of containers sharing a network namespace), which is the conceptual bridge to Kubernetes manifests, and it ships Quadlet for generating systemd units from container definitions. Podman Desktop, a free GUI available on Linux, macOS, and Windows and at version 1.0 since May 2023, is the answer for anyone who wants a graphical view without installing Docker Desktop.

Pricing: what you really pay

There is no pricing page to audit, because the software is free under the Apache 2.0 license. No tiers, no per-seat licensing, no feature gates, and — importantly for any organization beyond small-team size — none of the Docker Desktop commercial licensing questions that pushed a lot of organizations toward Podman in the first place. Podman Desktop is free as well. The only line item that can appear is a Red Hat subscription if you want enterprise support for Podman as it ships inside RHEL; that is a support contract around an operating system, not a Podman license.

The real cost of Podman is operational, and we would rather be straight about it than pretend free means zero. Migration is usually cheap at the CLI level and slightly more expensive at the orchestration level (see below). Rootless networking has its own learning curve. And every hour your team spends debugging a compose file that behaves differently under Podman is an hour not spent shipping. Our take: the sticker price is unbeatable, and the switching cost is modest but real.

Performance & infrastructure

Podman has no datacenters, no regions, and no SLA, because it is not a hosting product — it runs on whatever hardware or virtual machine you already pay for. The runtime overhead is close to nil: containers are ordinary Linux processes forked by the engine, with no daemon mediating every syscall. Anything you have read about container performance on this site (our benchmark methodology) comes down to the host kernel, the storage driver, and the underlying disks; Podman and Docker are effectively the same code paths below the CLI (runc or crun as the OCI runtime, the same kernel features).

The nuances are at the edges. Rootless networking historically routed through slirp4netns and now pasta, which adds a thin user-space network stack; for most workloads it is unnoticeable, but latency-sensitive or very high-throughput networking is where rootless has occasionally cost something in past versions. Port binding below 1024 needs a sysctl tweak (net.ipv4.ip_unprivileged_port_start). On macOS and Windows, Podman runs containers inside a managed virtual machine — the same constraint Docker Desktop has, with the same rough performance characteristics. On Linux, where it is native, there is no VM layer at all. For multi-tenant boxes, HPC clusters, and CI runners, rootless Podman is one of the cleaner ways to let unprivileged users run containers without handing out root.

Container lifecycle is handled by systemd through Quadlet, which in our experience is an underrated advantage for server workloads: systemctl becomes your container orchestrator, restarts and boot-time starts come for free, and logs land in the journal. That is a genuinely simpler operational model than babysitting a daemon.

Where it falls short

The compatibility story is good, not perfect. The biggest gap is Compose. podman-compose is a third-party reimplementation, and while docker compose can often be pointed at a Podman socket these days, teams with large multi-service compose stacks report edge cases — networking, build contexts, environment interpolation — that need actual attention during migration. If your deployment workflow is "docker compose up" everywhere, budget time before you call Podman a drop-in replacement.

The surrounding ecosystem is thinner. Third-party tools, CI actions, PaaS integrations, and tutorials overwhelmingly assume Docker; a hardcoded /var/run/docker.sock path or a docker binary check is still a common failure mode. Docker Hub rate limits apply to Podman pulls as well. Some workflows — Docker Swarm, for instance — have no Podman equivalent at all; Podman's answer to multi-node orchestration is Kubernetes, not a swarm mode clone.

Podman's pod concept deserves one more word, because it is the part that ages well. A pod groups containers that share a network namespace — the same abstraction Kubernetes uses — so the mental model you build translating a multi-container application into pod definitions transfers directly to Kubernetes manifests. podman generate kube and podman play kube round-trip between running containers and YAML. For teams whose next step is Kubernetes, that is a smoother on-ramp than treating containers as isolated units and rediscovering pod semantics later. Podman Desktop, which Red Hat said had passed 1.5 million downloads by KubeCon 2024, rounds out the offering with a free graphical interface on Linux, macOS, and Windows.

Rootless also means accepting the constraints of user namespaces: root inside a container maps to your unprivileged user outside it, which occasionally trips up images that assume true root for specific operations. Rootful Podman remains available and is the pragmatic choice for some server workloads, but then you have given up part of the security argument.

On macOS and Windows the experience is honestly a mixed bag: Podman Machine does the job, but it is a virtual machine wrapper, and polish here trails Docker Desktop. Native-Linux users get the best of Podman; everyone else gets a competent approximation.

Who should pick this

We reach for Podman first when the priorities are security posture and operational simplicity: multi-tenant hosts, HPC environments, CI runners, regulated workloads where running containers as root is a finding waiting to happen, and systemd-centric shops that want systemctl to own container lifecycle. It is also the natural choice for organizations that want to avoid Docker Desktop's commercial licensing terms entirely, and for anyone who values that the project now sits under CNCF governance.

We would steer elsewhere when a team's workflow is deeply built on Docker Compose and third-party Docker tooling, when they want Swarm-style clustering without adopting Kubernetes, or when they are on macOS or Windows and want the most polished desktop container experience available. In those cases Docker itself, or a Kubernetes platform for the multi-node question, is the more honest fit.

For the broader container platform landscape, see container platforms.

Key takeaways

• Daemonless and rootless by design: no privileged background socket, containers run as unprivileged user processes with systemd managing lifecycle.
• Free under Apache 2.0, now CNCF Sandbox governance — no license cost and no Docker Desktop-style commercial terms to navigate.
• Strong Docker CLI and Docker API compatibility; alias docker=podman genuinely covers a lot of ground.
• Compose is the migration weak spot: podman-compose is third-party and compose workflows need hands-on verification before you commit.
• Best on native Linux (HPC, multi-tenant, CI); macOS and Windows run containers through a VM wrapper that is competent but less polished than Docker Desktop.

Sources

• https://en.wikipedia.org/wiki/Podman
• https://noze.it/en/insights/podman-1-0