Cloud Parts

Podman

Runs Docker-style containers without a daemon, as root or as an ordinary user, and hands long-running ones to systemd.

What it is
Containers
Type
Open source
Made by
Podman Container Tools, a CNCF sandbox project; started and still mostly maintained by Red Hat
License
Apache 2.0 (Podman and Podman Desktop alike)
Facts checked
5 October 2026
Website Source code

What it is

Podman runs containers without a daemon. Each podman command does its job and exits: podman run prepares the container’s storage and network, then starts conmon, a small monitor process, which launches an OCI runtime (crun by default, or runc) to create the container. conmon stays behind to hold the container’s output streams, write its logs and record its exit code. The container is therefore a descendant of whatever started it, a shell or a systemd unit, not of a long-running server. Run by an ordinary user, Podman creates a user namespace mapped onto that user’s ranges in /etc/subuid and /etc/subgid, so root inside the container is your own account outside, and Podman itself never gains privileges. Rootful containers get bridge networks from Netavark, with container names served by the aardvark-dns DNS server; rootless ones get their network device from pasta. Containers can be grouped into pods that share network, IPC and hostname namespaces, matching Kubernetes defaults, and podman kube play runs Kubernetes Pod and Deployment YAML directly.

The command line copies Docker’s, so alias docker=podman works for most people, and podman build uses Buildah underneath. For tools that speak the Docker API, podman system service serves a Docker-compatible REST API, alongside Podman’s own, on a Unix socket that systemd starts on demand; docker-compose and the podman compose wrapper talk to it. For long-running services, Quadlet turns small .container, .pod or .kube files into systemd units, and podman auto-update pulls newer images and restarts those units. Containers need a Linux kernel, so on macOS and Windows podman machine runs a Linux VM (libkrun by default on Macs, WSL or Hyper-V on Windows) and podman drives it remotely. Podman is Apache 2.0. Red Hat started it, and since January 2025 it has been a CNCF sandbox project with Buildah and Skopeo; the separate Podman Desktop GUI is also Apache 2.0 and a CNCF sandbox project.

Why teams pick it

  • No daemon to run or protect: containers are children of the command or systemd unit that started them, and nothing runs when no containers do
  • Rootless by design: an ordinary user runs containers in a user namespace, and Podman is not setuid and gains no privileges
  • Close to Docker: the same CLI, images and registries, plus a Docker-compatible API socket for tools such as docker-compose
  • Quadlet makes containers ordinary systemd services, with dependencies, restarts and scheduled image updates through podman auto-update
  • Pods and podman kube play / podman kube generate let you move between Kubernetes YAML and local containers

Watch out for

  • Compose isn’t built in: podman compose hands off to an external docker-compose or podman-compose, and Docker plugins aren’t supported
  • Rootless networking has caveats: ports below 1024 need a sysctl change, and the default rootlessport forwarder hides clients’ real source IPs (a pasta forwarder that keeps them is experimental in 6.0)
  • One machine only: no Swarm and no scheduling or failover across hosts; the project points to Kubernetes for orchestration
  • On macOS and Windows every container runs inside a podman machine Linux VM, and Podman 6 dropped Intel Macs and Windows 10
  • Podman 6 removed cgroups v1, iptables, CNI and slirp4netns, so older hosts must be modernised or stay on the 5.8 line, which still gets releases

Alternatives

What all containers have in common →
AWS FargateAWSRuns ECS tasks and EKS pods without servers: you size each task, AWS finds the machine.Cloudflare ContainersCommercialLinux container images that run on Cloudflare’s network next to a Worker, each instance started on demand by its own Durable Object and put to sleep when idle.+1 Cloudflare Sandbox SDKDockerOpen sourceThe tool that made containers mainstream: build an image from a Dockerfile, then run it anywhere.Google Cloud RunGoogle CloudGive Google a container that listens on a port; it runs as many copies as traffic needs, down to zero.gVisorOpen sourceA Linux kernel reimplemented in Go that runs in user space, so a container’s system calls never reach the host kernel directly.

How it fits with other technologies

A rootless web service run by systemd through a Quadlet file · bash

mkdir -p ~/.config/containers/systemd
cat > ~/.config/containers/systemd/orders-api.container <<'EOF'
[Unit]
Description=Orders API

[Container]
Image=ghcr.io/acme/orders-api:1.4.2
PublishPort=8080:8000
Volume=orders-data:/var/lib/orders
Environment=LOG_LEVEL=info
HealthCmd=curl -fsS http://localhost:8000/healthz
AutoUpdate=registry

[Service]
Restart=on-failure

[Install]
WantedBy=default.target
EOF

systemctl --user daemon-reload                # Quadlet generates orders-api.service
systemctl --user start orders-api.service     # runs `podman run` as you; no daemon
loginctl enable-linger "$USER"                # keep user services alive after logout
systemctl --user enable --now podman-auto-update.timer  # daily: pull newer image, restart

Podman and Docker compared#

Both run the same OCI images from the same registries, and most docker commands work unchanged with podman. They differ in how containers are started and supervised, and in what comes in the box.

