# Why I Switched to Podman (and Why You Might Too)

> I was a Docker loyalist for years, until I needed rootless containers. What won me over — and what still bites.

February 2, 2026 · 3 min read · https://yasint.dev/why-i-switched-to-podman/
Tags: docker, tools, linux

---

I've been a Docker loyalist for years. But lately, I've been experimenting with [Podman](https://podman.io/), and honestly? It's grown on me.

The switch started out of necessity. I've been working on [FEGA](https://github.com/ELIXIR-NO/FEGA-Norway) for a while, I needed rootless containers for security reasons. Docker can do rootless, but it always felt like an _afterthought_. Podman was built for it from day one.

## What's the Difference?

At the surface, not much. Podman is CLI-compatible with Docker. This works:

```bash
alias docker=podman
```

Seriously. Most commands just work. But [architecturally they're different](https://www.redhat.com/en/topics/containers/what-is-podman#what-makes-podman-different).

Docker runs a daemon. Every container talks to `dockerd`, which runs as _root_. Podman **doesn't have a daemon**. Containers run as child processes of your shell. No daemon means no single point of failure, no root process sitting there waiting.

## The Gotchas

### A few things bit me:

1. Compose — There's `podman-compose` and `podman play kube`, but honestly? We still use `docker-compose` with Podman as the backend. It just works. Set `DOCKER_HOST` to your Podman socket and your existing compose files run unchanged. Sometimes the boring solution is the right one.
2. Networking — Docker's bridge network just works out of the box. Podman needs more hand-holding when containers need to talk to each other:
```bash
podman network create mynet
podman run --network mynet --name app1 myimage
podman run --network mynet --name app2 myimage
```
3. Build caching — This is where Docker still wins. BuildKit has SPOILED ME.

### Docker BuildKit

It builds independent stages in parallel. If our multi-stage Dockerfile has a `frontend` and `backend` that don't depend on each other, they build at the same time. It also does [content-addressed caching](https://docs.docker.com/build/cache/)! Meaning that it can reorder your Dockerfile and the cache still hits if the files haven't changed.

For example:

```dockerfile
FROM node:20 AS frontend
# build frontend (base image #1) ...

FROM golang:1.22 AS backend
# build backend (base image #2)...

FROM alpine
# build final stage (base image #3)...
COPY --from=frontend /ui/dist /usr/share/nginx/html
COPY --from=backend /api/app /app
```

![BuildKit vs Buildah](./buildkit-vs-buildah.png)

Podman uses [Buildah](https://github.com/containers/buildah), which doesn't do parallel stages _yet_[^1]. For simple images you won't notice. For anything with heavy multi-stage builds, you will.

[^1]: If _you_ run multiple `buildah bud` commands at the same time (e.g., via CI jobs), those builds can run _concurrently_ — but that’s just external parallelism, not Buildah optimizing one build.

## When to Use What

I still reach for Docker when I need fast builds, or I'm just spinning up something throwaway. For anything _security-sensitive_ or closer to production? Podman.

They read the same Dockerfiles, pull from the same registries, produce OCI-compliant images. Switching between them costs nothing.

---

Been away from writing for most of 2025. Feels good to be back.