Podman on Linuxize

Podman vs Docker: Differences and Migration Guide

hello@linuxize.com (Linuxize) — Wed, 03 Jun 2026 12:40:00 +0200

For most of the last decade, “containers on Linux” meant Docker. The CLI, the image format, the workflow, and the muscle memory all came from one tool. Podman entered the picture as a drop-in alternative built around a different architecture: no daemon, rootless by default, and tighter integration with systemd.

The two tools build and run OCI containers from the same images, expose nearly identical commands, and target the same workloads. The differences start to matter when you look at how containers are started, who owns them, how they run at boot, and what your existing tooling expects. This guide walks through how Podman and Docker compare in practice, and what a realistic migration looks like for a server already running Docker.

Quick Reference

For a printable quick reference, see the Podman cheatsheet .

Aspect	Docker	Podman
Architecture	Long-lived `dockerd` daemon	Daemonless, runs containers directly
Default privileges	Root, with rootless as opt-in	Rootless by default
systemd integration	Manual unit or restart policy	First-class via Quadlet `.container` files
Pods	Not available	Native, Kubernetes-style pods
Image build backend	Docker builder and BuildKit	Buildah
Compose	Docker Compose	`podman compose`, `podman-compose`, or Compose over the Podman socket
Default network backend	`bridge` (`docker0`)	`netavark` (rootless uses `pasta` or `slirp4netns`)
Image and CLI format	OCI images, `docker` CLI	OCI images, `podman` CLI plus `docker` alias

Same Image Format, Same CLI Surface

Both Podman and Docker work with OCI-compliant images and containers. Anything you pull from Docker Hub, quay.io, or a private registry runs the same way in either tool. The high-level commands also match:

Terminal
podman run -d -p 8080:80 --name web nginx
podman ps
podman stop web
podman rm web

Swap podman for docker in those lines and the result is the same. Podman ships a docker alias as part of its package on most distributions, so existing scripts that call docker ... continue to work without changes:

Terminal
sudo apt install podman-docker
docker ps

For everyday commands, Podman is intentionally close to Docker. If your workflow is mostly run, ps, logs, exec, and build, the commands will feel familiar. The larger differences sit underneath.

Daemon vs Daemonless

Docker runs a long-lived background daemon (dockerd) that manages container state on the host. The docker CLI is a client that talks to that daemon over a Unix socket. If the daemon is unavailable, you cannot create, stop, inspect, or attach to containers through the Docker CLI. Existing containers can keep running when Docker is configured with live restore, but the daemon is still the control plane for normal operations.

Podman has no daemon. When you run podman run, the CLI spawns the container directly using runc or crun as the OCI runtime, and exits. The container’s parent is your shell or whatever supervisor you choose, not a privileged background process.

This has a few practical consequences:

There is no long-running container daemon to restart for ordinary CLI use. Updating Podman does not stop containers that are already running.
Each container can be owned by a regular user account. The container’s processes show up in that user’s process tree, not under a root daemon.
Tools that expect a Docker socket need an explicit Podman socket service if you want API compatibility.

For the Podman socket, you enable a user or system service:

Terminal
systemctl --user enable --now podman.socket

The socket exposes a Docker-compatible REST API at $XDG_RUNTIME_DIR/podman/podman.sock, which lets tools like docker-compose or CI runners talk to Podman as if it were Docker.

Rootless Containers

Both tools support rootless containers, but the defaults differ. Docker historically runs as root, with rootless mode available as an opt-in setup that requires extra packages and a per-user installation. Podman is designed around rootless use. A regular user can pull images, build, and run containers without sudo as soon as the user namespace prerequisites are in place.

To run a container as a regular user with Podman:

Terminal
podman run -d -p 8080:80 --name web nginx

The container’s processes run as a UID inside a user namespace mapped to the invoking user on the host. From the host’s perspective, the container is owned by your user, not root, which limits the blast radius of a container escape and removes the need for the user to be in a docker group (which is effectively equivalent to giving root).

For most developer workstations and many production scenarios, rootless Podman is enough. Workloads that need privileged ports below 1024 or specific kernel features still benefit from a rootful install, but the default for new users is unprivileged.

