It is! At least 99%, in my experience. The one big difference is that Podman is "daemonless", which is actually a huge advantage in a lot of cases. The one downside is that it won't automatically restart your containers if your host machine reboots.

For that Podman provides a nifty little trick: `podman generate systemd`[0] which allows you to generate systemd unit files for your pods and/or containers.

Once generated and enabled, your pods/containers act as systemd services that can be started, stopped etc.

[0]: https://docs.podman.io/en/latest/markdown/podman-generate-sy...

This is no longer necessary as of Podman 3.3 or so--there's a single Podman systemd unit that will launch all containers that have restart=always.

Interesting! Do you have by any chance a link the documentation about it, because so far all I could find are links to information about `podman generate systemd`.

That's awesome, I didn't know about that.

Looks like the service is called podman-restart.service on my system.

Yup. I use this for all my home server services like Plex, Adguard, etc.

I reboot my machine after kernel updates and everything comes up flawlessly.

This generator has even better systemd integration: https://github.com/containers/quadlet

I want to mention the "-userns=keep-id" option of podman, which is a reason enough to use podman rather than docker on a Linux laptop.

The "podman.service" systemd unit takes care of restarting containers that were marked so.

correction: podman-restart.service

The biggest drawback for me is that podman cannot build containers.

Huh? I use `podman build` all the time. Sure, it uses `buildah` in the backend, but does that really matter?

On Mac OS at least there is a bunch of hoops you have to jump through for build to work at all. If I recall you needed virtualbox installed (which I don't want). With docker it just works, you install docker you can run docker build, no extra troubleshooting, or hacky workarounds, just so you can use basic functionality.

Even better. It”s API compatible with the docker daemon.

You can run podman-system-service and get a socket/port that you can point the official Docker CLI or any Docker library at and it will just work (tm).

I’ve run into many issues with tools when moving from docker to podman, mostly because they tried to be smart.

Some tools try to detect whether podman exists on the system or not and change their behaviour accordingly. I couldn’t get docker-compose to work properly either even though I had a socket exposed.

I would much prefer if the podman binary/cli also supported the compose command.

Then there are slight differences such as the registry that is used by default when resolving. Docker defaults to docker.io where podman asks. The same when an image is available in multiple registries.