Introduction to Podman

Docker requires a daemon running with root privileges in the background. Podman does not. Every container is a standalone process under your regular user account. In this block, you understand this daemonless architecture, the OCI standard behind Podman, and why the concept was designed for Kubernetes from the start.

Since 2022, Docker Desktop has required a paid subscription for companies with more than 250 employees or over USD 10 million in annual revenue, and for government entities (USD 9 to 24 per developer per month depending on the plan, as of July 2026). Podman and Podman Desktop are Apache 2.0 licensed with no license fees. But licensing is only one reason: you see why RHEL, Fedora, and SUSE ship Podman as their default and what the ecosystem of Buildah, Skopeo, and Quadlet means for your daily work.

Podman runs directly on Linux, while macOS and Windows use a virtual machine through Podman Machine; Podman Desktop adds a graphical interface. You set up the appropriate runtime, then inspect containers.conf, registries.conf, and storage.conf before changing selected defaults and registry rules. A test run reveals which file affects container behavior, registry selection, and storage.

Docker Hub, Quay.io, GitHub Container Registry: you work with multiple registries at once and see how Podman finds the right source automatically via shortnames and registries.conf. With Skopeo, you copy images directly between registries without downloading them locally. That saves bandwidth and is invaluable in CI/CD pipelines.

The Podman CLI is over 95% identical to Docker. You test that hands-on and quickly notice where compatibility reaches its limits. In rootless mode, some things behave differently than expected. While debugging, you discover Podman-specific tools that most tutorials never mention.

Since Podman 4.0, networking runs on Netavark instead of the older CNI stack. The advantage: everything in one tool, noticeably faster, and DNS resolution now works reliably across multiple networks. You create bridge networks, connect containers, and understand when host or none mode is the better choice.

Containers are ephemeral, your data is not. You work with named volumes and bind mounts and verify that data survives a container restart. In rootless mode, you then encounter the single most common Podman issue: file permissions that suddenly behave differently than expected. You understand the root cause (UID/GID mapping) and learn how to handle it cleanly.

You describe images declaratively: every line in a Containerfile defines exactly one step, reproducible and version-controlled. You write your first image from scratch and learn the difference between Containerfile and Dockerfile along the way (technically identical, Podman prefers Containerfile). Under the hood, Podman uses Buildah as its build engine.

FROM, COPY, RUN, ENTRYPOINT, CMD, and the remaining commands: you learn them not as a checklist but through a continuous example. The focus is on the declarative approach and best practices that work today and will still hold in 20 years: how do you structure a Containerfile that stays maintainable? When ENTRYPOINT over CMD? Why does COPY belong before RUN?

Build tools, compilers, test frameworks: none of that belongs in the runtime image. Multi-stage builds cleanly separate build environment and runtime in a single Containerfile. You build a concrete example and see live how much bloat you eliminate. With distroless images, you go to the absolute minimum: no package manager, no shell, just your application and its dependencies.

Good images are small, secure, and build fast. You optimize layer caching for shorter build times, use .containerignore to exclude unnecessary files, and configure HEALTHCHECK and USER for production use. With podman secret, you manage credentials without baking them into the image. Finally, you build a multi-platform image for AMD64 and ARM64.

Before working with Podman Compose, you need solid YAML: indentation, lists, maps, anchors, and multi-line strings. Sounds trivial, but these cause the most common errors in compose.yaml files and Kubernetes manifests. You deliberately write broken files, debug the error messages, and know what matters afterward.

Your first compose.yaml defines multiple containers as a shared stack. With Compose v5 syntax, the deprecated version field is gone, and you work directly with the current standard. You also see the difference between the two Compose variants: podman-compose as a standalone tool and Docker Compose via the Podman socket. Both work, but not equally well in every scenario.

You define networks and volumes in compose.yaml, control startup order via depends_on with healthchecks, and integrate secrets that never end up in the image. With podman compose up --scale, you scale individual services and see how Podman handles load distribution.

Database, backend, frontend, reverse proxy: you set up a complete stack in Podman Compose and run it with healthchecks, secrets, and persistent data. You take the result home as a working template for your own projects.

Now it gets concrete: you compare architecture, security, compatibility, and licensing point by point. You test which Docker commands work identically in Podman, where the 5% differences lie, and what actually breaks during a migration. After this block, you can make an informed case in your team.

The Podman ecosystem separates image building, registry transport, and systemd operation across Buildah, Skopeo, and Quadlet. Using a prepared Containerfile, you build the image with Buildah and inspect the result. You then compare provided Skopeo output with a Quadlet file to assign registry transfer and persistent service operation to the other two tools.

podman kube generate creates Kubernetes YAML from running containers and Pods. podman kube play runs Kubernetes manifests locally, no cluster needed. That means: you develop locally with Podman and deploy the same manifest to the cluster. For single servers without Kubernetes, Quadlet with .kube files offers a lightweight alternative.

Docker has no equivalent to Pods. Podman does: containers that share network and PID namespace, exactly like in Kubernetes. You create your first Pod, add containers, test communication via localhost within the Pod, and generate a Kubernetes manifest at the end that runs directly in the cluster.