Podman vs Docker in 2026: Podman 6.1, Rootless, Quadlet and Licences

Every year somebody in a team channel asks whether we should "just switch to Podman", and every year the honest answer is "for what?". I run both, Docker on laptops and CI, Podman on single Linux hosts, and the gap is narrower and more specific than most comparisons suggest. This post explains Podman vs Docker as it stands in November 2026: how the daemonless and rootless designs actually differ, what Docker Desktop's licence costs, what Podman 6 broke, how well Compose works on Podman, where Quadlet and Kubernetes YAML fit, and the cases where each tool clearly wins. If you have already decided to move, the companion step-by-step guide to migrating from Docker Desktop to Podman has the commands.

Podman vs Docker: what is the actual difference?

Both tools build and run the same OCI images and push to the same registries. The difference is the process model underneath.

Docker is client and server. The docker CLI talks over a socket to dockerd, a long-running daemon that by default runs as root, which in turn drives containerd, a per-container shim and runc. Every container on the machine is a child of that daemon tree. If the daemon is down, so is your ability to manage anything, and anyone who can write to /var/run/docker.sock is effectively root on the host.

Podman is a fork and exec tool. When you run podman run, the CLI sets the container up itself, starts a small monitor process called conmon for that one container, and hands over to an OCI runtime (crun or runc). Then the CLI exits. There is no central daemon holding state in memory; state lives in a database on disk (SQLite only, since Podman 6.0 removed BoltDB). When you need a Docker-compatible API, Podman serves one on demand with podman system service, usually through systemd socket activation, so the "daemon" only exists while something is talking to it.

That choice explains most of what follows. Podman fits under systemd, because each container is a process tree systemd can supervise. Docker fits a developer machine, because one daemon is easy for a GUI, an IDE plugin and fifty tools to talk to.

Is Podman more secure than Docker? Rootless and daemonless explained

Podman's reputation for security comes from two defaults: no root daemon, and rootless containers. In rootless mode your containers run inside a user namespace mapped from the subordinate UID ranges in /etc/subuid, so "root" inside the container is your unprivileged user outside it. A container escape lands an attacker in your account, not in root's.

Docker can do this too. Rootless Docker runs the daemon and containers as a normal user, installed with dockerd-rootless-setuptool.sh install, and needs the same 65,536 subordinate IDs. The difference is that it is an opt-in mode most people never enable, whereas on Podman it is the default you get when you type the command as yourself.

Podman 6 tightened things further. It made network isolation the default to match Docker, removed slirp4netns in favour of Pasta for rootless networking, and removed iptables in favour of nftables. Neither tool makes a container a security boundary for hostile code. Both share the host kernel, so for untrusted workloads you still want a VM or gVisor layer, a trade-off I covered in container vs microVM vs gVisor. Rootless shrinks the blast radius of a mistake; it does not make strangers' code safe.

Is Docker Desktop free in 2026? Licences and the Podman Desktop alternative

This is the question that starts most migrations, so here are the actual terms. Docker Engine, the CLI, Compose and BuildKit are Apache-2.0 open source and free at any company size. The paid part is Docker Desktop, the VM, GUI and integrations on macOS and Windows (and optionally Linux). Under the Docker Desktop licence, it is free for personal use, education, non-commercial open source and "small businesses (fewer than 250 employees AND less than $10 million in annual revenue)". Both conditions must hold. Cross either line and every user needs a paid seat.

Podman, Podman Desktop and every part of the stack are Apache-2.0 with no commercial tier at all. Podman Desktop is a Red Hat-sponsored project; the paid support story is through RHEL rather than per-seat licences.

Option	Licence	Price per user per month	Notes	Source
Docker Personal	Docker subscription	$0	Only within the personal, education, OSS or small business terms	Docker pricing
Docker Pro	Docker subscription	$9 annual, $11 monthly	Individual developers	Docker pricing
Docker Team	Docker subscription	$15 annual, $16 monthly	Team management	Docker pricing
Docker Business	Docker subscription	$24 (same on yearly and monthly)	SSO, SCIM, Enhanced Container Isolation	Docker pricing
Podman and Podman Desktop	Apache-2.0	$0	No seats; Podman Desktop 1.30.5 is current	Podman Desktop releases

Do the arithmetic. A 300-person engineering org on Team pays about $54,000 a year at the annual rate. Real money, but someone will also spend months answering "Compose broke on my Mac" tickets after a switch. The licence is a reason to evaluate Podman, not a reason to skip the evaluation.

