Podman

Podman: product and architecture

This Podman review covers the container engine that removed the daemon. Podman builds and runs OCI containers as child processes of the user who invoked them, rather than through a long-running privileged service, which makes rootless operation the default rather than a hardening project. Its command line is deliberately Docker-compatible, so alias docker=podman covers most everyday use. It is Apache-2.0 licensed and sponsored by Red Hat. We evaluated it on its documentation, its licence, and its GitHub repository, which carried 32,895 stars when we checked on 19 September 2026.

Overview

The architectural difference is the whole product. A daemon-based engine runs a privileged background service, and any user who can talk to its socket can effectively act as root on the host. Podman has no daemon: each container is a child process of the invoking user, supervised by conmon, with the kernel's user namespaces providing isolation.

That has consequences beyond security posture. Containers become ordinary processes, so systemd can supervise them the way it supervises anything else, and a container that dies does not depend on a daemon being healthy to be restarted. It also means there is no single point of failure whose restart takes every container with it.

Podman is developed in the open under Apache-2.0 and sponsored by Red Hat, which ships it as the default container engine in RHEL and Fedora. For teams already on Red Hat platforms, it arrives rather than being adopted.

Key Features and Architecture

Rootless containers are the headline capability. A non-privileged user can build and run containers without being granted access to a privileged socket, using user namespaces to map container root to an unprivileged host UID. In a shared build environment or a multi-tenant host, that removes an entire class of privilege escalation.

Docker CLI compatibility is deliberate and close. Commands, flags and output formats are designed to match, which is why the alias trick works for most everyday operations and why migration is usually a matter of changing the binary rather than rewriting scripts. Podman also exposes a Docker-compatible API socket for tools that speak to a daemon, so parts of the surrounding ecosystem continue to work.

Pods are a first-class concept, and the name is not incidental. Podman can group containers into a pod sharing a network namespace — the same abstraction Kubernetes uses — and can generate Kubernetes YAML from a running pod. That makes it a genuine local development path for workloads destined for a cluster, rather than an approximation.

Systemd integration is the operational story. Podman can generate unit files so containers are supervised, restarted and ordered by the same init system as everything else on the host, which suits single-node deployments that do not warrant an orchestrator. Quadlet, the declarative unit format Podman ships for this, lets a container be described as a systemd unit directly rather than through a generated file that has to be regenerated whenever the container definition changes.

Image building is handled in the same toolchain. Podman builds from a Containerfile or a Dockerfile — the formats are interchangeable — and the related Buildah and Skopeo tools cover scripted image construction and registry-to-registry copying for teams that want those steps separated from the runtime.

Ideal Use Cases

Podman fits any host where a privileged container daemon is unacceptable — shared build machines, multi-tenant developer servers, and security-reviewed environments where the daemon socket is a finding.

It fits Red Hat estates, where it is the default engine and the supported path.

It fits single-node deployments that want containers supervised by systemd rather than by an orchestrator. A small service on one VM does not need a cluster, and Podman with systemd units is a coherent answer.

It fits local development for Kubernetes workloads, because pods and manifest generation map onto what the cluster will actually run.

It fits CI runners, where a build job that needs to build an image has historically meant either mounting a privileged socket into the job or running a container inside a container. A rootless engine removes that choice, and the job builds images as the unprivileged user it already runs as.

Do not use Podman if your workflow depends heavily on Docker Desktop's ecosystem, Docker Compose plugins, or third-party tooling that assumes a Docker daemon. Compatibility is high but not total, and the gaps tend to appear in the tools around the engine rather than the engine itself. A team whose build pipeline is wired into that ecosystem should test the specific integrations before committing, rather than assuming the alias is enough.

Pricing and Licensing

Podman is free under the Apache-2.0 licence, with no paid tier, no per-seat charge and no commercial edition. It is an open-source project rather than a vendor product, so there is nothing to buy and nothing withheld.

Red Hat sells support for Podman as part of RHEL subscriptions. That is a support contract for a platform, not a price for the software — the same engine is free on any other distribution, and no capability is gated behind the subscription.

This is a meaningful difference from a daemon-based engine sold with commercial desktop licensing, where organisational size determines whether developer machines require paid licences. Podman has no such threshold, which for a large engineering organisation removes both a cost and a compliance-tracking obligation.

We recommend accounting for the migration effort rather than the licence when comparing. The software is free on both sides of that comparison for many teams; what differs is whether your surrounding tooling assumes a daemon.

Strengths & Trade-offs

Pros

• No daemon, and therefore no privileged socket. The largest single attack surface of the daemon model is simply absent.
• Rootless by default. Unprivileged users run containers without special grants.
• Docker-compatible CLI and API socket. Most commands and many tools work unchanged.
• Pods and Kubernetes YAML generation. Local development maps onto what a cluster will run.
• Systemd supervision. Containers are supervised like any other service on the host.

Cons

• Ecosystem edges differ. Tooling that assumes a Docker daemon may need adjustment, and the gaps are in the surrounding tools rather than the engine.
• Rootless has real constraints. Certain networking and storage configurations behave differently under user namespaces, which surprises teams that expect exact parity.
• Documentation assumes the alternative. Most tutorials in circulation are written for the other engine, so newcomers translate as they go.