What is Podman?

Podman is a tool for working with containers - it pulls images, runs containers, builds new images, and pushes them to registries. In other words, it does the same job as Docker, and it does it with nearly identical commands. The name is short for "pod manager," a hint at the one big idea it adds on top.

Podman is open source and was created by Red Hat, the company behind Red Hat Enterprise Linux and a major contributor to the broader container ecosystem. Two design choices set it apart from Docker: it runs without a central background daemon, and it can run containers without root privileges. Both choices are about security and simplicity, and we will unpack each below.

The container engine that speaks Docker, minus the daemon and the root.- the short version

The Docker-compatible promise

The most important thing to know about Podman is that it was built to be a drop-in match for the Docker command line. Almost every command you know transfers directly - the verbs, the flags, and the behavior are the same.

Docker vs Podman
# Docker $docker run -d -p 8080:80 nginx   # Podman - identical, just swap the word $podman run -d -p 8080:80 nginx

The compatibility goes deeper than the verbs. Podman works with the same images everyone already uses, because both tools follow the Open Container Initiative (OCI) standards for image and runtime formats. It pulls from the same registries - Docker Hub, GitHub Container Registry, Quay, and any private registry - and it reads the same Dockerfile to build images. Many teams that switch even add a shell alias, alias docker=podman, so existing scripts and muscle memory keep working without a single edit.

The practical upshot: the things you learned about Docker are not wasted. Podman is a different engine under the same steering wheel.

Daemonless by design

Here is the first real architectural difference. Docker runs a long-lived background service called a daemon (dockerd). When you type a docker command, the CLI is really just sending a request to that daemon, which does the actual work of running and supervising every container on the machine.

Podman has no daemon. When you run podman run, Podman starts the container as a direct child process of your command and then gets out of the way. There is no central service sitting in the background owning everything.

This sounds like a small plumbing detail, but it changes a few things in practice:

  • Smaller attack surface. The Docker daemon traditionally runs as root and is a single privileged process that controls every container. Removing it removes that one high-value target.
  • No single point of failure. If a daemon crashes, it can take its containers down with it. With Podman, each container stands on its own.
  • It fits Linux conventions. Because containers are ordinary child processes, the operating system's own service manager, systemd, can supervise them directly - start them on boot, restart them on failure - just like any other Linux service.

The tradeoff is that some workflows that assumed an always-on daemon (background event streams, certain remote-API integrations) need a small adjustment. Podman can run an optional API service for exactly those cases, but it is opt-in rather than always running.

Rootless containers

The second defining feature is that Podman can run containers as a normal, unprivileged user - no administrator rights required. This is called rootless mode, and it is the default way most people use Podman.

Why does this matter? In a traditional root-based setup, a process that escapes its container could potentially gain root on the host machine - the worst-case outcome. In rootless mode, a container runs with your ordinary user permissions, so even a breakout lands an attacker in an unprivileged account rather than handing them the whole machine. It is a meaningful reduction in blast radius, and it is why rootless containers are popular in security-conscious and multi-user environments.

bash
# no sudo - this runs entirely as your own user $podman run --rm -it alpine sh $whoami # root *inside* the container... # ...but mapped to your unprivileged user on the host

Inside the container you can still be root and install packages as normal - Podman uses a Linux feature called user namespaces to map that in-container root to your real, limited user on the host. You get the convenience of root where you need it and the safety of running unprivileged where it counts.

Pods, the Kubernetes-shaped idea

This is where Podman's name comes from. A pod is a group of containers that share some resources - most importantly a network, so containers in the same pod can talk to each other over localhost as if they were on one machine.

If that sounds familiar, it should: the pod is the fundamental unit of Kubernetes, the dominant system for running containers in production. Podman deliberately borrows the same concept so that the way you group containers on your laptop matches the way they will be grouped in a cluster.

bash
# create a pod, then run containers inside it $podman pod create --name web -p 8080:80 $podman run -d --pod web nginx $podman run -d --pod web redis # nginx and redis now share a network namespace

Grouping a web server and its cache into one pod on your machine mirrors how you would deploy them together in Kubernetes - which is exactly the bridge the next section is about.

The toolset around it

Podman is the front door to a small family of focused, composable tools that Red Hat and the community build alongside it. Each does one job well, and Podman leans on them under the hood.

  • Buildah builds OCI images. Podman's own build command uses Buildah internally, but you can also use it directly for fine-grained, scriptable image builds without a Dockerfile.
  • Skopeo moves and inspects images between registries without pulling them onto your machine first - handy for copying, signing, and auditing images in pipelines.
  • Podman Desktop is a graphical app, much like Docker Desktop, for people who would rather click than type. It manages containers, images, and pods, and can even connect to Kubernetes clusters.

The philosophy is the opposite of one big do-everything daemon: several small, single-purpose tools you can combine. For Mac and Windows users, Podman also ships a "machine" feature (podman machine) that runs a small Linux VM behind the scenes, since containers are fundamentally a Linux technology - the same approach Docker Desktop takes.

From your laptop to Kubernetes

Because Podman already thinks in pods, it can act as a stepping stone toward Kubernetes. It can take the containers and pods you are running locally and write out the Kubernetes configuration file that would deploy the same thing in a cluster.

bash
# turn a running pod into Kubernetes YAML $podman kube generate web > web.yaml   # ...and run a Kubernetes YAML file locally $podman kube play web.yaml

This two-way street - generate Kubernetes config from local pods, and run Kubernetes config locally - makes Podman a comfortable place to develop before you ever touch a real cluster. You are not learning one mental model for your laptop and a different one for production; it is pods the whole way down.

Where Podman fits and where it doesn't

Podman is a strong default for a lot of work, but it is not a universal replacement, and it helps to know the edges.

Reach for Podman when security matters (rootless and daemonless are real advantages), when you are on Linux - especially Red Hat, Fedora, or CentOS, where it is the native, pre-installed choice - when you want containers supervised by systemd, or when you are heading toward Kubernetes and want your local setup to match.

Be aware that some of the ecosystem still assumes Docker by name. Tooling, CI integrations, and tutorials sometimes hardcode the docker command or expect the Docker daemon's API. Podman covers most of this with its Docker-compatible CLI and optional API service, and podman compose handles multi-container apps, but you may occasionally hit a tool that needs a small tweak. The gap is much smaller than it used to be, and it keeps shrinking.

Why developers choose it

The appeal of Podman is that it keeps the part of Docker everyone likes - the simple, memorable command line - while quietly fixing the parts that made security teams nervous. No privileged daemon running in the background. No need for root. Containers that behave like ordinary processes your operating system already knows how to manage.

For individual developers, the switch is nearly invisible: the commands are the same, the images are the same, the registries are the same. For platform and security teams, the architecture is meaningfully safer by default. And for anyone heading toward Kubernetes, the shared concept of the pod means the habits you build locally carry straight into production.

Docker made containers usable for everyone, and it is still an excellent tool. Podman is the answer to a narrower question: can we keep all of that and run it more safely, with fewer moving parts? For a growing number of teams, the answer is yes.

References