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.
This is sort of "fixed" by using a Quadlet ".kube" but IMO that's a pretty weak solution and removes the "here's your compose file, run it" aspect.
Recently (now that Deb13 is out with Podman 5) I have started transitioning to Podmans Quadlet files which have been quite smooth so far. As you say, its great to run things without all the overhead of kubernetes.
teekert 5 hours ago [-]
"...removes the "here's your compose file, run it"
`podman generate systemd` was created as a bandaid because it was so difficult to manually write systemd units.
Quadlets now make it much easier to create the units by hand, and ‘
`podman generate systemd` is deprecated.
depingus 49 minutes ago [-]
I appreciate the correction. Its been a while since I used podman + systemd. I will definitely be checking out quadlets next time.
klysm 4 hours ago [-]
Echoing the other comment that quadlet is the way to go here
3abiton 3 hours ago [-]
I am curious performance wise about the performance difference between podman and incus. I found incus to be also extremly flexible.
seabrookmx 2 hours ago [-]
They both utilize all the linux c-group magic to containerize. So performance is roughly the same.
Incus is an LXD fork, and focuses on "system" containers. You basically get a full distro, complete with systemd, sshd, etc. etc. so it is easy to replace a VM with one of these.
podman and docker are focused on OCI containers which typically run a single application (think webserver, database, etc).
I actually use them together. My host machine runs both docker and incus. Docker runs my home server utilities (syncthing, vaultwarden, etc) and Incus runs a system container with my development environment in it. I have nested c-groups enabled so that incus container actually runs another copy of docker _within itself_ for all my development needs (redis, postgres, etc).
What's nice about this is that the development environment can easily be backed up, or completely nuked without affecting my host. I use VS Code remote SSH to develop in it.
The host typically uses < 10GB RAM with all this stuff running.. about half what it did when I was using KVM instead of Incus.
esseph 2 hours ago [-]
These seem like two very different stacks designed to solve quite different problems (incus v podman)
iTokio 5 hours ago [-]
Isn’t that limited to a single node?
How would you configure a cluster? I’m trying to explore lightweight alternatives to kubernetes, such as docker swarm, but I think that the options are limited if you must support clusters with equivalent of pods and services at least.
mands 1 hours ago [-]
I've found you can get pretty far with a couple of fixed nodes and scaling vertically before bringing in k8s these days.
Right now I'm running,
- podman, with quadlet to orchestrate both single containers and `pods` using their k8s-compatible yaml definition
- systemd for other services - you can control and harden services via systemd pretty well (see https://news.ycombinator.com/item?id=44937550 from the other day). I prefer using systemd directly for Java services over containers, seems to work better imo
- Fedora CoreOS as an immutable base OS with regular automatic updates
All seems to be working really well.
jabl 3 hours ago [-]
> Isn’t that limited to a single node?
Yes. Though unless you have a very dynamic environment maybe statically assigning containers to hosts isn't an insurmountable burden?
MrDrMcCoy 1 hours ago [-]
HashiCorp Nomad is probably the only real alternative. It's what in using, and I like it better than the overcomplexity of k8s.
sc68cal 3 hours ago [-]
> How would you configure a cluster?
So, unless you have a service that requires a fixed number of running instances that is not the same count as the number of servers, I would argue that maybe you don't need Kubernetes.
For example, I built up a Django web application and a set of Celery workers, and just have the same pod running on 8 servers, and I just use an Ansible playbook that creates the podman pod and runs the containers in the pod.
gf000 5 hours ago [-]
In the off chance your search didn't expand to k3s, I can semi-recommend it.
My setup is a bit clunky (having a Hetzner cloud instance as controller and a local server as a node throught Tailscale), from which I get an occasional strange error that k3s pods fail to resolve another pod's domain without me having to re-create the DNS resolver system pod, and that I so far failed at getting Velero backups to work with k3s's local storage providers, but otherwise it is pretty decent.
iTokio 4 hours ago [-]
K3s is light in terms of resources, but heavy in operational complexity, I’m not looking for a smaller version of kubernetes but for a simple way to run container backed services when you’re not google but a small company, something that has few moving parts but is very reliable and low maintenance.
esseph 2 hours ago [-]
I've been back and forth on this for a long time, but I've just decided at this point that I either settle for podman or docker on a single host, or go to Talos / k3s / k8s. There's a lot of tools there, a lot of inertia, and eventually it's likely that I will need to solve the problems that k8s does.
YMMV
zelphirkalt 4 hours ago [-]
I once tried Nomad for a very brief moment. Not sure if it fits your bill.
0x457 45 minutes ago [-]
Nomad is weird. Its OSS version is like a very limited trial of paid version. At least last time I tried it. To a point that it was more productive for me to install k3s instead.
heavensteeth 3 hours ago [-]
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.
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 1 hours ago [-]
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 36 minutes ago [-]
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.
papercrane 30 minutes ago [-]
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.
sureglymop 1 hours ago [-]
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!
prmoustache 56 minutes ago [-]
> once all of these bugs are ironed out
You just mention they have.
lukaslalinsky 4 hours ago [-]
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.
smjburton 4 hours ago [-]
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.
mstade 6 hours ago [-]
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.
orbstack is just a vm provider for docker on mac, colima offers the same features without a ui and is a great open replacement but as neither supports podman both are not really relevant to the podman discussion.
epistasis 3 hours ago [-]
The UI of OrbStack is probably one the biggest features, so a replacement without the UI doesn't make a ton of sense for most people that like OrbStack.
nicce 4 hours ago [-]
> orbstack is just a vm provider for docker on mac
”just” is a big statement here. Performance between colima and OrbStack are from different planets.
Apple just released their own runtime so that is also worth inspecting.
jFriedensreich 3 hours ago [-]
can you back that claim up? i see a huge difference between orbstack and docker desktop but colima and orbstack use afaik the same technology and the performance was near identical in my tests. (Though you need to change the colima settings to vz and virtiofs)
nicce 32 minutes ago [-]
> (Though you need to change the colima settings to vz and virtiofs)
I think I have just used the defaults. The difference was huge in regular use. E.g. simple test to upgrade OS packages and time that.
digikata 49 minutes ago [-]
On Linux I'm using colima with docker compose and buildx and it seems to work ok for my limited cases.
On Mac it works ok to, but there are networking cases that Colima on mac doesn't handle - so orbstack for there
gz09 4 hours ago [-]
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...
rsyring 2 hours ago [-]
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.
zoobab 3 hours ago [-]
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 encountered this exact issue (no buildkit with Podman) months ago. I gave up and used Docker desktop, but I'm glad you didn't. Well done!
cyprien_g 6 hours ago [-]
I have never used Podman, but I hear about it very often. I currently use Colima (https://github.com/abiosoft/colima) and I'm very satisfied with it.
I 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.
cmiles74 6 hours ago [-]
I use Podman, I wanted a Docker-like experience on MacOS or Windows. I use it to provide services during development (PostgreSQL, etc.) and working on image builds. It works pretty well. :-)
rockyj 6 hours ago [-]
Colima is related but separate, Colima runs a Linux VM seamlessly in MacOS so you can interact with Docker as if it was running on your host OS. Podman will also need a VM (coz there is no native Docker on MacOS).
dizhn 6 hours ago [-]
That sounded like podman needs docker. It's more of a mostly compatible separate product that does not need a daemon to run. Both probably lack things like cgroups (a Linux kernel really) etc on macos.
privatelypublic 6 hours ago [-]
Podman Desktop uses a VM on windows too.(WSL2)
haolez 6 hours ago [-]
But Docker can run rootless these days, right? Can anyone chime in with how well does this work?
pxc 6 hours ago [-]
Actually setting up rootless Docker is pretty manual and kludgy. With Podman, rootless is pretty much effortless.
leemelone 45 minutes ago [-]
podman pissed me off when I tried it in it's early days. Is it better?
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.
Last I tried using the .kube files I ran into issues with specifying container networks (https://github.com/containers/podman/issues/12965).
This is sort of "fixed" by using a Quadlet ".kube" but IMO that's a pretty weak solution and removes the "here's your compose file, run it" aspect.
Recently (now that Deb13 is out with Podman 5) I have started transitioning to Podmans Quadlet files which have been quite smooth so far. As you say, its great to run things without all the overhead of kubernetes.
Claude recently hallucinated this for me:
For a brief moment in time I was happy but then:Can you really use "ComposeService" in the systemd unit file? I can't find any reference to it
You're absolutely right to question that - I made an error. There is no ComposeService directive in systemd or Quadlet.
It would be a nice best of both worlds...
Just FYI, `podman generate systemd --files --name mypod` will create all the systemd service files for you.
https://docs.podman.io/en/latest/markdown/podman-generate-sy...
Quadlets now make it much easier to create the units by hand, and ‘ `podman generate systemd` is deprecated.
Incus is an LXD fork, and focuses on "system" containers. You basically get a full distro, complete with systemd, sshd, etc. etc. so it is easy to replace a VM with one of these.
podman and docker are focused on OCI containers which typically run a single application (think webserver, database, etc).
I actually use them together. My host machine runs both docker and incus. Docker runs my home server utilities (syncthing, vaultwarden, etc) and Incus runs a system container with my development environment in it. I have nested c-groups enabled so that incus container actually runs another copy of docker _within itself_ for all my development needs (redis, postgres, etc).
What's nice about this is that the development environment can easily be backed up, or completely nuked without affecting my host. I use VS Code remote SSH to develop in it.
The host typically uses < 10GB RAM with all this stuff running.. about half what it did when I was using KVM instead of Incus.
How would you configure a cluster? I’m trying to explore lightweight alternatives to kubernetes, such as docker swarm, but I think that the options are limited if you must support clusters with equivalent of pods and services at least.
Right now I'm running,
- podman, with quadlet to orchestrate both single containers and `pods` using their k8s-compatible yaml definition
- systemd for other services - you can control and harden services via systemd pretty well (see https://news.ycombinator.com/item?id=44937550 from the other day). I prefer using systemd directly for Java services over containers, seems to work better imo
- Pyinfra (https://pyinfra.com/) to manage and provision the VMs and services
- Fedora CoreOS as an immutable base OS with regular automatic updates
All seems to be working really well.
Yes. Though unless you have a very dynamic environment maybe statically assigning containers to hosts isn't an insurmountable burden?
So, unless you have a service that requires a fixed number of running instances that is not the same count as the number of servers, I would argue that maybe you don't need Kubernetes.
For example, I built up a Django web application and a set of Celery workers, and just have the same pod running on 8 servers, and I just use an Ansible playbook that creates the podman pod and runs the containers in the pod.
My setup is a bit clunky (having a Hetzner cloud instance as controller and a local server as a node throught Tailscale), from which I get an occasional strange error that k3s pods fail to resolve another pod's domain without me having to re-create the DNS resolver system pod, and that I so far failed at getting Velero backups to work with k3s's local storage providers, but otherwise it is pretty decent.
YMMV
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
I recommend starting with .container files instead of .kube, unless you're already familiar with kubernetes.
Not sure I'm sold.
> 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.
You just mention they 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.
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.
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/
”just” is a big statement here. Performance between colima and OrbStack are from different planets.
Apple just released their own runtime so that is also worth inspecting.
I think I have just used the defaults. The difference was huge in regular use. E.g. simple test to upgrade OS packages and time that.
On Mac it works ok to, but there are networking cases that Colima on mac doesn't handle - so orbstack for there
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...
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.
https://docs.docker.com/build/building/export/
Does Podman supports the same feature?
I 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.