On the desktop app itself, Podman Desktop has caught up on the basics: container, image, pod and volume management, Kubernetes integration, extensions, and a Docker compatibility mode that links the Docker socket to the Podman machine. Its 1.30 release post of 14 October 2026 (1.30.0 itself was tagged on 21 September) lists Podman 6.1.4 and 5.8.9 as the bundled versions and shows each Docker context as its own connection. What it does not have is Docker's AI layer (Model Runner, the MCP Toolkit, Gordon), which I covered in the Docker 2026 state of containers post.

What changed in Podman 6, and who should care?

Podman 6.0.0 shipped on 24 June 2026 and was a clean-out release. It removed CNI networking (use Netavark), slirp4netns (use Pasta), iptables (use nftables), cgroup v1 and BoltDB. It also dropped Intel Macs and Windows 10 as host platforms, made libkrun the default podman machine provider on Macs, and changed podman volume prune to prune only anonymous volumes, as Docker does. The project moved to a CNCF-owned GitHub organisation, and the current release is 6.1.4 from 12 October 2026, with 6.2.0-rc1 in testing.

The Intel Mac part matters for teams with older hardware. Podman Desktop keeps bundling Podman 5 for Intel Mac installs, and the 5.8 series gets CVE and critical fixes until the second week of June 2027. After that, Intel Mac users are on their own. If half your laptops are 2019 MacBook Pros, that date belongs in your plan.

On Linux servers, check for cgroup v1 and iptables: current distributions are fine, older appliance images may not be.

Does Docker Compose work with Podman?

Mostly yes, by two routes. The first is podman compose, which is a thin wrapper: according to its man page it runs an external provider, preferring docker-compose if installed and falling back to podman-compose, and you can pin the choice with PODMAN_COMPOSE_PROVIDER or compose_providers in containers.conf. The second is to point the real Docker Compose (v5.7.0 is current) at Podman's socket with DOCKER_HOST. That second route is the one I would use, because then you are running the same Compose binary as everybody else and only the engine changes.

The API version story improved this year. Docker Engine 29.0 raised its minimum API to v1.44, then 29.3 lowered it back to v1.40 after a lot of tools broke. On the Podman side, 6.0 bumped the Docker-compatible API to v1.44 and 6.1 continued that work. In practice a current Docker CLI and Compose negotiate fine against Podman 6.

Where it still bites: Compose files that bind-mount /var/run/docker.sock into a container (Traefik, Watchtower, CI agents) need the socket to exist and, rootless, to point at your user's Podman socket. Rootless containers cannot bind ports below 1024 without changing net.ipv4.ip_unprivileged_port_start. Bind mounts can surface UID mismatches that Docker's root daemon hid. And Compose features that lean on BuildKit specifics may build differently under Buildah. None is a blocker; each costs someone a morning.

Quadlet and systemd: where Podman clearly wins

If you run containers on a single Linux host, this is the strongest reason to pick Podman. Quadlet lets you describe a container as a systemd unit file, and a systemd generator turns it into a real service at boot. You get systemd's restart policies, dependency ordering, journald logging and resource controls, without writing a wrapper script or running a separate daemon. The older podman generate systemd command is now marked deprecated in favour of Quadlet.

Here is a complete rootless web container as a Quadlet file. The keys come from podman-container.unit(5).

# ~/.config/containers/systemd/web.container  (Podman 6.1.4, rootless)
[Unit]
Description=nginx served by rootless Podman
After=network-online.target

[Container]
# Fully qualified name: Podman does not assume docker.io the way Docker does
Image=docker.io/library/nginx:1.30.6-alpine
ContainerName=web
PublishPort=8080:80
# Named volume, created on first start
Volume=web-content:/usr/share/nginx/html:Z
# Lets `podman auto-update` pull a newer digest and restart the unit
AutoUpdate=registry
HealthCmd=wget -q -O /dev/null http://127.0.0.1/

[Service]
Restart=on-failure

[Install]
# User units use default.target; you cannot `systemctl enable` a generated unit
WantedBy=default.target

systemctl --user daemon-reload          # run the Quadlet generator
systemctl --user start web.service      # start it now
loginctl enable-linger "$USER"          # keep user services running after logout
journalctl --user -u web.service -f     # logs go to journald

Docker's answer to this is restart: unless-stopped in Compose and a daemon that brings things back after reboot. That works, and plenty of people run it happily (I wrote about where it stops being enough in Docker Compose in production). But it means two supervisors on one box, systemd and dockerd, each with its own idea of what "running" means. Quadlet removes one of them. Today's systemd explainer covers the unit side in more depth.

Kubernetes YAML, pods and local clusters