systemd Integration and Quadlet

Docker treats containers as something separate from system services. To run a containerized app at boot, you usually rely on docker-compose with a restart policy, a separate process supervisor, or a hand-written systemd unit that calls docker run.

Podman integrates with systemd as a first-class option. Containers can be generated into systemd unit files, and modern Podman supports Quadlet, a declarative format that turns a small .container file into a fully managed systemd service.

A minimal Quadlet file at ~/.config/containers/systemd/web.container:

~/.config/containers/systemd/web.containerini
[Unit]
Description=Nginx Web

[Container]
Image=docker.io/library/nginx:latest
PublishPort=8080:80

[Install]
WantedBy=default.target

After reloading the user daemon, the container becomes a normal systemd unit:

Terminal
systemctl --user daemon-reload
systemctl --user start web
systemctl --user status web

You get journald logs, restart policies, dependencies on other units, and timers, all without writing a wrapper script. This is one of the strongest practical reasons to pick Podman on a Linux server.

Compose Workflows

Docker Compose is a major part of how teams use Docker. Multi-container apps live in a docker-compose.yml file and run with a single command. Podman supports the same workflow in a few ways.

The most direct option on current Podman releases is the Compose provider exposed through podman compose. Depending on your distribution, that command may call docker-compose, Docker Compose v2, or podman-compose behind the scenes:

Terminal
podman compose up -d

Another option is podman-compose, a Python implementation of the Compose spec that runs against the Podman CLI:

Terminal
podman-compose up -d

The most compatible path for existing Compose projects is often to enable the Podman socket and run the regular Docker Compose binary against it. This is useful when a project depends on Compose features that podman-compose does not fully match:

Terminal
systemctl --user enable --now podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
docker compose up -d

For new projects, Quadlet often replaces Compose entirely on Podman. Each service becomes a .container file, networks become .network files, and systemd takes over orchestration.

Pods

Podman’s name comes from the feature that Docker does not have: pods. A pod is a group of containers that share a network namespace and (optionally) other namespaces, similar to a Kubernetes pod. You create a pod and add containers to it:

Terminal
podman pod create --name app -p 8080:80
podman run -d --pod app --name web nginx
podman run -d --pod app --name cache redis

Both containers share localhost and the host port mapping, so web can reach Redis at 127.0.0.1:6379 without any custom network setup. This is useful when you are testing services that expect to share localhost, and it also matches the way Kubernetes groups containers inside a pod.

Docker does not have a direct equivalent. Multi-container patterns in Docker rely on user-defined networks or Compose stacks.

Networking Differences

Both tools provide bridge networks, host networking, and DNS resolution between containers in the same user-defined network. The default network drivers differ.

Docker uses its own bridge driver by default, with docker0 on the host.
Podman uses netavark on current releases, with legacy CNI still present on older systems. Rootless containers use pasta or slirp4netns for userspace networking.

For straightforward workloads (publish ports, talk to upstream services, attach to a user network), the experience is the same. The differences show up when you need advanced DNS behavior, IPv6 inside containers, or specific MAC/IP assignments, where the two stacks diverge.

Building Images

Both tools build images from a Dockerfile (Podman calls it a Containerfile, but accepts both). The build commands match:

Terminal
podman build -t myapp:1.0 .

Podman delegates builds to buildah under the hood, while Docker has its own builder (and BuildKit for advanced features). For day-to-day builds the difference is invisible. For advanced cases (multi-platform builds, cache mounts, secret mounts), BuildKit has more features today, though Buildah has been catching up steadily.

