Quadlet is one of the best things to have come out of Podman and I highly recommend anyone curious about Podman or switch to container-based workloads to check them out. Being able to slot containers in and treat them like essentially any other system service feels great, plus I don't have to learn some extra orchestration layer to get them to work together or depend on non-container resources. I can just write the same systemd units I'm already writing. The auto-updating and service restart/notify on failure/etc is just icing on the cake. I've seen the equivalent Docker versions before and they're awful; giant messy run commands to try to work around the Docker daemon and half the time you end up with phantom services and containers anyway. Quadlet's end up being much cleaner; plus it means your whole setup (besides volume contents) exists with your other systemd units (/etc/systemd/, .config/systemd, /usr/local/lib/systemd, etc) so it's easy for backups.

The only downside is they're not really an answer to docker-compose on the local development side and the podman team doesn't seem super interested in tackling that segment. User containers are nice for long running local test infra (i.e. a background database) but are too clunky for a normal compile-> docker compose up -> test -> docker compose down loop. The best answer is either .kube Quadlets (kubernetes plays) or using docker compose [0] against the podman socket.

Either way, I've enjoyed using quadlets enough that I've spent the last few months writing a gitops tool for managing them in my spare time. They just feel like the right way of managing containerized servers.

[0] NOT podman-compose, which the article points out as being not very good and under-developed. Podman implements most of the compose spec so you can use docker compose for most situations. I suspect many people who tried Podman when RH first started pushing it ran into Podman 3 being kinda of bleh and podman-compose being awful and bounced off it.