[heavensteeth]

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.

[1]: https://github.com/containers/podman-compose/pull/1283

[2]: https://github.com/containers/podman-compose/issues/127

[bogwog]

Podman compose is an attempt to court Docker users by porting over a bad idea. Instead of that, learn how to create "quadlets" and you'll never want to touch docker again. See: https://www.redhat.com/en/blog/quadlet-podman

I recommend starting with .container files instead of .kube, unless you're already familiar with kubernetes.

[c-hendricks]

So for my set of DVR services, quadlets would have me replace a single compose.yml with 6 .container files, and manually create the network, and have to stop and start all of the services individually.

Not sure I'm sold.

[bogwog]

Not sure what your compose file looks like, but my container files are tiny, flat, and trivial to maintain.

> manually create the network

There's no way for me to know what your requirements are, but often times if you just need your containers to talk to each other, all you need is an empty file with a unique name. So `touch MyDVRNetwork.network` to create it, and add `Network=MyDVRNetwork` to your containerfiles.

> and have to stop and start all of the services individually.

Nope, container files are essentially already systemd service files. If you add them to the correct folder and set up the dependencies, systemd will automatically start them in the correct order at boot time, restart them if they fail, etc. That's the best part of quadlet IMO. Literally set it and forget it, and the process works the same for rootless containers (you just need to add them to your user folder instead of the system-wide folder)

It gets even more awesome when you combine them with something like Fedora CoreOS and Butane. With a few small text files, you can declaratively generate an OS image with all of your desired services ready to go. It is pure bliss.

[smarx007]

How would I share Quadlet files for my repo? Today I have a docker-compose.yml in my repo, the instructions to try it out are usually `docker compose up --build -d`.

I read about the recently released CLI support for quadlets [0] and the ability to install Quadlets from a URL but still cannot wrap my head around it (as in, no matter how I look at it, Quadlets seem to require non-trivially higher knowledge to use and more steps/files).

If we need a concrete example to discuss: https://github.com/oslc-op/refimpl/blob/main/src/docker-comp...

[0]: https://blog.podman.io/2025/08/level-up-your-container-game-...

[bogwog]

Quadlet is only for managing containers. If you need to build images too, you need to use the "buildah" CLI tool. If you know what a systemd service file is, a quadlet is essentially just that. It's a service file that automatically handles the annoying details of creating a systemd service to start/stop your container properly.

