Podman: daemonless OCI containers, rootless by default

What Podman replaces, and for whom

Podman is a tool for managing containers and images, volumes mounted into those containers, and pods made from groups of containers. The repository also contains libpod, the library for container lifecycle management that Podman is built on, and libpod exposes APIs for containers, pods, images and volumes. So the project is two things at once: an end-user CLI and a Go library other tools can embed.

The intended user is someone running OCI containers on Linux who does not want a manager daemon sitting between them and the kernel. The README states the design goal plainly: no manager daemon, for improved security and lower resource utilization at idle. That single choice drives most of the differences people notice. Containers are children of the Podman process, not of a long-lived daemon, so there is no socket to protect and no service to restart when you upgrade the client.

The second intended user is the one who needs rootless operation. According to the README, Podman can be run as a normal user without requiring a setuid binary, and when run without root, containers use user namespaces to map root in the container to the invoking user. The README is explicit about the ceiling this creates: rootless containers will never have more privileges than the user that launched them, and some restrictions can be lifted with flags such as --privileged, but the ceiling stays.

Mac and Windows users are a third audience, served differently. Podman runs containers on Linux, but can also be used on Mac and Windows systems using a Podman-managed virtual machine, driven by podman machine. That is a real architectural difference from running natively, and it shapes what you can expect from volume mounts and networking.

The daemonless model and what libpod actually manages

The scope list in the README is the clearest description of the mechanism. Podman supports multiple container image formats, including OCI and Docker images, and manages them end to end: pulling from various sources including trust and verification, creating images via Containerfile or Dockerfile or by committing from a container, and pushing to registries and other storage backends. Container lifecycle covers creation from an image or from an exploded root filesystem, running, checkpointing and restoring via CRIU, and removal. Networking is handled by Netavark.

Pods are the piece with no direct Docker equivalent. A pod is a group of containers that share resources and are managed together, which mirrors the Kubernetes pod abstraction closely enough that the mental model transfers. If you already think in terms of sidecars sharing a network namespace, Podman pods will feel familiar; if you think only in single containers, pods are extra surface area you can ignore.

Two interfaces sit on top of libpod. The first is a Docker-compatible CLI that can run containers locally or on remote systems. The second is a REST API providing both a Docker-compatible interface and an improved interface exposing advanced Podman functionality. The README does not enumerate which advanced calls exist only in the Podman-native API, so if you are writing a client against the REST layer, check the API documentation in docs/ before assuming Docker parity.

The checkpoint and restore support depends on CRIU, and the go.mod file confirms it is a real dependency: github.com/checkpoint-restore/go-criu/v8 and github.com/checkpoint-restore/checkpointctl appear in the require block. That means checkpointing is not a stub, but it also means it inherits CRIU's kernel and configuration requirements rather than being self-contained.

Installing Podman and running a first container

The README points to an install guide at podman.io/getting-started/installation and to DOWNLOADS.md in the repository, and it notes that your operating system may require additional configuration detailed in that install guide. It does not print a single canonical install command, because distribution packaging differs. The honest starting point is the install guide, not a command copied from a blog.

On distributions that ship Podman in their repositories, installation is a package manager operation. The repository contains an rpm/ directory and a DISTRO_PACKAGE.md file, which is consistent with distribution packaging being a first-class path rather than an afterthought. The README does not give the package manager command, so take the exact package name from your distribution's packaging.

The README does state that Podman can be run as a normal user, without requiring a setuid binary, and that any recent Podman release should be able to run rootless without any additional configuration, though your operating system may require some additional configuration detailed in the install guide. It also states that a little configuration by an administrator is required before rootless Podman can be used, with the necessary setup documented in the rootless tutorial.

The first real container run is where the daemonless model becomes visible. There is no service to start first. The README states that Podman supports running containers and pods without root or other elevated privileges, and that it offers a Docker-compatible CLI interface. Because the README does not print a runnable example command, the concrete invocation to try is the one your distribution's install guide shows; the repository's docs/ directory and demos.md file are the places to look for worked examples before you assume a specific flag exists.

If you are on Mac or Windows, the README states that containers run inside a Podman-managed virtual machine, so the local Linux path above does not apply until that machine exists. The README does not document the podman machine subcommands in the text available here, so consult the install guide before assuming a specific sequence.

