[bonzini]

> podman had a much worse performance compared to docker on my small cloud vps. Can't really go into details though.

Are you using rootless podman? Then network redirection is done using user more networking, which has two modes: slirp4netns is very slow, pasta is the newer and good one.

Docker is always set up from the privileged daemon; if you're running podman from the root user there should be no difference.

[Tajnymag]

Well, yes, but rootless is basically the main selling point of podman. Once you start using daemons and privileged containers, you can just keep using docker.

[bonzini]

No, the main selling point is daemonless. For example, you put podman in a systemd unit and you can stop/start with systemctl without an external point of failure.

Comparing root docker with rootless podman performance is apples to oranges. However, even for rootless pasta does have good performance.

[curt15]

Some tools talk to docker not using the docker CLI but directly through its REST API. Podman also exposes a similar REST API[1]. Is Podman with its API server switched on substantially different from the docker daemon?

[1]. https://docs.podman.io/en/latest/markdown/podman-system-serv...

[xylophile]

Docker daemon runs as root, and runs continuously.

If you're running rootless Podman containers then the Podman API is only running with user privileges. And, because Podman uses socket activation, it only runs when something is actively talking to it.

[eriksjolund]

Sometimes it's possible to not use the Podman API at all. Convert the compose file to quadlet files with the command-line tool podlet and start the container with "systemctl --user start myapp.service". Due to the fork/exec architecture of podman, the container can then be started without using the Podman API.

[bonzini]

Yes, either quadlet or handwritten podman CLI in .service files is the way to go. I don't like using generate-systemd because it hides the actual configuration of the container, I see no point in being stateful...

[bonzini]

Yes because the API server is stateless, unlike the docker daemon. If you kill it you can still operate on containers, images, etc. by other means, whereas if you kill the docker daemon the CLI stops working too.