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.
Docker has one of the most severe cases of not-invented-here. All solutions require a combination of a new DSL, a new protocol, a new encryption scheme, a new daemon, or any combination there-of. People are sleeping on using buildah directly; which OP alluded to with Bakah (but fell short of just using it directly).
Ever wish you could run multiple commands in a single layer? Buildah lets you do that. Ever wish you could loop or some other branching in a dockerfile? Buildah lets you do that. Why? Because they didn't invent something new, and so the equivalent of a dockerfile in buildah is just a script in whatever scripting language you want (probably sh, though).
I came across this when struggling and repeatedly failing to get multi-arch containers built in Circle CI a few gears ago. You don't have access to an arm64 docker context on their x86 machines, so you are forced to orchestrate that manually (unless your arm64 build is fast enough under qemu). Things begin to rapidly fall apart once you are off of the blessed Docker happy path because of their NIH obsession. That's when I discovered buildah and it made the whole thing a cinch.
Buildah is elite tooling. Enables you to build with devices and caps and kernel modules. Buildx acts like you should sign a waiver and really weak documentation if at all for what you are trying to do
multiple commands in a layer is possible in a dockerfile for a long time, since format 1.4(?) using heredoc, which is just a script netting you loop and branches etc.
on the QEMU thing... the only time I tried to cross-build arm containers from an x86 server was using whatever servers Github Actions supports... the x86_64 build was pretty normal for the project, but the qemu/buildx/arm64 build was about the same speed as an 8mb Raspberry Pi 4 to build the same project... pretty disappointing.
I do a combi, sometimes even asking the LLM and starting a ddg search in parallel. It speeds me up. Sometimes the LLM is right, sometimes it's not. NP, I'll get it to work. One should never do anything that one does not understand, but I get to the understand faster as I can also ask more in depth follow up questions to the LLM.
It is very stupid and is usually wrong in some meaningful way, but it can help break logjams in my thinking. Giving me clues that might be missing. Sort of like how writing gibberish is sometimes effective for writers to break writer's block.
It is also nice for generating boiler plate code for languages that I am not super familiar with.
The biggest problems I have with current state of the art LLMs is that errors compound. Meaning that I only really get somewhat useful answers when starting out with the first few questions or the first couple times I ask it to review some code. The longer the session lasts the more la-la land answers I get.
It is a game of odds. I expect that with systemd and quadlets it is going to particularly useless because there just isn't that many examples out there. It can only regurgitate what it is trained with so if something isn't widely used and checked into code bases it is trained on then it can't really do anything with it.
Which is why it is nice for a lot of common coding tasks, because a lot of code is just same thing tens of thousands people did before for only slightly different contexts and is mostly boilerplate.
yeah Quadlets are a pretty reasonable improvement.
It was introduced in Podman 4.4 which is circa 2023.
And it takes a while for podman to get up to date in non-Redhat related distributions. Like Debian Stable was stuck on 4.3 until Trixie release this month.
So unless you are using Fedora and friends or something like Arch it is kinda hard time going for podman users. Which is unfortunate.
Docker has a bit of a advantage here because they encourage you to use their packages, not the distribution's.
Here is a example Quadlet configuration i use for syncthing that I run out of my home:
This then gets dropped into ~/.config/containers/systemd/syncthing.container
And it is handled automatically.
This configures the syncthing container to always get updated on each startup, bypasses the "rootless" networking by using host networking (rootless networking is limited and slow), and the default Sync dir ends up in ~/.syncthing where as I can add more sync'd directories to my real home directory by directing it to /var/home/ in the syncthing web ui.
As you can see the arguments under "container" is just really capitalized versions of docker/podman arguments.
Also if you like GUIs the podman desktop has support for helping to generating quadlets. Although I haven't tried it out yet.
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.
That feature might be able to replace my docker usage on the host, so I don't need it and incus side by side. Which would be pretty neat.
Within the incus dev environment container though I'm pretty sure I want to keep docker, as I have a lot of tooling that expects it for better or worse (docker compose especially). It also doesn't appear incus integrates buildkit etc. so even if I used it here, I'd still need something else to _build_ OCI images.
If you are using podman "rootless" mode prior to 5.3 then typically you are going to be using the rootless networking, which is based around slirp4netns.
That is going to be slower and limited compared to rootful solutions like incus. The easy work around is to use 'host' networking.
If you are using rootful podman then normal Linux network stack gets used.
Otherwise they are all going to execute at native speed since they all use the same Linux facilities for creating containers.
Note that from Podman 5.3 (Nov 24) and newer they switched to "pasta" networking for rootless containers. Which is a lot better, performance wise.
edit:
There are various other tricks you can use for improving podman "rootless" networking, like using systemd socket activation. This way if you want to host services this way you can setup a reverse proxy and such things that runs at native speeds.
That is what I do as well. I'd rather not have to remember more than one way of doing things so 'podman play kube' allows me to use Kubernetes knowledge for local / smaller scale things as well.
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.
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
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.
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.
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.
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.
I recall seeing a couple of blog posts lately about docker swarm and how its better now. I can see a few references to it in the latest release notes so I guess it's still getting some love.
I've been reading and watching videos about how you can use Ansible with Podman as a simpler alternative to Kubernetes. Basically Ansible just SSHs into each server and uses podman to start up the various pods / containers etc. that you specify. I have not tried this yet though so take this idea with a grain of salt.
ansible -i server1,server2,server3 deploy_fake_pods.yaml
ssh server1 sudo shutdown -h now
# aww, too bad, now your pods on server1 are no longer
With
kubectl apply -f deployment.yaml
for i in $(kubectl get nodes -o jsonpath='{.status.hostIP}'); do
ssh $i sudo shutdown -h now
sleep 120
done
# nothing has changed except you have fresh Nodes
If you don't happen to have a cluster autoscaler available, feel free to replace the for loop with |head -1 or a break, but I mean to point out that the overall health and availability of the system is managed by kubernetes, but ansible is not that
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.
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.
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 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.
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).
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.
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.)
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.
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.
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.
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?
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`
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.
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).
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!
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?)
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.
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.
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...
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 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.
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.
You know someone has NOT used OrbStack when they just think all they have to offer is the UI. In fact, I barely use the UI, I just see the icon in the Menu Bar, from then on I just love the performance, feels almost like being back on Linux.
I haven't used OrbStack in a while but would you say Colima or OrbStack is faster? At least on Intel Mac Colima is for me way better than Docker. Also better than Podman in terms of compatibility, although I had to switch back to Docker Desktop since I need full compat.
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)
I can't think of any stellar reason why colima couldn't also support it, since they even go out of their way to support Incus as a runtime, but I don't currently have the emotional energy to prosecute such a PR
It's more general than that, closer to WSL. I usually use Podman Desktop for container stuff, but I like OrbStack for managing Linux VMs. It has some really slick integrations and it performs very, very well.
I've replaced my OrbStack usage entirely with Podman Desktop and have zero issues with it, unlike with OrbStack.
In particular the 1TB VM disk image OrbStack uses wreaks havok with deduplicating backups. Their disk cache also caused me hours of debugging why my assets weren't up-to-date.
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.
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.
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.
Podman doesn't produce their own binary distributions for ANY Linux distro. The only binary packages they provide are for Mac and Windows because those don't have a native package repository.
Even if they did release their own Linux packages, bear in mind that Podman development is driven by and sponsored almost entirely by Red Hat. It's not really in their interest to pay their developers to maintain packages for Ubuntu, a direct competitor in the enterprise Linux space.
Also yes, podman v4 on bookwarm was famously useless in many cases and because of either libc or kernel (iirc) you could not even install v5 effortlessly.
I like Debian and I like podman but putting this as a usefule nice experience (up until trixie released) is just weird framing.
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 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. :-)
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).
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.
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'm a big podman stan)
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.
(I'm a bigger podman stan)
I agree about quadlets, amazing.
Docker has one of the most severe cases of not-invented-here. All solutions require a combination of a new DSL, a new protocol, a new encryption scheme, a new daemon, or any combination there-of. People are sleeping on using buildah directly; which OP alluded to with Bakah (but fell short of just using it directly).
Ever wish you could run multiple commands in a single layer? Buildah lets you do that. Ever wish you could loop or some other branching in a dockerfile? Buildah lets you do that. Why? Because they didn't invent something new, and so the equivalent of a dockerfile in buildah is just a script in whatever scripting language you want (probably sh, though).
This will probably give you the general idea: https://www.mankier.com/1/buildah-from
I came across this when struggling and repeatedly failing to get multi-arch containers built in Circle CI a few gears ago. You don't have access to an arm64 docker context on their x86 machines, so you are forced to orchestrate that manually (unless your arm64 build is fast enough under qemu). Things begin to rapidly fall apart once you are off of the blessed Docker happy path because of their NIH obsession. That's when I discovered buildah and it made the whole thing a cinch.
Buildah is elite tooling. Enables you to build with devices and caps and kernel modules. Buildx acts like you should sign a waiver and really weak documentation if at all for what you are trying to do
multiple commands in a layer is possible in a dockerfile for a long time, since format 1.4(?) using heredoc, which is just a script netting you loop and branches etc.
Isn't buildah and podman themselves a case of NIH too? ;) I mean, they work fine but I don't think that's an issue with docker either.
How so? What could they have reused instead of inventing?
on the QEMU thing... the only time I tried to cross-build arm containers from an x86 server was using whatever servers Github Actions supports... the x86_64 build was pretty normal for the project, but the qemu/buildx/arm64 build was about the same speed as an 8mb Raspberry Pi 4 to build the same project... pretty disappointing.
"...removes the "here's your compose file, run it"
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...
Many moons ago, the concept of chaos monkey [1] was concieved.
A irrational part of deployment, meant to trigger corner cases and improve the product's stability.
Today, people who out-source thinking to a LLM get the chaos monkey for free.
The only problem seems to be that the LLM proponents are ahistoricists.
1: https://en.wikipedia.org/wiki/Chaos_engineering#Chaos_Monkey
It’s exhausting. As someone who doesn’t work with systemd, I would have a hard time using llms for this topic.
I do a combi, sometimes even asking the LLM and starting a ddg search in parallel. It speeds me up. Sometimes the LLM is right, sometimes it's not. NP, I'll get it to work. One should never do anything that one does not understand, but I get to the understand faster as I can also ask more in depth follow up questions to the LLM.
For me LLM is just a rubber duck that talks back.
It is very stupid and is usually wrong in some meaningful way, but it can help break logjams in my thinking. Giving me clues that might be missing. Sort of like how writing gibberish is sometimes effective for writers to break writer's block.
It is also nice for generating boiler plate code for languages that I am not super familiar with.
The biggest problems I have with current state of the art LLMs is that errors compound. Meaning that I only really get somewhat useful answers when starting out with the first few questions or the first couple times I ask it to review some code. The longer the session lasts the more la-la land answers I get.
It is a game of odds. I expect that with systemd and quadlets it is going to particularly useless because there just isn't that many examples out there. It can only regurgitate what it is trained with so if something isn't widely used and checked into code bases it is trained on then it can't really do anything with it.
Which is why it is nice for a lot of common coding tasks, because a lot of code is just same thing tens of thousands people did before for only slightly different contexts and is mostly boilerplate.
> you just need to write a short systemd config snippet and then you can manage the kube service just like any other systemd service.
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...
`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.
I appreciate the correction. Its been a while since I used podman + systemd. I will definitely be checking out quadlets next time.
yeah Quadlets are a pretty reasonable improvement.
It was introduced in Podman 4.4 which is circa 2023.
And it takes a while for podman to get up to date in non-Redhat related distributions. Like Debian Stable was stuck on 4.3 until Trixie release this month.
So unless you are using Fedora and friends or something like Arch it is kinda hard time going for podman users. Which is unfortunate.
Docker has a bit of a advantage here because they encourage you to use their packages, not the distribution's.
Here is a example Quadlet configuration i use for syncthing that I run out of my home:
This then gets dropped into ~/.config/containers/systemd/syncthing.containerAnd it is handled automatically.
This configures the syncthing container to always get updated on each startup, bypasses the "rootless" networking by using host networking (rootless networking is limited and slow), and the default Sync dir ends up in ~/.syncthing where as I can add more sync'd directories to my real home directory by directing it to /var/home/ in the syncthing web ui.
As you can see the arguments under "container" is just really capitalized versions of docker/podman arguments.
Also if you like GUIs the podman desktop has support for helping to generating quadlets. Although I haven't tried it out yet.
Be sure to podlet for automating the creation of the quadlet config files!
Echoing the other comment that quadlet is the way to go here
I am curious performance wise about the performance difference between podman and incus. I found incus to be also extremly flexible.
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.
If you use the non LTS branch of incus it supports OCI containers. Have you tried that instead of running docker inside of a LXC container?
That feature might be able to replace my docker usage on the host, so I don't need it and incus side by side. Which would be pretty neat.
Within the incus dev environment container though I'm pretty sure I want to keep docker, as I have a lot of tooling that expects it for better or worse (docker compose especially). It also doesn't appear incus integrates buildkit etc. so even if I used it here, I'd still need something else to _build_ OCI images.
If you are using podman "rootless" mode prior to 5.3 then typically you are going to be using the rootless networking, which is based around slirp4netns.
That is going to be slower and limited compared to rootful solutions like incus. The easy work around is to use 'host' networking.
If you are using rootful podman then normal Linux network stack gets used.
Otherwise they are all going to execute at native speed since they all use the same Linux facilities for creating containers.
Note that from Podman 5.3 (Nov 24) and newer they switched to "pasta" networking for rootless containers. Which is a lot better, performance wise.
edit:
There are various other tricks you can use for improving podman "rootless" networking, like using systemd socket activation. This way if you want to host services this way you can setup a reverse proxy and such things that runs at native speeds.
These seem like two very different stacks designed to solve quite different problems (incus v podman)
That is what I do as well. I'd rather not have to remember more than one way of doing things so 'podman play kube' allows me to use Kubernetes knowledge for local / smaller scale things as well.
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.
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
- 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.
> 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?
> 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.
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.
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.
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
It that's what you want to do, just get something running... what's wrong with docker swarm?
I recall seeing a couple of blog posts lately about docker swarm and how its better now. I can see a few references to it in the latest release notes so I guess it's still getting some love.
I've been reading and watching videos about how you can use Ansible with Podman as a simpler alternative to Kubernetes. Basically Ansible just SSHs into each server and uses podman to start up the various pods / containers etc. that you specify. I have not tried this yet though so take this idea with a grain of salt.
whew, "alternative" is doing a lot of work there.
Contrast:
With If you don't happen to have a cluster autoscaler available, feel free to replace the for loop with |head -1 or a break, but I mean to point out that the overall health and availability of the system is managed by kubernetes, but ansible is not thatHashiCorp Nomad is probably the only real alternative. It's what in using, and I like it better than the overcomplexity of k8s.
>> lightweight alternatives to kubernetes
microk8s seems exceedingly simple to setup and use. k3s is easy as well.
I once tried Nomad for a very brief moment. Not sure if it fits your bill.
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.
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
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.
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.
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.
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-...
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.
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.)
Cool, I didn't know that!
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.
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.
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?
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?
> 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.
> 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/`
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...
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.
Can I use quadlets on my macOS laptop? Or in WSL2?
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).
[0] - https://www.redhat.com/en/blog/quadlet-podmanI 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!
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?)
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.
It works perfectly well. Try it out :)
Well that's pretty interesting, then. And it handles named volumes and isolated networks between containers?
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.
it does work, yes
> once all of these bugs are ironed out
You just mentioned they are.
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...
If you use qemu, you don't need a complicated multi-node build system. Obviously performance becomes a factor then.
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 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.
[1]: https://orbstack.dev/
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.
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.
Podman has this built-in, and there is an optional UI called Podman Desktop.
> 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.
You know someone has NOT used OrbStack when they just think all they have to offer is the UI. In fact, I barely use the UI, I just see the icon in the Menu Bar, from then on I just love the performance, feels almost like being back on Linux.
I haven't used OrbStack in a while but would you say Colima or OrbStack is faster? At least on Intel Mac Colima is for me way better than Docker. Also better than Podman in terms of compatibility, although I had to switch back to Docker Desktop since I need full compat.
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)
> (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.
> but as neither supports podman both are not really relevant to the podman discussion
FWIW lima (upon which COlima was built) ships with "boot me up a podman": <https://github.com/lima-vm/lima/blob/v1.2.1/templates/podman...> and <https://github.com/lima-vm/lima/blob/v1.2.1/templates/podman...>
I can't think of any stellar reason why colima couldn't also support it, since they even go out of their way to support Incus as a runtime, but I don't currently have the emotional energy to prosecute such a PR
It's more general than that, closer to WSL. I usually use Podman Desktop for container stuff, but I like OrbStack for managing Linux VMs. It has some really slick integrations and it performs very, very well.
I've replaced my OrbStack usage entirely with Podman Desktop and have zero issues with it, unlike with OrbStack.
In particular the 1TB VM disk image OrbStack uses wreaks havok with deduplicating backups. Their disk cache also caused me hours of debugging why my assets weren't up-to-date.
Admittedly the OrbStack GUI is super snappy tho.
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.
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 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!
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.
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.
Huh? It's right there in the docs: https://podman.io/docs/installation#installing-on-linux
Podman doesn't produce their own binary distributions for ANY Linux distro. The only binary packages they provide are for Mac and Windows because those don't have a native package repository.Even if they did release their own Linux packages, bear in mind that Podman development is driven by and sponsored almost entirely by Red Hat. It's not really in their interest to pay their developers to maintain packages for Ubuntu, a direct competitor in the enterprise Linux space.
As a sibling comment pointed out, the problem with the Ubuntu packages is they are dated. I should have made this clearer in my original comment.
> It's not really in their interest to pay their developers to maintain packages for Ubuntu, a direct competitor in the enterprise Linux space.
Exactly. :)
The problem is podman in the apt repos are very old. Last time I checked, Podman was on v5, where debian was on v2 something.
Must have been ages ago, even stable now has 5.4: https://packages.debian.org/search?searchon=names&suite=all&...
"even stable" - that was released 2w ago.
...
Also yes, podman v4 on bookwarm was famously useless in many cases and because of either libc or kernel (iirc) you could not even install v5 effortlessly.
I like Debian and I like podman but putting this as a usefule nice experience (up until trixie released) is just weird framing.
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:
https://docs.docker.com/build/building/export/
Does Podman supports the same feature?
Yes, since 2021 they also support the same syntax natively: https://github.com/containers/buildah/pull/3133 While also supporting building Dockerfiles with buildah: https://github.com/containers/buildah/blob/main/docs/tutoria...
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.
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. :-)
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).
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.
Podman Desktop uses a VM on windows too.(WSL2)
But Docker can run rootless these days, right? Can anyone chime in with how well does this work?
Actually setting up rootless Docker is pretty manual and kludgy. With Podman, rootless is pretty much effortless.
Wow. It seems really clunky indeed: https://docs.docker.com/engine/security/rootless/
Check your distribution's documentation for the easy way.
Been using it without any issues for years.
Very few distros ship the extras required for it. If yours doesn't, you'll have some extra manual steps to set it up.
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
i am always missing podman(-compose) cp as docker(-compose) cp :( That was so convenient.
podman pissed me off when I tried it in it's early days. Is it better?
clean site