We moved from docker to podman about 15 months ago, and I'm never going back. I (personally) love the quadlet (read: systemd) integration, that makes it so much easier to monitor a set of running services, be they regular systemd services or containers. Running rootless is as straightforward as it gets and on top of it, podman is blazingly fast. I, personally, don't miss docker compose all that much, but I understand if the lack of docker compose is a showstopper for others. I've never tried podman's compose plugin.

I switched from a giant docker compose file to podman quadlets on my homelab. IIRC it look me a little while to translate the first couple of services because there wasn't (at the time, at least) as much documentation/examples of quadlets as compose files, but after that it was a piece of cake. I highly recommend them.

The only issue I have is validation, there isn't a convenient built-in command to validate quadlet files and systemd doesn't warn you if any fail to generate. You either have to do a --dry-run first (and probably alias the full command to something reasonable) or check the journal for errors.

Swapped a few years back (pre 5.0), haven't looked back. For compose files I'd look into using quadlets.

For quick conversions you can use compose files directly with podman-compose or docker compose pointed at the podman socket[0].

There's also podlet[1] which converts compose files into native quadlets. It does a pretty good job of taking care of everything for you and for a lot of simple to medium complexity compose files it will Just Work. There's talk of making it into a library of some kind so other tools can transparently convert compose files to quadlets so hopefully we'll see more stuff like it.

Otherwise, writing your own Quadlet files isn't too hard if you're at all familiar with systemd unit files. Most `docker run` or `podman run` arguments have direct quadlet conversions so once you get used to the INI format versus yaml it's pretty easy to see a compose file and churn out the equivalent quadlet(s).

[0] https://www.redhat.com/en/blog/podman-docker-compose

[1] https://github.com/containers/podlet

I switched everything over to rootless podman a year or two back. Some containers ended up with permissions issues when trying to read their old data - caused by being run with a different UID. This was really the only problem I ran into, but I would have had the same issue switching from rootful docker to rootless docker.

Absolutely zero regrets, would never go back.

I have switched on production and QA servers. I used AI tools to help with the migration. Easy peasy. On the desktop, I am still using docker. Old habits die hard. Eventually I plan to switch on the desktop as well.

I've been coding solutions against each. I'm currently having issues extracting progress from the current Podman on my TUI build pane, but now switching versions to see if it addresses it and continue working the issue.

I have zero issues with it doing the builds I need. Works same same as Docker from what I can tell.

I took Docker completely off my Macbook which has a tiny drive in it. Hardly ever use it, except for testing. Podman is super lightweight and using a project I'm developing, launches containers with dev agents in it, just the same as Windows running Docker.

podman-compose has gotten much better. I used it for a work project a few months ago, and it ran fine. That said, I know there are some random little things podman-compose doesn't support, so be careful.

What I'm experimenting with right now is defining stuff with a Kubernetes yaml, which podman also supports: https://docs.podman.io/en/latest/markdown/podman-kube.1.html.

It's slightly more verbose than docker-compose, but podman supports it natively and you can actually wrap your app containers into a single "pod" for easier management.

I set up my stuff as all Podman when I moved from a VPS to my home server and it's been pretty simple. I didn't use any of the compose functionality because I have a single DBMS of each type and just have multiple DBs on them etc. and I use podman through the systemd quadlet system. Honestly, it's been pretty flawless.

I moved in 2021.

Others have pointed out that you can use podman-compose or docker-compose pointed at podman. I did something different: I switched to using systemd to manage all my containers. It was worthwhile as I can just use my usual systemctl and journalctl utilities for both containerized and non-containerized services rather than having to remember two sets of commands.

I only experienced one minor issue with pasta (used by podman) with networking, but by then I had fully committed to podman so I did not even try to see whether I would have had this same issue if I were using docker.

Would be great to know if I can uninstall docker on Mac and just install https://github.com/containers/podman/releases and be good to go with my docker compose files ?!

I have the feeling the docker company is communicating a lot with Apple because virtualisation got better and better over the years. I wonder if podman would be a speed downgrade here?

I switched a few years back and use Quadlets instead of compose now. Converting compose files to Quadlets is pretty mechanical once you get the hang of it.

Highly recommend Podman overall; there are some quirky edge cases, but for the most part it’s a smooth replacement for Docker.

If you don’t want to give up compose entirely, podman-compose exists. I just prefer Quadlets so I haven’t used it much myself.

The biggest differences for me were related to non trivial network setups. Is just that you find docs and how tos for docker, but less so for podman.

Other than that, I haven't found anything that makes me consider using docker again.

For me, I'm as grateful for Podman as I am for git.

Podman has been mature and sane. In cases where $someone's container depends on su privs, I blame the $someone, not Podman.

In our shop, I wasn't one of those who knew Docker in and out, got just enough into it I could containerise applications we needed to have containerised, which was of a modest scope -- no crazy networking setup that required bleeding edge or anything like that. Anyway, after only a few months into Docker, organisation announced migration to Podman across the board. Initial impressions were soured by, ironically, poor out-of-the-box installation experience _on Red Hat Enterprise Linux_ (which we run everywhere where Linux is used) -- getting `podman` to do much of anything useful in the "rootless" mode matched the typical anecdotal evidence requiring a bunch of incancations you may or may not understand fully, as RHEL itself wasn't ready for the package, apparently. That was in 2024 though, and it rapidly got better after that. These days I have all but forgotten we used to use `docker` but use `podman` instead, but then again I have had to learn plenty enough about at least the latter -- enough I am able to navigate problems better than earlier (what with UID/GID mapping, for example -- which too had to be done manually occasionally when we first transitioned).

There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).

We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)

Good for the most part, I appreciate them being pretty much a drop in replacement (mostly so tools that reference docker can just work usually).

Regardless it works enough for me to run local Kubernetes and Tilt

Yes. 99% of things just worked, zero modifications.

The few cases where something was not directly translatable was <10 minutes with a coding agent to make some minor config changes, and then it just worked.

Yeah pretty much no big issues in moving over. Even ctop works for which I really wish there was a replacement since it's not updated anymore.

Not a power user but compatibility has been excellent.

You don't have to fully switch. I use podman in socket mode with the docker cli as a frontend.

Switching quickly turns into "Here is a list of 10 easy steps..."

For anyone with a working homelab there is no reason to switch

If you're worried about security, both need extra work

I mean I should probably also say it’s good enough that Bazzite ships with it enabled (not something I’d have expected)

What I have observed through my limited experience, primarily testing docker-based development env setups in podman, is that it's usually not a straight swap.

I switched from Docker to rootless Podman for our build server. Completely positive experience so far. Our builds went _down_ from 1 minute to 2 seconds.

I'm also using podman-compose that is small and delightful (I had to fix a few bugs there). It's just one Python file that you can copy.

Sic an AI cli on a copy of it. They take care of that stuff pretty easily.