PodmanDocker
How containers startNo daemon: podman starts conmon and an OCI runtime, then exitsThe docker client asks the dockerd daemon over a REST API
RootRootful or rootless; rootless needs only subordinate UID rangesThe daemon needs root unless you opt in to Rootless mode
PodsYes: podman pod shares network, IPC and hostname namespaces, like KubernetesNo pod object; Compose groups related containers
Keeping services runningQuadlet files become systemd units; podman auto-update refreshes imagesRestart policies run by the daemon; Docker advises against process managers
Composepodman compose runs docker-compose or podman-compose against Podman’s socketDocker Compose, Docker’s own tool
Multi-hostNone; Swarm API calls are refusedSwarm mode built into the engine
Kubernetes YAMLpodman kube play runs it; podman kube generate writes itNot read by the engine; Docker Desktop includes a local Kubernetes
Docker APICompatibility layer (Docker API v1.44 in Podman 6.0) plus the Libpod APINative
macOS and Windowspodman machine Linux VMDocker Desktop Linux VM (on Linux desktops too)
Desktop app licencePodman Desktop: Apache 2.0, free for everyoneDocker Desktop: proprietary; paid for companies with 250+ employees or $10 million+ revenue
Licence and governanceApache 2.0, CNCF sandbox projectEngine Apache 2.0, built from the Moby project; Docker, Inc.
  • Docker’s Rootless mode runs the daemon itself inside a user namespace; Podman’s rootless mode has no daemon at all.

The rest of the toolbox#

Podman is one of several daemonless tools from the same team, sharing the same image and storage libraries.

Buildah

CNCF, with Podman

Builds OCI images from a Dockerfile or by modifying a working container, without a daemon or root. podman build uses it internally, and the two share image storage.

Skopeo

CNCF, with Podman

Copies images between registries and inspects remote images, layers included, without pulling them or running a daemon.

Podman Desktop

separate CNCF sandbox

A GUI for Linux, macOS and Windows for working with containers, images and Kubernetes from the desktop. Free and Apache 2.0 for any size of company.

bootc

separate CNCF sandbox

Boots and updates whole operating systems from container images, kernel included. Podman 6 uses bootc switch to update the OS inside podman machine VMs.

See it in a real stack

No architecture uses Podman yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2026

Docker starts every container as a child of one long-running daemon that normally runs as root. In 2018 Red Hat’s Dan Walsh showed what that costs: a container started through the daemon loses the login UID that Linux audit uses to record who changed a file, and systemd features such as readiness notification and socket activation can’t pass through the client/server hop. Talking to the daemon’s socket also means trusting a root process.

Podman began inside CRI-O, Red Hat’s container runtime for Kubernetes. In November 2016 engineers added kpod there, a client-only tool for debugging pods and images when the daemons weren’t responding, which needed no daemon itself. In November 2017 it moved to its own repository, libpod, and that December Walsh renamed it: “The decision is in, kpod is going to be named podman.” Red Hat wanted something easy for anyone used to the Docker command line that didn’t need a daemon running.

Podman 1.0 shipped in January 2019, and RHEL 8 that May dropped the Docker engine and docker command in favour of Podman. Later releases replaced CNI networking with Netavark, built systemd support in through Quadlet and made pasta the rootless network. The CNCF accepted Podman, Buildah and Skopeo as a sandbox project in January 2025, and Podman 6.0 moved them into a CNCF-owned GitHub organization.

Why it’s built this way

Fork and exec instead of a client and a daemon
The container is an offspring of the podman process, so audit keeps the real user’s login UID and systemd can pass readiness notifications and sockets straight through. When no containers run, nothing of Podman runs.
Rootless through user namespaces
Walsh’s complaint about the daemon model was that users must open a socket to a privileged daemon. Mapping a block of subordinate UIDs into a user namespace lets an ordinary user run containers without ever holding root on the host.
Pods from day one
Its ancestor kpod was a tool for inspecting and launching pods next to CRI-O, so Podman kept Kubernetes’ unit of grouped containers. That made it natural to read and write Kubernetes YAML, which podman play kube did by 1.0.
Its own network stack instead of CNI
CNI was built for Kubernetes clusters, while Podman needed single-host features such as DNS by container name and alias. In Podman 4.0 the team replaced it with Netavark and Aardvark, written in Rust, for better IPv6, multi-network containers and speed.

Timeline

  1. 2016

    kpod added to the CRI-O repository in November

  2. 2017

    Moves to its own repository; renamed Podman in December

  3. 2019

    Podman 1.0 in January; RHEL 8 ships Podman instead of Docker in May

  4. 2022

    Podman 4.0 brings the Netavark network stack

  5. 2024

    Podman 5.0 makes pasta the default rootless network

  6. 2025

    Accepted into the CNCF as a sandbox project in January

  7. 2026

    Podman 6.0 in June: CNCF GitHub organization, cgroups v1 and CNI removed

Sources43 · facts checked 5 October 2026

Improve this page on GitHub