Podman in 2026: the daemonless, rootless container engine becoming the default

The Docker alternative that stopped being optional

For a decade, "containers" and "Docker" were near-synonyms. In 2026 they no longer are. Podman has become the default container engine on Red Hat Enterprise Linux 10, Fedora, and AlmaLinux — three of the most widely deployed enterprise and desktop distros on the planet. Red Hat removed the Docker daemon from RHEL back in version 8, and it has not returned. On any of those systems, the container engine you get out of the box is Podman.

The switch is not cosmetic. Podman was built around an architectural bet: that a container engine does not need a central, always-on, root-level daemon. Docker runs through a long-lived dockerd process that brokers every request. Podman does not. Each container runs as a child of your own per-user podman process, in a fork/exec model. There is no single privileged daemon to crash, and nothing listening on a root-owned socket waiting to be attacked.

Rootless by default

That design unlocks a second difference, arguably the bigger one: Podman runs rootless out of the box. A normal user can create and run containers without ever touching sudo. The trick is Linux user namespaces. Podman maps container user IDs onto a private range the host reserves for you in /etc/subuid and /etc/subgid — lines like johndoe:100000:65536. "Root" inside the container is really just your unprivileged username on the host, with no special powers outside its namespace. A compromised container stays quarantined.

For most teams this makes migration easy because the CLI and image format did not change. Podman speaks the same OCI images Docker uses, and its commands mirror Docker almost 1:1: podman run, podman build, podman ps. On RHEL-family systems the podman-docker package even provides a docker command and API that translate to Podman underneath. podman compose serves as a compatibility layer for docker compose, running most multi-container stacks with minimal changes. If you have used Docker, you already know how to use Podman.

Quadlet: containers as systemd services

Where Podman genuinely outshines Docker is service management. On a single server you want a container to start at boot, restart on crash, and log like any other daemon. Quadlet, a systemd generator shipped in Podman since 4.4, makes that declarative. You drop a small INI file ending in .container into ~/.config/containers/systemd/, and systemd turns it into a real service and supervises it.

For self-hosting, this is the killer feature. Here is a running example — a Caddy reverse proxy that boot-starts, survives crashes, and lives after you log out:

# ~/.config/containers/systemd/caddy.container
[Unit]
Description=Caddy reverse proxy (rootless)

[Container]
Image=docker.io/library/caddy:latest
ContainerName=caddy
PublishPort=8081:80
Volume=%h/caddy-data:/data:Z

[Service]
Restart=always

[Install]
WantedBy=default.target

Then, once with loginctl enable-linger $USER so rootless services survive logout:

systemctl --user daemon-reload
systemctl --user enable caddy
systemctl --user start caddy

That is it. Crash recovery (Restart=always), boot-time start (WantedBy=default.target), and journald logging come from systemd itself — not from a fragile wrapper script. Declare it, reload, and the container behaves like any system daemon.

The last gap closed with Podman Desktop, a free GUI running on macOS, Windows, and Linux that provides the dashboard-like comfort Docker Desktop gave laptop developers — container list, image building, and deploy to a Podman engine behind the scenes.

None of this requires abandoning what you know. The defaults changed; the muscle memory did not. That is why Podman stopped being the "other" engine and became the default one. Curious about more of the modern self-hosted stack? We write about adjacent tools over at https://tama.fdhcl.com