Podman has pods as a first-class object, borrowed from Kubernetes: a group of containers sharing a network namespace. podman kube generate writes Kubernetes YAML from running containers or pods, and podman kube play runs YAML directly, currently supporting Pod, Deployment, PersistentVolumeClaim, ConfigMap, Secret, DaemonSet and Job. Quadlet has a .kube unit type that runs a YAML file as a systemd service. Handy for prototyping a pod spec.

It is not a Kubernetes API server: no scheduler, no Service or Ingress objects, and "works in kube play" does not mean "works on EKS". For real cluster behaviour on a laptop, Docker Desktop ships a built-in Kubernetes with a kind-based provisioner for multi-node clusters, and Podman Desktop drives kind or minikube through extensions. Neither replaces a staging cluster.

Is Podman faster than Docker?

For the container itself, no measurable difference should be expected on Linux: both hand the process to an OCI runtime, both use overlay storage and cgroups, and once the process is running the kernel does the same work. Podman usually ships with crun, written in C, and Docker with runc, written in Go, and the runtime is a small slice of start-up time either way. I have not found a current independent benchmark worth quoting.

Where you feel differences is around the container. Rootless networking adds a userspace hop for published ports in both engines (rootlessport or Pasta for Podman, RootlessKit for Docker), which matters for high-throughput services, not a dev database. On macOS and Windows, both tools run Linux in a VM, so file sharing between host and VM dominates "feels slow" complaints. Podman 6 on Apple silicon defaults to libkrun, Docker Desktop uses Apple's virtualisation framework with VirtioFS. Test your own bind-mount-heavy workload (a big node_modules, a monorepo build) on both.

Podman vs Docker: when each one wins

Situation	Better fit	Why	Source
Company over 250 staff or $10M revenue, Mac and Windows laptops	Podman Desktop, or pay for Docker	Docker Desktop needs a paid seat	Docker licence
Long-running services on a single Linux host	Podman with Quadlet	systemd supervises containers directly	Quadlet docs
Heavy Compose and BuildKit users, Docker-specific tooling	Docker	Largest ecosystem, fewest edge cases	Compose releases
RHEL, Fedora, CentOS Stream hosts	Podman	Shipped and supported by the distribution	Podman install
Intel Macs after June 2027	Neither cleanly	Podman 6 dropped Intel Macs; 5.8 support ends	Podman Desktop blog
Teams using Docker Model Runner or MCP Toolkit	Docker Desktop	No Podman equivalent built in	Docker Desktop notes
Kubernetes nodes	Neither	Kubelet talks to containerd or CRI-O, not Docker or Podman	Kubernetes CRI

Your laptop tool has no effect on what runs your production pods.

FAQ

Is Podman a drop-in replacement for Docker?

For the CLI, close to it: most docker commands work with podman substituted, and Podman Desktop can alias the Docker CLI and socket. The gaps are image short names (use fully qualified names like docker.io/library/nginx), rootless port and permission differences, and tools that assume a root daemon socket. Plan for a short shakedown, not a zero-effort swap.

Can I use Docker Compose with Podman?

Yes. Either run podman compose, which delegates to docker-compose or podman-compose, or point Docker Compose at Podman's socket with DOCKER_HOST. Podman 6 implements the Docker API at v1.44, which current Compose releases negotiate against without trouble.

Is Docker Desktop free for commercial use?

Only for businesses with fewer than 250 employees and less than $10 million in annual revenue, plus personal, education and non-commercial open source use. Larger organisations need Pro, Team or Business seats at $9 to $24 per user per month on annual billing. Docker Engine on Linux is free and open source regardless.

Should I use Podman or Docker in production?

On a single Linux host running a handful of services, Podman with Quadlet is the cleaner design because systemd becomes the only supervisor. On Kubernetes the question does not apply, since nodes run containerd or CRI-O. If your team already runs Compose on Docker Engine and it works, migrating for its own sake is rarely worth it.

This quarter I would do three things. Check whether your company is over the Docker Desktop thresholds and what the seats actually cost, then give two or three volunteers a week on Podman Desktop with your real Compose files and bind mounts, and write down every friction point. Move any single-host Linux services still running under docker run --restart or Compose to Quadlet units, because that is where Podman is simply better. And if you have Intel Macs, put June 2027 on the calendar now. The migration guide walks through the laptop side step by step.

Related: Docker in 2026: Engine 29, containerd 2.3 LTS, Podman 6 and the AI Push, Docker Compose in Production (2026): Is v5.6 Enough, or Do You Need K8s? and Container vs microVM vs gVisor: Choosing Agent Isolation.