If you build a lot of images and use BuildKit-specific syntax (# syntax=docker/dockerfile:1.4), test those Dockerfiles with Podman before assuming a clean migration.

Performance and Resource Use

For application workloads, performance is dominated by the workload itself, not the runtime. Both tools use the same kernel features (cgroups, namespaces, overlay filesystems) and run containers as regular Linux processes.

Two areas where you may notice a difference:

Startup overhead is similar; both spawn a runtime and a container process. Podman has no daemon to wait on, but the per-container cost is comparable.
Memory footprint for the runtime itself favors Podman on a host with many idle containers, because there is no long-running daemon keeping connections and state in memory.

For most users, performance is not the deciding factor between the two tools.

A Practical Migration Path

A realistic Docker-to-Podman migration on an existing server does not need to be all-or-nothing. A common path:

Install Podman alongside Docker. They can coexist on the same host because each tool manages its own state directory.
Terminal
```
sudo apt install podman
```
Pull and run one non-critical container as your user with Podman:
Terminal
```
podman run -d -p 9000:80 --name test nginx
curl http://localhost:9000
```
Move one Compose stack to either podman compose, podman-compose, or the Podman socket with Docker Compose. Confirm the app behaves the same.
Convert the most stable services to Quadlet units so systemd takes over restart, logging, and boot ordering. This is usually where the operational win shows up.
Once every workload runs cleanly under Podman, stop and disable the Docker service, then remove the package.
Terminal
```
sudo systemctl disable --now docker
sudo apt remove docker-ce docker-ce-cli containerd.io
```

Plan for storage migration. Docker and Podman do not share the same image store. The simplest path is to export your important images with docker save and import them with podman load:

Terminal
docker save myapp:1.0 | podman load

For data volumes, treat them like any other host directory: bind-mount the same path from both runtimes during the transition, then point only Podman at it once you cut over.

When to Stay on Docker

Docker is still the right tool when:

Your CI, hosting platform, or orchestrator assumes Docker (Docker Desktop, certain managed runners, some Kubernetes ingress workflows).
Your team relies on advanced BuildKit features that Buildah does not match in your workflow.
You use Docker Swarm or third-party tooling that talks only to the Docker daemon.
You want a single supported product across Linux, macOS, and Windows, with a consistent GUI.

When to Switch to Podman

Podman is the better fit when:

You run containers on a Linux server and want them managed as systemd units.
You want rootless containers by default, with no docker group equivalent.
You target Kubernetes in production and want local pods that map to the same concepts.
You prefer a daemonless architecture for upgrades, restarts, and security boundaries.
You are on a distribution where Podman is the default container engine, such as Fedora, RHEL, or CentOS Stream.

Conclusion

Podman and Docker overlap heavily on the CLI surface and image format, so adopting Podman is rarely a rewrite. The main reasons to choose Podman are the daemonless architecture, rootless defaults, and clean systemd lifecycle. On a new Linux server, Podman is often the simpler choice for long-running services. On an existing Docker host, move one workload at a time and use Quadlet when you are ready for systemd to manage the container. If you have not installed Podman yet, the Podman on Ubuntu guide is the next step.

How to Install Podman on Ubuntu: Rootless Container Alternative to Docker

hello@linuxize.com (Linuxize) — Tue, 19 May 2026 09:40:00 +0200

Podman is a daemonless container engine that runs OCI containers without a long-lived root process. Each container is started as a regular user-owned process, which removes the privileged daemon that Docker relies on and makes containers safer to run on shared servers. The command-line surface mirrors Docker almost exactly, so most Dockerfiles, image references, and docker run patterns work with little to no change.

This guide explains how to install Podman on Ubuntu, configure rootless mode, run your first container, and use Podman as a drop-in replacement for the Docker CLI.

Quick Reference

For a printable quick reference, see the Podman cheatsheet .

Task	Command
Install Podman	`sudo apt install podman`
Run a container	`podman run -d --name web -p 8080:80 nginx`
List containers	`podman ps -a`
Build an image	`podman build -t myimage .`
List images	`podman images`
Pull an image	`podman pull alpine:latest`
Stop and remove	`podman rm -f web`
Inspect rootless setup	`podman info`

Install Podman

Podman has been part of the Ubuntu universe repository since 20.10, so on every supported release you can install it through apt without adding a third-party PPA.

Update the package index, then install:

Terminal
sudo apt update
sudo apt install podman

Confirm the version:

Terminal
podman --version

output

podman version 5.7.0

Ubuntu 26.04 ships Podman 5.7 from the universe repository. Ubuntu 24.04 ships the 4.9 series, while Ubuntu 22.04 ships the 3.4 series, so the exact version depends on the Ubuntu release you are using.

Verify the Rootless Setup

Podman supports both root and rootless modes, and the rootless mode is the one most users want. Run podman info as your regular user and look for rootless: true:

Terminal
podman info | head -20

output

host:
arch: amd64
cgroupManager: systemd
...
security:
rootless: true

Two pieces have to be in place for rootless containers to work: subordinate UID/GID mappings, and a user namespace. Ubuntu sets both up automatically on first run, but you can confirm with:

Terminal
cat /etc/subuid /etc/subgid

output

sara:100000:65536
sara:100000:65536

Each user gets a range of 65,536 subordinate UIDs and GIDs that Podman uses to map container processes to non-overlapping host IDs. If the file is missing your user, add an entry with sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 sara and run podman system migrate to apply the change.

Run Your First Container

Pull and run an Nginx container in detached mode, exposing port 8080 on the host:

Terminal
podman run -d --name web -p 8080:80 nginx

output

Resolved "nginx" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull docker.io/library/nginx:latest...
Getting image source signatures
Copying blob sha256:...
Writing manifest to image destination
Storing signatures
2b9bd4e1f3...

Check that the container is running:

Terminal
podman ps

output

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2b9bd4e1f3a8 docker.io/library/nginx:latest nginx -g daemon o... 10 seconds ago Up 10 seconds 0.0.0.0:8080->80/tcp web

Hit the published port from the host:

Terminal
curl -I http://localhost:8080

output

HTTP/1.1 200 OK
Server: nginx/1.27.4

The response confirms that the user-mode network stack forwarded the request into the container correctly. Stop and remove the container with:

Terminal
podman rm -f web

Configure Registries

By default Podman searches a configured list of registries when you run podman pull nginx (without a registry prefix). The list lives in /etc/containers/registries.conf. To prefer Docker Hub, edit the file:

Terminal
sudo nano /etc/containers/registries.conf

Set the unqualified-search registries:

/etc/containers/registries.conftoml
unqualified-search-registries = ["docker.io", "quay.io"]

Save and exit. From now on podman pull alpine resolves to docker.io/library/alpine:latest, which matches Docker’s default behavior. Save yourself confusion by always pulling with the full reference (podman pull docker.io/library/alpine) in scripts and CI pipelines.

Use Podman as a Docker Replacement

If you already have shell history, Makefiles, or scripts that call docker, install the alias package and keep them working:

Terminal
sudo apt install podman-docker

The package adds a /usr/bin/docker symlink that points to podman, plus a stub that suppresses the daemon-not-running warning. Test it:

Terminal
docker run --rm hello-world

output

Hello from Docker!

Behind the scenes, docker run invoked podman run. Most everyday commands (build, pull, push, images, ps, logs, exec) work identically. The differences show up around Docker Compose and the daemon socket; Podman 4 ships its own socket that Docker Compose can target by setting DOCKER_HOST.

Build an Image with a Dockerfile

Podman builds OCI images from a standard Dockerfile, no changes required. Create a small Flask app to demonstrate:

Terminal
mkdir hello-podman && cd hello-podman
nano app.py

app.pypy
from flask import Flask

app = Flask(__name__)


@app.route("/")
def index():
 return "Hello from Podman!"


if __name__ == "__main__":
 app.run(host="0.0.0.0", port=5000)

Write the Dockerfile:

Dockerfiledockerfile
FROM python:3.12-slim
WORKDIR /app
RUN pip install --no-cache-dir flask
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Build the image:

Terminal
podman build -t hello-podman .

output

STEP 1/6: FROM python:3.12-slim
STEP 2/6: WORKDIR /app
...
Successfully tagged localhost/hello-podman:latest

Run a container from the new image:

Terminal
podman run -d --name hello -p 5000:5000 hello-podman
curl http://localhost:5000

output

Hello from Podman!

The image and container both live in the user’s storage (~/.local/share/containers), so no sudo is involved at any step.

Run Pods of Containers

The name “Podman” comes from its support for Kubernetes-style pods: groups of containers that share a network namespace. Create an empty pod, then add containers to it:

Terminal
podman pod create --name webapp -p 8080:80
podman run -d --pod webapp --name redis redis:7
podman run -d --pod webapp --name nginx nginx

Inside the pod, nginx can reach Redis at localhost:6379 because they share the network namespace. List pods with:

Terminal
podman pod ps

output

POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
8f4d7b8c0e1f webapp Running 20 seconds ago c2a8f9b1d3e4 3

The count of three includes an infra container that holds the shared namespaces.

Run Podman as a systemd Service

To start a container at boot in rootless mode, use a Quadlet container unit. Quadlet is Podman’s current systemd integration method and keeps the container definition in a small, readable file.

Terminal
mkdir -p ~/.config/containers/systemd
nano ~/.config/containers/systemd/web.container

Add the container definition:

~/.config/containers/systemd/web.containerini
[Unit]
Description=Rootless Nginx container

[Container]
Image=docker.io/library/nginx:latest
ContainerName=web
PublishPort=8080:80

[Service]
Restart=always

[Install]
WantedBy=default.target

Reload the user systemd manager, then start the generated service:

Terminal
systemctl --user daemon-reload
systemctl --user start web.service

Enable lingering so the user services keep running after logout:

Terminal
sudo loginctl enable-linger sara

The [Install] section tells the Podman systemd generator to attach the service to the user’s default target. The container now starts without root or a system-wide daemon.

Troubleshooting

Error: short-name "nginx" did not resolve to an alias
The unqualified-search-registries list is empty. Edit /etc/containers/registries.conf and add at least docker.io, or pull with the full reference (podman pull docker.io/library/nginx).

ERRO[0000] cannot find UID/GID for user
The current user has no entry in /etc/subuid or /etc/subgid. Run sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USER, then podman system migrate.

Ports under 1024 refuse to bind in rootless mode
The kernel restricts low ports for non-root users. Either publish to a high port (-p 8080:80), or allow your user to bind low ports with sudo sysctl net.ipv4.ip_unprivileged_port_start=80.

FAQ

Is Podman a drop-in Docker replacement?
For everyday run, build, pull, push, and exec workflows, yes. Compose and the long-lived socket need extra setup. Most CI jobs only need the CLI and switch over without changes.

Does Podman work with Docker Compose?
Yes. Start the Podman socket with systemctl --user enable --now podman.socket, export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock, and run docker compose up.

Are Podman images compatible with Docker?
Yes. Both produce OCI-compliant images, so an image built with podman build runs unchanged under Docker, and vice versa.

Conclusion

Podman gives you the Docker workflow without the daemon and without root, which is often what you want on a multi-user server or a developer workstation. Install it from apt, alias docker if you have existing scripts, and the rest of the CLI feels familiar.

For follow-up reading, see our guides on installing Docker on Ubuntu 26.04 and building Docker images with a Dockerfile .

Podman on Linuxize

Podman vs Docker: Differences and Migration Guide

Quick Reference #

Same Image Format, Same CLI Surface #

Daemon vs Daemonless #

Rootless Containers #

systemd Integration and Quadlet #

Compose Workflows #

Pods #

Networking Differences #

Building Images #

Performance and Resource Use #

A Practical Migration Path #

When to Stay on Docker #

When to Switch to Podman #

Conclusion #

How to Install Podman on Ubuntu: Rootless Container Alternative to Docker

Quick Reference #

Install Podman #

Verify the Rootless Setup #

Run Your First Container #

Configure Registries #

Use Podman as a Docker Replacement #

Build an Image with a Dockerfile #

Run Pods of Containers #

Run Podman as a systemd Service #

Troubleshooting #

FAQ #

Conclusion #

Quick Reference

Same Image Format, Same CLI Surface

Daemon vs Daemonless

Rootless Containers

systemd Integration and Quadlet

Compose Workflows

Pods

Networking Differences

Building Images

Performance and Resource Use

A Practical Migration Path

When to Stay on Docker

When to Switch to Podman

Conclusion

Quick Reference

Install Podman

Verify the Rootless Setup

Run Your First Container

Configure Registries

Use Podman as a Docker Replacement

Build an Image with a Dockerfile

Run Pods of Containers

Run Podman as a systemd Service

Troubleshooting

FAQ

Conclusion