If you're not wedded to docker-compose, with podman you can instead use the podman kube support, which provides roughly docker-compose equivalent features using a subset of the Kubernetes pod deployment syntax.
Additionally, podman has nice systemd integration for such kube services, you just need to write a short systemd config snippet and then you can manage the kube service just like any other systemd service.
Altogether a very nice combination for deploying containerized services if you don't want to go the whole hog to something like Kubernetes.
I replaced my Docker usage entirely with OrbStack[1] a few months ago, and have had zero issues with it so far. Great product that I happily pay a license for.
My usage is fairly basic though and I'm sure mileage varies, but for my basic web dev setup it's been perfect.
Unfortunately, it's quite a big mess (as the article indicates), which leads to a steep learning curve for someone who "just wants to build some images".
And that's just half of it. Want to build an image on two native architectures (ARM64 and AMD64) and then make a multi-arch image out of them. Might blow someones mind on how complicated that is with 2025 docker technologies: https://docs.docker.com/build/ci/github-actions/multi-platfo...
This is an interesting find OP and could help people transition from Docker to Podman (especially if they're used to deploying with Docker-Compose).
I think the better long-term approach though is to use systemd user units for deployment, or the more modern approach of using Podman Quadlets. There's a bit of a learning curve, but these approaches are more native to the Podman platform, and learning how systemd services work is a great skill to have.
I was a huge fan of Podman, but I eventually gave up and use Docker Compose for local development. It's not worth fighting the system.
However, for single server deployments, where I don't need Kubernetes, I now exclusively use Quadlets to run apps and I couldn't be happier. It's a much nicer experience that using typical Docker/Podman setup. It feels integrated into the system.
> I was a huge fan of Podman, but I eventually gave up and use Docker Compose
You can mix them. I was using docker-compose with podman instead of docker before switching to quadlets. I still prefer the experience of compose files, but quadlets do integrate much better into systemd.
I tried Podman on my messing around VPS but quickly reverted to rootless Docker.
The straw that broke the camels back was a bug in `podman compose` that funnily enough was fixed two hours ago[1]; if `service1` has a `depends_on` on `service2`, bringing down `service1` will unconditionally bring down `service2`, even if other services also depend on it. So if two separate services depend on a database, killing one of them will kill the database too.
Another incompatibility with Docker I experienced was raised in 2020 and fixed a few months ago[2]; you couldn't pass URLs to `build:` to automatically pull and build images. The patch for this turned out to be a few lines long.
I'm sure Podman will be great once all of these bugs are ironed out, but for me, it's not quite there yet.
I use a special feature of Docker Buildx with a multistage Dockerfile build, with the SDK in the first part, and an empty container in the second part to copy the build artifact (like firmware.bin), like explained here:
I've wanted to try Podman for a couple years. But I keep bowing out because there are no official Ubuntu builds that I could find. Upstream seems content with that status quo.
That's their prerogative, and I could build it myself, but it makes me concerned they don't really have multi-distro compatibility as a priority, which makes me hesitant to commit time to experimenting with it when Docker considers Ubuntu a first-class citizen.
It's not clear from the article, but is this for local development or production deployments? Because it's worth noting that Swarm solves a lot of the limitations that Compose and Podman have for running containers in a production environment. Swarm runs well on singular vms and people with Docker experience can learn the ropes in a day.
I've mostly just stuck to Docker myself... that said, podman definitely has some curiousity from me, just haven't taken the time to learn.
One enhancement suggestion to TFA, would be to take a hash of the compose file path, then have that as a prefix name in a temp directory for a hash of the compose file itself... if the hash changes, dump the .json and rebuild in the temp path... then do the bakah against that file. This would be an easy enough script to make.
20 comments
[ 2.4 ms ] story [ 50.1 ms ] threadI have tried to find a good comparison between the two, but I find it hard to have a clear opinion on which one is best for me.
Very few distros ship the extras required for it. If yours doesn't, you'll have some extra manual steps to set it up.
Additionally, podman has nice systemd integration for such kube services, you just need to write a short systemd config snippet and then you can manage the kube service just like any other systemd service.
Altogether a very nice combination for deploying containerized services if you don't want to go the whole hog to something like Kubernetes.
My usage is fairly basic though and I'm sure mileage varies, but for my basic web dev setup it's been perfect.
[1]: https://orbstack.dev/
And that's just half of it. Want to build an image on two native architectures (ARM64 and AMD64) and then make a multi-arch image out of them. Might blow someones mind on how complicated that is with 2025 docker technologies: https://docs.docker.com/build/ci/github-actions/multi-platfo...
I think the better long-term approach though is to use systemd user units for deployment, or the more modern approach of using Podman Quadlets. There's a bit of a learning curve, but these approaches are more native to the Podman platform, and learning how systemd services work is a great skill to have.
However, for single server deployments, where I don't need Kubernetes, I now exclusively use Quadlets to run apps and I couldn't be happier. It's a much nicer experience that using typical Docker/Podman setup. It feels integrated into the system.
You can mix them. I was using docker-compose with podman instead of docker before switching to quadlets. I still prefer the experience of compose files, but quadlets do integrate much better into systemd.
The straw that broke the camels back was a bug in `podman compose` that funnily enough was fixed two hours ago[1]; if `service1` has a `depends_on` on `service2`, bringing down `service1` will unconditionally bring down `service2`, even if other services also depend on it. So if two separate services depend on a database, killing one of them will kill the database too.
Another incompatibility with Docker I experienced was raised in 2020 and fixed a few months ago[2]; you couldn't pass URLs to `build:` to automatically pull and build images. The patch for this turned out to be a few lines long.
I'm sure Podman will be great once all of these bugs are ironed out, but for me, it's not quite there yet.
[1]: https://github.com/containers/podman-compose/pull/1283
[2]: https://github.com/containers/podman-compose/issues/127
https://docs.docker.com/build/building/export/
Does Podman supports the same feature?
That's their prerogative, and I could build it myself, but it makes me concerned they don't really have multi-distro compatibility as a priority, which makes me hesitant to commit time to experimenting with it when Docker considers Ubuntu a first-class citizen.
On Mac it works ok to, but there are networking cases that Colima on mac doesn't handle - so orbstack for there
One enhancement suggestion to TFA, would be to take a hash of the compose file path, then have that as a prefix name in a temp directory for a hash of the compose file itself... if the hash changes, dump the .json and rebuild in the temp path... then do the bakah against that file. This would be an easy enough script to make.