But Quadlet needs a container image before it can create a container. The example compose file you linked includes steps for building Dockerfiles. Quadlet doesn't do that. Instead, you'll need to do it as a separate step using buildah (https://www.redhat.com/en/topics/containers/what-is-buildah)

Compose does a lot of stuff, so migrating away from it isn't always easy. In this case, you'd probably need to bring in a build system like Make or some custom scripts to build all the container images you need. Once you rebuild an image, you can restart your quadlet-managed containers with `systemctl restart my-container` and they'll automatically use the new image.

I don't do much web development these days, so I'm definitely not an authority on container-based development workflows. Maybe there are better tools out there, or maybe compose is still the best tool for that job. But quadlets are definitely the better choice when it comes to deploying/orchestrating your containers without getting into a full blown kubernetes setup.

[GCUMstlyHarmls]

Quadlet supports ".build" and ".image" files, and ".container"s can have an auto-update policy (supported by manually invoking `podman auto-update` or the daily timer.)

[c-hendricks]

It sounds interesting, but with some caveats / things that require other tooling, maybe migrating all my services from compose to quadlets would end up a fairly lateral move.

[papercrane]

Quadlets also support a .kube file. I have a similar use case where I have 6 containers I want to all run on the same network. So have a k8s YAML file that has a pod with the containers, their configuration and path mapping and then a have a `service.kube` file with a '[Kube]' section and a 'Yaml=/path/to/config.yaml' directive. That creates a single service to stop/start with systemd and has all the containers running on the same network in a single pod.

[johnny22]

Can you use those quadlets inside a development project? I use docker-compose (with podman) just so i can work on a project that is completely self-contained. No copying files to ~/.config/systemd just run docker-compose to start and stop.

Can i do that with quadlets?

[bogwog]

I'm not the best person to ask about this as I don't do much web dev these days, and my experience with podman is mostly limited to deploying existing software. If compose works for that use case, then you should probably stick with it. For actually deploying it somewhere though, you should be using quadlets instead (or kubernetes I guess)

> No copying files to ~/.config/systemd just run docker-compose to start and stop.

Naively, I'd say to create symlinks instead of copying, and run `systemctl daemon-reload`/`systemctl restart ...`. Although there are probably more streamlined web development options out there.

Maybe look into Podman Pods. They're probably closer to what you're looking for, but idk what kind of dev tools exist out there for it. Maybe a few custom shell scripts to run the pod management commands is all you really need?

[johnny22]

> Naively, I'd say to create symlinks instead of copying,

I did mean symlinks too. The rest of my system shouldn't have to know or care about my project at all.

I just wanna be able to systemctl --user start ./my-service.service or something to that effect.

[all2]

> I just wanna be able to systemctl --user start ./my-service.service or something to that effect.

Can you not? I know that systemctl has a userspace dot folder for user's services.

[0] `~/.config/systemd/user/`

[bogwog]

The quadlet user folder is typically at `~/.config/containers/systemd`. So if you put your .container files in there, you can start them with `systemctl start --user MyContainer`

https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

[jabl]

What I've done is use the "podman kube play" similar to docker-compose when developing ("podman kube play file.yaml", "podman kube play --down file.yaml", "podman kube play --replace file.yaml", etc.) with the "file.yaml" in my working directory. Then when I'm satisfied and want to deploy to production I write a quadlet snippet referencing the kube file and put them under /etc.

[cyberax]

Can I use quadlets on my macOS laptop? Or in WSL2?

[kevinrineer]

I was able to follow Dan Walsh's example [0].

I tried with Ubuntu just know and there's a 404 for buildah to install via apt at this exact moment. Here's my working Fedora WSL2 (which I prefer and use daily).

  $ cat /etc/os-release
  NAME="Fedora Linux"
  VERSION="42 (WSL)"
  RELEASE_TYPE=stable
  ID=fedora
  VERSION_ID=42
  VERSION_CODENAME=""
  PLATFORM_ID="platform:f42"
  PRETTY_NAME="Fedora Linux 42 (WSL)"
  ...
  VARIANT="WSL"
  VARIANT_ID=wsl

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

[sureglymop]

I use rootless podman in socket mode but use the docker CLI (just the CLI, no daemon or service or messing with iptables) as the frontend. Can recommend!

[bityard]

What does the docker CLI give you that the podman CLI doesn't? (Surely you aren't suggesting that `docker compose` works with a podman rootless daemon?)

[figmert]

It certainly does!

For what it's worth, podman has also a thin wrapper around docker compose (podman compose) which can also automatically select `podman-compose`.

Note:

- `podman-compose` is an early attempt at remaking `docker-compose` but for Podman.

- Later Podman wrote a Docker compatible socket instead, which can work with most docker clis that accept a `DOCKER_HOST` argument, including `docker` and `docker-compose` (both v1 and v2)

- `podman compose` is a thin wrapper that automatically selects `docker-compose` or `podman-compose` depending on which is installed.

[sureglymop]

It works perfectly well. Try it out :)

[bityard]

Well that's pretty interesting, then. And it handles named volumes and isolated networks between containers?

[sureglymop]

Yes. All of that works in my experience. It's a drop in replacement. You set it up once in the docker CLI with `docker context ` or just symlink it to the right location. Then you can forget about it basically.

I use this on my server with compose together with traefik which listens on 127.0.0.1:{8000,4433}. Then I have a small nftables config that does the port forwarding to 80/443.

[ownagefool]

it does work, yes

[prmoustache]

> once all of these bugs are ironed out

You just mentioned they are.