Where rootless Podman stops being a drop-in

The rootless section is the most candid part of the README, and it is worth reading as a list of limitations rather than a feature. The README gives a concrete example: if you run Podman as your user and mount in /etc/passwd from the host, you still will not be able to change it, because your user does not have permission to do so. That is not a bug to file. It is the user namespace boundary doing its job.

The README also links to rootless.md for shortcomings and states that almost all normal Podman functionality is available, which is a careful phrasing. Almost is doing work there. If your workload needs capabilities the invoking user does not hold, rootless will refuse, and --privileged only lifts restrictions up to that same ceiling.

The second limitation is support policy, and it is stated without hedging. Only the most recent release receives upstream support. The maintainers make occasional exceptions after a major release, and the README documents one: after Podman 6.0, upstream support of the v5.8 series was extended until the second week of June in 2027, one year after the 6.0 release, and that support includes only CVE fixes and critical bugfixes. If you are pinned to an older series by a distribution, you are outside normal support and should know it.

The third limitation is the release cadence itself. Podman ships a major or minor release four times a year, in the second week of February, May, August and November, with patch releases at any time. All releases are PGP signed, and the approved signing keys live in the containers/release-keys repository. A four-times-a-year minor cadence means breaking changes are a scheduled event, not a surprise, but it also means you should budget for upgrades rather than treating the version as fixed.

Podman against Docker, and against Kubernetes

The most common comparison is Podman against Docker, and the difference that matters is architectural. Docker's model centers on a long-running daemon that owns containers; Podman's README states there is no manager daemon. Everything else follows from that. There is no docker group to join, no daemon socket whose permissions are a security boundary, and no daemon restart that takes your containers with it. The CLI is deliberately Docker-compatible, so the day-to-day commands transfer, but the process model does not.

The comparison against Kubernetes is a different axis and the search data suggests people conflate them. Podman runs containers and pods on a single host; Kubernetes schedules workloads across a cluster. Pods exist in both, which is the source of the confusion, but a Podman pod is a local grouping, not a schedulable unit managed by a control plane. Podman is a reasonable way to run a container locally before deploying it to a cluster, and it is not a substitute for one.

For teams that want a graphical entry point, Podman Desktop is a separate project and is not described in this README. Nothing in the repository material documents its features, so treat it as adjacent tooling rather than part of this codebase. Similarly, Podman Compose and Quadlet appear in the search data but the README does not document them; the repository does contain a docs/ directory and a demos.md file, which is where you would look before assuming a specific integration behaves a particular way.

Release cadence, licensing and upgrade cost

Podman is licensed under Apache-2.0, and the LICENSE file sits at the top level of the repository. That is a permissive licence with an explicit patent grant, which matters if you are embedding libpod in a product rather than just running the CLI. This is a description of the licence identifier, not legal advice; if you are redistributing Podman or linking libpod into a commercial product, have counsel read the actual terms.

Upgrade cost is driven by the cadence. Four minor releases a year, in February, May, August and November, plus patch releases at any time. The README frames the post-major-release support extension as recognition that not all users and distributions will be able to quickly migrate to a breaking change release. That sentence is the upgrade story in miniature: breaking changes happen, distributions lag, and the maintainers sometimes extend the previous series with CVE and critical fixes only.

The practical consequence is that you should track which series your distribution ships and whether it is inside that window. If you are on a v5.8 series release, the README states support runs until the second week of June in 2027 and covers only CVE fixes and critical bugfixes. Feature fixes are not in scope for that extension. Building from source is possible; the Makefile defaults CGO_ENABLED to 1 and notes that Podman does not work without CGO except in specific cases, with Windows and Mac clients requiring CGO_ENABLED=0. That is a build-time constraint worth knowing before you try to cross-compile a static binary.

Editorial conclusion

Adopt Podman if you run containers on Linux, want rootless isolation without a setuid binary, and need pods or Quadlet-style systemd integration. Do not adopt it if your tooling assumes a persistent Docker daemon socket, or if you depend on a distribution that has not packaged a recent release. Verify first that your host kernel and user namespace configuration allow rootless operation, since the README points to extra setup documented in the rootless tutorial and install guide.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes