After Docker Desktop randomly started consuming insane amounts of memory again we switched to Podman and it was literally as easy as installing it and pointing it at our docker-compose.yml.
Zero changes needed and now I don’t need to keep a daemon running.
It's been a couple months so I forget what problems I ran into, but Docker's AI bullshit pushed me over the edge and I tried switching to Podman. I ran into some compatibility issues. Alas I don't recall the details.
So I tried Rancher Desktop and other than I keep forgetting its name it just worked.
I really love Quadlet. I used to host my rootless containers on Hetzner, Ansible, SystemD and RockyLinux for years without any issues and extracted it to template repo [1].
Why not? On my home server, k3s (single-node master), sitting idle (no workload, no changes), has amassed as much CPU time as a full virtual machine running Home Assistant: 17.75 hours in 106 hours of uptime.
All those abstractions and cluster features do not come for free.
As long as they refuse to support installing on Ubuntu (and other popular distros), without relying on the distro repos which are always out of date, they will continue to lose to Docker.
Any serious project in this space supports as many distros as possible.
It's OSS, so I'm not complaining per se, I have no right to. They owe me nothing.
But this one issue has kept me from seriously considering Podman for years. They don't care about my use case and I therefore don't care to use their project.
When getting the latest version looks like this[1], who is really going to consider this for serious production uses?
Entirely different perspective: If I have to add a separate repo, then this is a red flag.
> Any serious project in this space supports as many distros as possible.
Wrong way around. Any serious product is supported by lots of distros. Distros curate their selection and if nobody bothered packaging your stuff, then your stuff is not good enough.
A slightly different perspective: Podman is made by the distro people (RedHat/Fedora). And they consider it unacceptable to mess with the software distribution channels of a distro. If Debian does not want latest Podman, they are not going to push the latest version to Debian users behind Debian repo's "back". This is a distro-to-distro respect rather than amateur hour.
I do not think this perspective is correct. You are considering official distro repos as a means to control what is allowed to be run on Debian. This is a kind of control commercial platforms often value because they use it to extract rent or to micromanage their experience that they sell to the rubes.
Debian DOES care about about both experience and ethics of what is allowed to be distributed in official repos but it is contrary to the ethos of free software to care what you run on your machine or by extension what others choose to offer. You are intuiting a corporate sort of perspective where neither it nor the raison d'être for it exists.
> You are considering official distro repos as a means to control what is allowed to be run on Debian.
I am rather considering official repos as a means to keeping your Debian system in a "supported" state. Many users, including software developers, want to only install software (or sw versions) that would not put their system in an unsupported configuration.
> Debian DOES care about about both experience and ethics of what is allowed to be distributed in official repos
Podman is widely distributed in official Debian repos, so ethics is not a question in this particular case. We are only talking about Debian repos being conservative with the versions of the software in the repos - not limited to Podman. Debian does not encourage users to install software from 3rd-party repos just to get a newer version of an existing package because the stability of the system (and the ability to do major version upgrades) cannot be guaranteed otherwise.
> As long as they refuse to support installing on Ubuntu (and other popular distros), without relying on the distro repos which are always out of date, they will continue to lose to Docker.
Your needs are incomprehensible to me: that is exactly why I use podman: a predictable version of it is in my distro's repos.
I go to docker.com and how do I even install the thing? What's "docker sandboxes"?
Get the latest version of docker? Why would I want the latest version? I don't want the latest version, I want the same version as my other machines have, so things work everywhere. And I usually don't know what version that is. But I sure do know what Debian version my other machines run!
Again, your needs are utterly incomprehensible to me.
I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one.
Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay.
Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Universe. Everything in this thread makes sense, it's a matter of who wants to pay for it. End users have been asking for this for years.
The engineers don't make the decisions. Canonical doesn't want to pay, Red Hat doesn't want to pay. Users stuck in the middle.
I get podman from brew even on Linux because the idea that vendors fighting over uploading tarballs to a server is stupid. Fuck distros.
I'm confused, the latest LTS version of Ubuntu is 26.04 (released on 2026/04/23) and has Podman v5.7.0 (released on 2025/11/11). [1]
If they're on a 24.04 LTS release is there any reason they would be on a newer version of Podman (without jumping through hoops)? Ubuntu 24.04LTS released on 2024/04/25 and the Debian Import Freeze was on 2024/02/29.
The bleeding edge Podman release at that time was a pre-release v5.0.0-RC3 (2024/02/22) and the latest actual release was v4.9.3 (2024/02/13). That's the version Ubuntu 24.04LTS has. [2][3][4]
So aren't they on the exact version of Podman they're supposed to be on for the operating system version they're running?
Ubuntu loves to mess with upstream by shipping a bunch of vendor patches. It's one of the main reasons I run Fedora, they do this the least in my experience
I don't claim to understand the business or politics between RedHat and Ubuntu.
I do know many projects with way less resources seem to be able to support Ubuntu and other popular distros just fine. Often through PPAs or their own apt repos (like Docker, PostgreSQL, or Incus).
If RedHat doesn't choose to, so be it. But IMO, they can't really compete with Docker when getting a recent release on the most popular distros is such a major cluster F.
If I manage an open source program like this, my job is to write the code and docs, publish it somewhere and maybe make some changes to make it more portable. That's it!
It's the distro's job to package and integrate this software with the rest of the system, to make it easier for their users.
I have 1677 packages installed. I absolutely _do not_ want to go to 1677 places to install or look for the latest version.
24.04 is a stable release. Package updates in stable releases need to follow the Stable Release Update process https://ubuntu.com/project/docs/SRU/stable-release-updates/
In essence someone needs to do contribute time and effort to make it happen. Canonical is free to choose the packages they want to maintain themselves and which ones go to universe and are community maintained. The upstream, if they care enough, can choose to get involved and try to do the updates. The process isn't exactly easy or fun. There's a bunch of requirements regarding backward compatibility and testing that need to be met. Snapd upstream goes though it for almost every release and it takes anything from a couple of weeks to a month. I don't think anything is stopping either party from updating the packages, although I don't why upstream wouldn't be interested in getting involved making this happen.
I think you are taking an overly simplistic and dismissive view.
There's no confusion. I understand Podman's position. I'm simply saying that position keeps them from gaining enough users to really compete with Docker.
I run LTS Ubuntu versions for core stability. That usually doesn't keep me from getting the latest version of software that it makes sense to keep updated. Case in point...Docker!
So, on my "old" version of Ubuntu, which I agree is completely "on me" for choosing it, I'm able to easily run the latest version of Docker. They care about my use case, make my life as a sysadmin easier, so I use their software.
Podman doesn't and I therefore have avoided using their software for years even though they have some compelling features.
If you use an LTS version of Ubuntu (or Red Hat etc.), you are going to have older versions of software. That's just how it works. And is kind of the point of LTS. If you want more recent versions, use a rolling release or a more recent (non-LTS) version of Ubuntu (or whatever). The latest version of podman is going to depend on recent versions of the kernel and systemd, etc. and isn't going to work well on an older distro with older versions of those dependencies.
There's a perfectly legit reason for wanting a stable, non-rolling, OS while keeping some software updated beyond versions the OS provides.
Lots of other software providers seem to care about being compatible with LTS releases of popular distros, like...Docker! They seem to manage supporting the older kernel and systemd versions just fine.
And, my entire argument here, is that this difference between Podman and Docker is glaring and one of the reasons Podman isn't more popular.
It's interesting that Linux users have been conditioned to expect this level of coupling when any other user would find that absurd. Do Windows 10 users expect to be stuck on software from 2015? Should one have to switch to Windows Insiders just to run recent games?
> but you could create your own .deb packages for each github release, which can be installed much quicker than downloading and compiling source code and all its dependencies.
This is why OSS maintainers have burn out. Always wanting more and more. Not even the source code is good enough.
My point is that it's not good enough to compete in this space.
Look at the distros that Docker supports. That kind of support is what users expect. When Podman just leaves it up to the distros to support, it's understandable. But, yes, it's not enough.
a.k.a. the most recent stable LTS, which will be succeeded by 26.04.1. Unless your hardware doesn't work on 24.04.4, I would not upgrade to 26.04 yet, unless you enjoy unexpected behavior in the console.
One thing I don't like about Podman is that it pretends to be docker-compatible while having some minor differences that will come to bite you. And users of your docker-based project who try to run it on Podman will come to you and complain.
I've found most of the differences to come not from the socket API, or the logical behavior, or CLI differences. But instead from assumptions Docker makes, that it's running rootful, when Podman will not (by default).
As such, most of the fixes for Podman/Docker incompatibilities is just addressing that assumption with a few extra flags on the Podman commands to change how the user namespace maps between the container and the host, etc etc.
This has been my experience too. And that conclusion, I've found that if I really don't want to deal with such quirks, I can indeed literally just run the same docker compose file in rootful mode, and it works.
Making the changes required to run under rootless is often very simple.
There are also different CLI flags (I recall something related to building and pushing multi-arch containers) and different features supported in compose.yml. Even rootful Podman won't be fully Docker-compatible.
My #1 complaint by far is that it --- pretty much silently --- depends on systemd to work correctly.
Try having a docker-compose with a service that waits until a dependency is healthy --- in a host that has no systemd (such as Alpine Linux).
The service will never start because Podman relies on systemd (and only systemd) to do the periodic healthchecks which it needs to do in order to handle such dependencies.
And of course, this fact isn't adequately documented anywhere. And Red Hat says they'll never, ever drop this dependency.
---
But I don't know if there are any tools compatible with the Docker ecosystem other than Podman. I'd love to find one.
Yeah that's an unfortunate downside of the daemon-less design. Service management (like dependencies, health checks, etc) are outsourced to systemd since there's nothing locally available to monitor them. The fact that the documentation doesn't mention this is a major miss.
On macOS, there's Orbstack, which is ridiculously compatible (I believe it's based on the same moby engine underneath). On Linux there's oodles of options for working with OCI containers, but nothing else I know of that's compatible with the docker API or CLI.
I've been using Podman on Mac and Linux for 3 years, and unfortunately, I have found this to be perennially true. I am willing to doggedly pursue the root cause and file bugs, but for many people it will just seem broken.
Most recently: Netavark doesn't match Docker's behavior with accepting broadcast traffic on a published port.
Yes! It put me off Podman for years. I do now think it has some clever ideas and if you’re running RHEL it’s a no brainer, but they should be more upfront that you will have to adapt. Especially if you’re moving from rootful docker to rootless Podman.
We moved from docker to podman about 15 months ago, and I'm never going back. I (personally) love the quadlet (read: systemd) integration, that makes it so much easier to monitor a set of running services, be they regular systemd services or containers. Running rootless is as straightforward as it gets and on top of it, podman is blazingly fast. I, personally, don't miss docker compose all that much, but I understand if the lack of docker compose is a showstopper for others. I've never tried podman's compose plugin.
The one big reason I dread giving up compose files is that they're a great way to have system agnostic documentation on how to setup a new stack. That means every developer can just start the thing locally, and it's pretty much the same as on the server (and everyone elses laptop).
Podman doesn't officially support any thing platform agnostic. How do you (or anyone) deal with this for a project in active development?
podman can work with kube files, which is the YAML format from Kubernetes. That's more "platform agnostic" than docker-compose. And it can be read as a documentation in the same way.
You don't have to learn much resource jargon for a quadlet, just the Pod type, and a relatively small subset of it at that (you're not going to be using things like selectors or priority classes). And there's a script that can convert a compose file to a quadlet, so you don't have to do it from scratch.
I switched from a giant docker compose file to podman quadlets on my homelab. IIRC it look me a little while to translate the first couple of services because there wasn't (at the time, at least) as much documentation/examples of quadlets as compose files, but after that it was a piece of cake. I highly recommend them.
The only issue I have is validation, there isn't a convenient built-in command to validate quadlet files and systemd doesn't warn you if any fail to generate. You either have to do a --dry-run first (and probably alias the full command to something reasonable) or check the journal for errors.
Swapped a few years back (pre 5.0), haven't looked back. For compose files I'd look into using quadlets.
For quick conversions you can use compose files directly with podman-compose or docker compose pointed at the podman socket[0].
There's also podlet[1] which converts compose files into native quadlets. It does a pretty good job of taking care of everything for you and for a lot of simple to medium complexity compose files it will Just Work. There's talk of making it into a library of some kind so other tools can transparently convert compose files to quadlets so hopefully we'll see more stuff like it.
Otherwise, writing your own Quadlet files isn't too hard if you're at all familiar with systemd unit files. Most `docker run` or `podman run` arguments have direct quadlet conversions so once you get used to the INI format versus yaml it's pretty easy to see a compose file and churn out the equivalent quadlet(s).
I switched everything over to rootless podman a year or two back. Some containers ended up with permissions issues when trying to read their old data - caused by being run with a different UID. This was really the only problem I ran into, but I would have had the same issue switching from rootful docker to rootless docker.
Others have pointed out that you can use podman-compose or docker-compose pointed at podman. I did something different: I switched to using systemd to manage all my containers. It was worthwhile as I can just use my usual systemctl and journalctl utilities for both containerized and non-containerized services rather than having to remember two sets of commands.
I only experienced one minor issue with pasta (used by podman) with networking, but by then I had fully committed to podman so I did not even try to see whether I would have had this same issue if I were using docker.
I have switched on production and QA servers. I used AI tools to help with the migration. Easy peasy. On the desktop, I am still using docker. Old habits die hard. Eventually I plan to switch on the desktop as well.
I've been coding solutions against each. I'm currently having issues extracting progress from the current Podman on my TUI build pane, but now switching versions to see if it addresses it and continue working the issue.
I have zero issues with it doing the builds I need. Works same same as Docker from what I can tell.
I took Docker completely off my Macbook which has a tiny drive in it. Hardly ever use it, except for testing. Podman is super lightweight and using a project I'm developing, launches containers with dev agents in it, just the same as Windows running Docker.
I set up my stuff as all Podman when I moved from a VPS to my home server and it's been pretty simple. I didn't use any of the compose functionality because I have a single DBMS of each type and just have multiple DBs on them etc. and I use podman through the systemd quadlet system. Honestly, it's been pretty flawless.
I have the feeling the docker company is communicating a lot with Apple because virtualisation got better and better over the years. I wonder if podman would be a speed downgrade here?
> I wonder if podman would be a speed downgrade here?
Doubtful. But for sure it would be a compatibility downgrade. When I tried podman-compose a couple years ago, I found it nowhere near usable, though I'm told it's improved since. If you want a better Docker for mac, you're looking for OrbStack.
I switched a few years back and use Quadlets instead of compose now. Converting compose files to Quadlets is pretty mechanical once you get the hang of it.
Highly recommend Podman overall; there are some quirky edge cases, but for the most part it’s a smooth replacement for Docker.
If you don’t want to give up compose entirely, podman-compose exists. I just prefer Quadlets so I haven’t used it much myself.
Do you have a good canonical source on this conversion? I’ve tried the conversion tools that came out around the release of podman v4 and again with v5. But somehow the files being generated contained deprecated features which pointed me to use different commands which led me to yet again different structures which when executed in systemd brought me back to what I originally had. I never got it to work fully.
Yes. I think podlet was one of the tools that the output of podman, or the quadlet tool, suggested I use.
I will try again. Currently I have a systemd service that tries to start my services with `podman compose `. Sometimes this fails, when I start the service interactively it just works. Unknown what exactly is the issue.
podman-compose has gotten much better. I used it for a work project a few months ago, and it ran fine. That said, I know there are some random little things podman-compose doesn't support, so be careful.
It's slightly more verbose than docker-compose, but podman supports it natively and you can actually wrap your app containers into a single "pod" for easier management.
I switched from Docker to rootless Podman for our build server. Completely positive experience so far. Our builds went _down_ from 1 minute to 2 seconds.
I'm also using podman-compose that is small and delightful (I had to fix a few bugs there). It's just one Python file that you can copy.
In our shop, I wasn't one of those who knew Docker in and out, got just enough into it I could containerise applications we needed to have containerised, which was of a modest scope -- no crazy networking setup that required bleeding edge or anything like that. Anyway, after only a few months into Docker, organisation announced migration to Podman across the board. Initial impressions were soured by, ironically, poor out-of-the-box installation experience _on Red Hat Enterprise Linux_ (which we run everywhere where Linux is used) -- getting `podman` to do much of anything useful in the "rootless" mode matched the typical anecdotal evidence requiring a bunch of incancations you may or may not understand fully, as RHEL itself wasn't ready for the package, apparently. That was in 2024 though, and it rapidly got better after that. These days I have all but forgotten we used to use `docker` but use `podman` instead, but then again I have had to learn plenty enough about at least the latter -- enough I am able to navigate problems better than earlier (what with UID/GID mapping, for example -- which too had to be done manually occasionally when we first transitioned).
There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).
We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)
Yes. 99% of things just worked, zero modifications.
The few cases where something was not directly translatable was <10 minutes with a coding agent to make some minor config changes, and then it just worked.
What I have observed through my limited experience, primarily testing docker-based development env setups in podman, is that it's usually not a straight swap.
I can imagine that but I don't have those issues with the default config. So it allows using docker compose with podman directly.
On the other hand I could see it being hard for people to only install the cli part of docker. Luckily on arch that was simple due to how it's packaged.
Cool, been running my home server on podman + quadlets for about two years now and picked up a couple of things in the release notes
podman quadlet list
Added in v5.6.0, lists quadlets and their containers
podman system migrate --migrate-db
Flag added in v5.8.0. I remember seeing the bolt db deprecation warnings in the past but there was no tool to do the migration to sqlite, now there is (or just upgrade to podman 6.0.0 and it will do it automatically)
I’d wager it’s mainly just that deployment is mildly more annoying and requires more disparate steps.
Especially if you want to go rootless (and you should).
For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat intimidating when compared to just installing docker, whipping up a docker compose file and pressing “start”.
I understand why they’ve taken this approach but it’s pretty clunky and a bit unfriendly.
It's not just mildly annoying, it completely ruins a great thing.
Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose, but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.
I genuinely don't understand how someone can see the value of Docker, but then do things so completely "not-docker" when it comes to deployment/stacks/orchestration.
> but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.
To nit pick slightly, it's not really a bespoke mechanism it's just re-using the mechanisms provided by systemd. Quadlets are implemented as a systemd generator in order to re-use the existing service management system that exists on essentially all major Linux distros. Quadlets are less a direct competitor with compose (hence why Podman implements the compose spec) and more a way to better integrate containers with the rest of a system. The closer Podman native equivalent to compose is Kube files.
It can be argued that it’s Docker that is reinventing the wheel and doing its own bespoke process management, journal management etc when all of these are solved problems on Linux. Podman is instead reusing the platform which exists, Quadlets are just reusing systemd, so as a sysadmin I can manage, control and monitor docker containers using the same standard tooling that I already use to manage, control and monitor all the other processes which are running on the system.
Architecturally I find the above argument attractive. The problem is chronology. Docker and docker compose came before systems was ubiquitous and long before Quadlets, so it’s natural to think of Quadlets as reinventing the wheel.
Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.
> Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.
It also would have only run on Linux hosts (and not all of those at that), so something else would have been adopted instead. Docker didn't win by being superior to every alternative, it won by being good enough and being everywhere. For portable orchestration, Desktop does ship with kubernetes that's literally one click to enable.
> Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose
This isn't (completely) true. I found podman-compose to be a more or less drop-in replacement for docker-compose. I know that in the past support was patchy, but things are rather good now.
Pretty sure that's because podman-compose literally calls docker-compose under the hood.
e: from the manpage:
"podman compose is a thin wrapper around an external compose provider such as docker-compose or podman-compose. This means that podman compose is executing another tool that implements the compose functionality but sets up the environment in a way to let the compose provider communicate transparently with the local Podman socket. The specified options as well as the command and argument are passed directly to the compose provider."
That's the "podman compose" wrapper command. podman-compose (the implementation referenced in the first sentence of your quote) does not call docker-compose: https://github.com/containers/podman-compose
FWIW, for me docker compose works just fine with podman. I am not sure what kind of additional configuration is needed these days, make sure you are running podman with the socket thing and perhaps set DOCKER_HOST. It's just a client / frontend to an API that podman provides.
IIRC `podman compose` can invoke either `podman-compose` or `docker-compose` and sets up the environment for the call, so I don't think you need to even really do anything special other than install either of the 2 commands
The purpose of quadlets is when you want good integration with systemd.
The better equivalent of docker compose is podman kube, which does use a single file. And it isn't bespoke, it uses the same format as kunernetes.
And if you prefer the docker compose format, podman-compose is available as a separate tool.
And FWIW docker compose is a separate tool from docker itself as well (and needs to be installed separately on several linux distros). And can actually work with podman instead of docker.
> the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts
Podman does not require systemd (thank God). I use a simple podman compose up/down in a user systemd file to automatically bring my containers up at boot, but other mechanisms are possible, like quadlets and init scripts.
Quadlets are awesome and honestly I think one of the best additive things that podman has on top of the regular docker toolset.
I use podman regularly, and despite it being a good drop-in replacement like 95% of the time, the 5% of the time where it isn't seamless are super painful. For example, skaffold (https://skaffold.dev/) pukes all over itself when you try to run podman as a drop in replacement. I'm sure there are plenty of other examples, but that one stops me from using podman at work in addition to in my personal projects.
Well, but that's kinda the point, isn't it? You know that other mechanisms are possible, but you opted out for a user systemd file. I know that too, and I also just use systemd for that. Because the alternative doesn't look much easier. I guess it makes sense that they try to discourage it now, because for serious deployment it isn't the best option. But when I install Podman on my laptop, I really wish the systemd configs would be added automatically without me even knowing.
I mean, really, if we keep in mind that formally these are 2 totally unrelated projects, it's hard to complain. Yes, it's almost seamless. But since when installing Podman everyone thinks roughly "I am installing a newer better Docker version", and we all already have a few dozens of custom Docker containers running, it's hard no to wish it was even more seamless and backwards-compatible. I remember the transition process wasn't nearly as smooth as I hoped, and every small glitch is kinda stressful, because you know that currently all of it "somehow works", and if something breaks you probably won't even notice right away.
Linux. It’s not the installation of podman that can be fiddly. It’s the setting up systemd unit files and local user accounts for rootless / daemonless deployment of containerized apps that can be a headache.
You could quite simply have a systemd file that calls podman compose up when the service starts and podman compose down when it stops. Basically the same systemd file for every container stack defined in a single compose.yml. It's extremely easy, and does not do stuff behind your back like Docker (such as silently altering iptables rules).
The question was why Podman doesn’t have the adoption levels that Docker does, and my supposition was that (for those that don’t have much Linux administration experience) added steps like systems configs, or quadlets etc are just another barrier to entry that you don’t have with Docker.
I’m not arguing that Docker is better (I think Podman wins in a lot of ways actually) just that Podman requires a bit of extra work to implement well and that is just enough of an annoyance to tip the scales towards Docker.
I think it's just because Docker came before. Podman is more secure and architecturally cleaner, but not touching something that works is an equally good reason not to migrate.
It might not be the popular way here in HN but nowadays I just ask llm to create required configuration files and everything is so easy. Of course you need to review them but tbh no more headaches at least with config files.
> Doesn't quadlet fix some or all of those problems?
It definitely can solve some of those problems, and that’s the approach I’d generally recommend.
But to answer OP’s question - my supposition was that the mere fact that such a device is even necessary (when compared to docker) is an added work that isn’t obviously easy to implement for someone who is just trying to learn how to containerize their app (and might be a developer but not that experienced with Linux administration) and this one of the main reasons Podman isn’t as popular as Docker.
I think Podman is better in a number of ways, but it isn’t the most intuitive to implement compared to Docker.
Or, to look at it another way, the answer is that it’s the developers who don’t want to learn something new that, objectively speaking, might turn out to be better than what they’re used to.
I gave up on Podman for some minor reasons: one was that they decided to deviate from Docker and handle SELinux differently, which required effort to change the SELinux security labels on a stock Centos system. That made it a no go.
The other issue is minor differences from Docker, but small enough that a packaged up Docker compose doesn’t work out of the box. It’s not a good use of my time to debug that when I could just switch to Docker, have it work, and get on with my day.
Can you elaborate on SELinux? It affected me too but I just had to add :Z to my mount argument. Curious about whether there's further impact I'm unaware of.
This is my biggest gripe. If you're using docker-compose.yml on a team that mostly uses docker, you can't use use that same docker-compose.yml with rootless podman. Any volume mounts that need to be writable (like the app, or databases) need to have `:X` or `:x` as a suffix, or podman won't set the SELinux label correctly to make it writable. But if you add those, docker blows up because it doesn't understand them.
There were other problems although it’s been a few years so I’ve forgotten them. I think the container I had trouble with Ory Kratos. We did eventually get it to work but had to change the sample docker deployment a fair bit.
macOS had a seperate set of problems. I ended up just going with buildx and Colima on macOS. (We don’t use Docker Desktop.)
Long term I’d like to try to switch to podman again, but it needs to have a “be 100% compatible with Docker” mode as opposed to this:
CentOS is very old and very out of date now. Unless you're using stream, which I haven't followed along with that at all. Podman is on v6 now, after all. A lot of systemd changes have also happened since.
Last time I checked podman compose was only a superficial docker compose equivalent. Also stuff like inotify seems to randomly break a lot on the podman side.
I'd love to be able to recommend people use podman but not having a good docker compose compatibility and missing inotify on volumes makes the DX just too problematic.
Podman has supported plugin compose (v2) for years now, and I believe that's the version I used before I switched to Quadlets, but I must have not needed Buildkit features back then because those are apparently still unsupported over v2.
Don't know about that. I did a ddg search "using docker compose (v2) plugin with podman" I do get some tutorials but they all are from 2026. This also aligns with my experience from late 2024 where you where typical advised to use `podman compose` or the compose script.
Here's the 2022 release announcement for Podman 4.1 claiming support for compose v2. Your distro may have been stuck with an older Podman version for much longer though.
I spent about a week last year trying to move from docker+compose plugin to a podman hosted variant. It has issues on multiple stages of the lifecycle as I mentioned in my original comment. Mac users lose fs events, a lot of compose.yml features are flaky (post start events), buggy (reset and import), or just not implemented (don't remember the exact features).
If you use podman and have no issues that is awesome but your use case is probably quite narrow, you are most probably on a non fedora based Linux and keep compose usage to a minimum.
I think a stronger brand name. Also on macOS I found Docker Desktop to be more straightforward. Also lately it has been very error prone. Randomly failing at mounting files, or cleaning up networking rules, or suddenly becoming bog slow so I have to restart the VM.
Podman on macOS feels miles less refined. Orbstack is a way better choice.
I only use podman on Linux and there it is blazing fast. Even so, most features seem to be geared to be able to replace kubernetes in combination with systemd. And then something simple as docker compose support is flaky and it’s TUI/ux lags behind the original.
Now that Apple has containerization api’s probably the gap closed but when I ran benchmarks a couple years ago Orbstack would on average perform the same build at 4x faster wall clock time as docker desktop
Build as in building images or as in building a project when mounted in a container? I notice 3-4x performance degradation of our maven builds in containers. With golang I haven’t noticed much performance degradation, but that may be because it is fast enough anyway.
One advantage of Docker is reliable host-to-container file change notifications, allowing tools like Vite inside the container to detect changes. Podman and many alternatives don’t handle this well for our web development on macOS.
Not even Tart or Apple Container support it, as far as I know. Maybe someone has found a way.
> don’t handle this well for our web development on macOS
In general this seems to be a common complaint here. If you're developing with cloud runners or on linux infra you won't run into this, but on macOS for local development it is impactful.
Just today, I tried to run docker compose on a remote host via podman-docker on Fedora (Asahi). I ran into all sorts of buildx issues, and the easiest fix for me was to remove podman and install docker instead.
I tried working through it with Claude, but after a few failed attempts I gave up. I'd like to use podman, but the docker compose + buildx compatibility gaps made it more trouble than it was worth for now. I'm definitely going to try it again.
If you want podman equivalents, you can either use pods of multi containers are the need, or if multi arch builds are the main buildx need, OCI manifests work.
Fedora and selinux may be a thing to look into if you were trying to share volumes.
I am posting this from a park on my phone, so this may be slightly wrong, but this is the multiarch case that seems to be harder to find for many people.
Last time I evaluated podman, Ubuntu was second class citizen. Rootless was non trivial and required additional setup. Documentation also suck.
Docker is something we all already hate, milion edge cases and forever bugs but at least well documented and understood. Podman claim to be drop-in replacement does it mean it carry docker shitness? Examples: ufw punch through, env file handling, volumes, etc
Last time I tried rootless podman was about 6 months ago and it was a total mess. I was trying to use it to run a container as me (user 1000) and mount a directory from my home (owned by user 1000) and it drove me and Claude around the bend. It's not a podman vs docker thing per se, just rootless being a total pain. However I just enabled the docker service, ran the same command on docker and it worked. I think I just left docker running after that. I realised that on my home setup I don't care enough to fight with it. Sometimes you just want to do the thing you want to do and not turn it into a 4 hour learning session about some side shit.
Had similar issues with podman on a Steam Deck of mine that I use as a little home server - eventually got a configuration working fine but was a real pain.
With recent advances in both systemd and podman a lot of this is basically a non-issue.
Documentation has also gotten better.
For tools that require docker to work, like testcontainers and tilt, I've found some annoyances using podman, but ultimately I've been able to work around them.
For everything else, it's pretty much a drop in replacement.
One of the key design principles of podman was rootless operation; they were so disgusted by Docker being a daemon they decided to do a full open source implementation. I've never had an issue with it running without root.
Most people simply do not care. They just want a Dockerfile to become an image, and they want to run that image. I use both... rootless podman is nice. Although the promise of ez systemd integration is a bit... oversold. I use it with systemd however with my own hand-crafted unit files. Pretty good combo.
In many places it doesn't matter, because cheap companies don't want to even hear about Docker, so one gets to choose between podman, rancher, and if on Windows wslc is going to be a thing.
Docker (the company) lost the plot in Linux containers, OCI got standardized, alternative runtimes came to be, and very few companies actually care to pay for Docker Desktop or the other services they sell.
I know, but companies legal or IT department make it easier, no docker of any kind being installed from https://www.docker.com.
Microsoft also is finally adding their own docker cli (wslc), due to having had enough pressure that many companies don't want to instal third party tools for Linux/Windows containers, even if API is compatible with docker daemon.
Apple is doing a similar approach on top of their virtualisation framework.
I ran into an issue I couldn't figure out how to solve with podman. Some of the testcontainers my test suites would run wouldn't start in time causing tests to fail locally. Switching back to docker desktop solved the problem.
I went all in on podman compose last year but went all back because off constant permission errors. I thought it was going to be better than docker because I run the containers as a user… but man the amount of time I wasted on files that either I or the container itself or some other container couldn’t read… With docker I felt that stuff just works.
And then there are the extra steps: Enable user lingering, make a systemd service that starts the compose containers (and there is nothing really “native”, it’s a script.) With Docker compose containers just restart if you say so in the file.
There are many great things about podman, will try again in a year or so perhaps?
> I went all in on podman compose last year but went all back because off constant permission errors.
The issue is that "ease of use" and "it just works" come at the expensive of security and the principle of least privilege. Docker makes things easy by running a daemon as root. Rootless Podman forces you to think about permissions and does not stab you in the back by overwriting your firewall rules.
Yes, the firewall rule altering was what drove us to podman! Was kind of weird to find a container's Postgres wide open on 5432 after a `sudo ufw default deny`. Madness really.
But as said below, the permissions issues got to us.
Mostly self made containers, also one with Claude-code, but I couldn't for the life of me get it to be able to store and retrieve credentials in an externally mounted folder (~/.claude). I tried everything from fixing the user creation process in the container, `--userns=keep-id`, `--userns=keep-id:uid=1000,gid=1000`, several tags, :Z, :U, `chown`-ing after creation etc. And I keep running into that stuff.
I wish that "run podman containers as a user, rootless" would just simply mean: All the things are also the property of the user, but you get weird uid/guid combos and stuff on your filesystem as owners you never heard of (like www-data, but not that one in particular) due to the mismatches.
If containers can ever simply be run as user like they are a user process, that would be so nice.
It's a lot of stuff to set up though, compared to disaster recovery instructions being: Install Docker, restore state from x, docker compose up -d.
I want it all "as code", this could certainly be automated (scripts, nix), but it would be nice if it really was as simple as one single compose file, that should be the goal, imho.
To be clear, all of that setup happens once on your host machine, then you never have to think about it again! You can compose to your heart's content. I think podman just doesn't want to commit to a particular DNS solution so they leave that decision to you.
Fuse overlayfs was noticeably slower than Docker's overlayfs setup. Maybe there's a way to reconfigure but I haven't checked lately.
I think it was Zig (building ghostty) was broken in podman with obscure "unknown file" errors. Turns out that was lack of fuse-overlayfs supporting some attributes it was trying to check.
It's random, little things like that which keep biting me every time I try to make the switch. I use it for simple stuff though.
I've never interacted with anyone that knew them by another name. It's always (docker) container, where they may leave out the docker term, but if questioed what kind of container they mean theyll say it.
And the times I've called them OCI container (or image when talking about those) nobody knew what I meant until I clarified to docker
I hear occasionally Image Container, but even that is fundamentally docker flavored because when disambiguating for the term "image".
This comes up because we use both the Image and Package registries on Gitlab, so we sometimes have to absolutely specify, and the conversation lends to "The Docker Image one".
I never liked Docker, but someone pointed out to me that Podman is backwards compatible, doesn't need root, and even has simulated docker commands if you need them so you can just alias podman to docker... and voila same experience, so every online tutorial works just fine.
A few years ago, I started moving towards Podman when it got to that "good enough" point on both Linux and macOS and when Docker started to remind people about Docker Desktop that it needed a license for commercial use.
Even then, it took around a year or so to transition.
Isn't Docker is basically a front end to containerd, the most common k8s container runtime? One could just as well ask why use a completely separate container stack just for local development when docker shares the same business end as the prod environment.
I mean, one answer is that docker configuration on your local dev machine can go one of two ways:
1. You have to use `sudo` for every `docker ...` command; or
2. You add your user to the `docker` group and now anything that can run as your user can use docker to read or write any file on your system, making docker into the best local privilege escalation option out there.
Podman has some serious issues they are not really fixing, we ran into an issue where builds just hang for a few minutes before doing anything. So we had to switch back to using docker desktop locally for that.
> No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation.
docker-compose is one big reason. The networking aspect of it still isn't feature-compatible compared to using docker. I keep trying podman+docker-compose again every 6–9 month, and there's also some issue that makes it unfeasible for my use case.
Its IPv6 implementation is also broken, and connections from the host to the container are dropped if the host doesn't have a public IPv6 address (WTF!?). I reported this in June 2024 (#22959). Not being able to reach an HTTP server on a podman container from my host when I'm offline is ridiculous.
Lots and lots of tiny little bugs and quirks which are a nuisance to deal with. With docker, everything just works.
Another recent bug I hit was that the value of the environment variable TMPDIR and XDG_RUNTIME_DIR is persisted to disk with podman's internal state. After a reboot, if either of those has changed, nothing works because podman tries to use directories that don't exist. This… seems to be due to workarounds for wildly broken setups.
I've reported many of these bugs, and have a backlog of a lot more that I haven't bothered to report yet.
What honestly really surprises me is how many people actually manage to use podman for work despite all its issues.
They really upset me with how they introduced it initially, and I haven't looked at it since.
Redhat swapped in podman and removed docker, and all of the config/images/scripts I had spend 2 years making stopped working on new/replacement hosts... So I had to spend a lot of time in meetings/filling out paperwork to get docker back. I haven't forgiven Redhat for dropping that shitty experience on my head.
For the company I work at, it’s primarily inertia. We started using containers with Docker. And then it just continued. We are two out of 20+ developers who would like to use Podman, but the rest is just ”eh, why bother?”. And I don’t fully fault them for holding that position, Docker generally works. Why switch to something which may or may not provide some benefit (most which will be indirect such as better security and setup)? I still continue to mention Podman regularly though …
This was about a year ago, but I had trouble getting podman to add an nvidia GPU so that the container could use it. It was technically possible (I succeeded) but it was annoying and "different".
I used rancher + podman on Windows. Mainly Rancher. The last 8 months I use exclusively Podman + Podman Desktop. Rancher has a slightly better desktop app and can manage podman.
I mean for local dev I like that I can just press one button and have Kubernetes available. Podman Desktop had something approaching that simplicity but I have found Docker Desktop more stable in my limited experience with it.
Rootless was the reason I switched to Podman years ago. It's just so smooth and I don't have to worry about obscure permissions and services errors anymore.
I like Podman, but what's up with that grey text colour? It looks ugly and the contrast of 4.96:1 makes it hard to read (does not reach WCAG AAA level).
How is Podman these days? I use OrbStack on macOS and it seems to be much faster, not sure how everything will shake out now that macOS 27 is adding (more) native and performant Linux containers, similar to WSL with micro-VMs.
I'm not sure about macOS, but it is seamless on Linux for my use cases. One thing to note is that Podman Compose defaults to docker-compose as the provider, and I haven't used the podman-compose provider (confusingly named slightly different to Podman Compose, which is the top level abstraction on top of docker-compose or podman-compose). You can still run containers through the Docker engine with Podman, if you need to.
Same question, same scenario. I tried it on MacOS, and the first issue I experienced (don’t recall what it was) had me deep into Redhat forums to even understand what was happening. Switching to OrbStack was a no-brainer, but there are obvious tradeoffs from a features perspective.
I doubled down on Podman when moving to Fedora a couple years ago- couple small hiccups but mostly my shallow knowledge on SELinux and bind mounts. Big fan, especially quadlets + stow on my homelab- thanks Podman people!
SO much of the text of a comment thread is not black, though. The line above each comment is gray. Downvoted comments are various shades of gray. The "help" link next to the comment box is gray.
I've seen worse, but gray on beige is not my favorite.
If any Podman engineers are here: does the new /libpod/local/artifacts/add endpoint let me ingest individual layers? I have an alternative pull client that's currently a little hamstrung on Podman compared to docker+containerd, due to having to convert the entire image to tarball to ingest rather than only new layers.
I wanted to love Podman, but unfortunately, in my current employer's we have macOS machines.
I had issues like when Podman randomly stopped responding and I had to "kill" the podman machine more than once or some container randomly built differently or failed (due to architecture diff).
This was not the case with Orbstack, but they are license-only, closed source and macOS only oriented.
I wish I could find a consistently good container management system that is multiplatform, ideally open source as well.
Having said this, I think I will try Podman (6.0) again, in macOS :)
> podman doesn't spew garbage and punch holes in my firewall (iptables)
The way Docker silently rewrites iptables rules is just insane. It boggles my mind that someone thought that it would be a good idea, and that it survived a peer review.
podman's been great for me on macOS for testing stuff quick; which earlier used to need a whole limactl[3]/virt thing.
you can set it up with qemu-user-static for --platform linux/amd64; i don't remember which i exactly used, or if official docs have been updated for it but looked something like [1]
there is one sneaky bug in qemu that breaks uv [2] for cross-platform targets so i keep having to fall back to lima for that, but great otherwise.
Does it still completely screw up file/group owners in user containers? Because they keep saying it gets fixed and then that 1 out of 10 times it's not.
I don't understand how podman can be used for serious development work. Sure, if you want to be bound to one single platform (linux), and create a bunch of individual files, you can sort of get something a little bit like compose.
But the beauty of compose is the same as the beauty of the Dockerfile. Portability, reproducibility (mostly), and a single readable file with all the relevant parts. It means a developer can use the same compose file locally that's used for deployment.
How do people actually work with podman? Do you work with a team? How do you setup a local development stack the way you would with compose?
We have a consistent wsl image for everyone. So they are all on Linux. Then we have a podman pod defined in a bash script. We have a Justfile where you can run ‘just services’ and it all “just works (tm)”.
Once the pod is defined you can use ‘podman pod up/down’ to interact with it, but mostly we encourage people to use the Just recipes to do the things.
The thing is, podman has docker-compose like management built in, in the form of pods, but it doesn’t seem to be very well socialized.
On the server we use quartet+systemd and it’s great. Never had an issue with that part.
podman-compose is "mostly" compatible. I "plain" podman at work, but there we just have a bunch of shell scripts that spin up/down/build containers. For regular dev work, it's fine.
For personal stuff, I've been experimenting with podman's Kubernetes files: https://docs.podman.io/en/latest/markdown/podman-kube.1.html. Which, IMO, "feel" like docker-compose the most. You can run services via "podman kube play ..." and install them via quadlet install too.
I run podman for local dev containers or for isolated sandboxes mostly. Anything needing orchestration and I go straight to k8s, never liked docker compose.
After Docker Desktop randomly started consuming insane amounts of memory again we switched to Podman and it was literally as easy as installing it and pointing it at our docker-compose.yml.
Zero changes needed and now I don’t need to keep a daemon running.
Great software.
I liked Orbstack better than colima which was better than Docker Desktop. Then I found https://smolmachines.com's smolvm microvms.
Fixed link: https://smolmachines.com/
thanks!
Since I came across orbstack that's the only one I use for docker on macOS
been using orbstack but this smol stuff is interesting
is this firecracker or total rewrite
author of smol machines here, it has no relation to firecracker.
It runs ontop of the libkrun vmm forked with optimizations, which is the underlying lib powering podman as well.
open source, will contribute upstream when possible: https://github.com/smol-machines/libkrun
Upthread the implication seems to be that smolmachines would be in some way a replacement for orbstack to run docker containers
But it seems more like a completely different way to run isolated workloads?
smol machines is a virtual machine, akin to firecracker but designed to run locally as well
It also has container-inages support built-in with crun so you can create a VM with a container running by default.
You can also just... run docker inside of it.
good stuff man i just installed it and its super fast im just not sure is this really secure to run untrusted code i can't find any white papers
the underlying vmm is libkrun: https://github.com/libkrun/libkrun is battle tested and used for podman.
It provides kernel isolation for running untrusted code which is a security boundary that traditional containers can't guarantee.
I'm engaged with a third party security penetration company for their review, and will be happy to share it publicly when it is available.
thank you. definitely enjoying smol. this is a very nice alternative to docker, orbstack even firecracker
Can smolmachines run devcontainers? K3d?
yes to both, here's the example for running docker(indirectly, devcontainers) inside smolvm:
https://github.com/smol-machines/smolvm/blob/main/examples/d...
This is very cool. The example is thorough and well documented.
I am trying smolmachines this weekend.
Thanks.
don't forget `alias docker='podman'` for muscle memory
It's been a couple months so I forget what problems I ran into, but Docker's AI bullshit pushed me over the edge and I tried switching to Podman. I ran into some compatibility issues. Alas I don't recall the details.
So I tried Rancher Desktop and other than I keep forgetting its name it just worked.
It's another simple option for those who need it.
I really love Quadlet. I used to host my rootless containers on Hetzner, Ansible, SystemD and RockyLinux for years without any issues and extracted it to template repo [1].
[1] https://github.com/Mati365/hetzner-podman-bunjs-deploy
I switched my home server from k3s to quadlet and saw an 8% drop in power usage.
Well hang on a second I have two nodes running k3s. 8%??
Did you accidentally also swap out the CPU governor?
Why not? On my home server, k3s (single-node master), sitting idle (no workload, no changes), has amassed as much CPU time as a full virtual machine running Home Assistant: 17.75 hours in 106 hours of uptime.
All those abstractions and cluster features do not come for free.
I think it's an 8% drop on the previous usage, not 8% of total compute drop.
If I may ask, what do you use to host now?
As long as they refuse to support installing on Ubuntu (and other popular distros), without relying on the distro repos which are always out of date, they will continue to lose to Docker.
Any serious project in this space supports as many distros as possible.
It's OSS, so I'm not complaining per se, I have no right to. They owe me nothing.
But this one issue has kept me from seriously considering Podman for years. They don't care about my use case and I therefore don't care to use their project.
When getting the latest version looks like this[1], who is really going to consider this for serious production uses?
1: https://github.com/podman-container-tools/podman/discussions...
Entirely different perspective: If I have to add a separate repo, then this is a red flag.
> Any serious project in this space supports as many distros as possible.
Wrong way around. Any serious product is supported by lots of distros. Distros curate their selection and if nobody bothered packaging your stuff, then your stuff is not good enough.
To be clear, it doesn't explicitly not support Ubuntu or anything, it just doesn't privilege it. Podman doesn't produce packages for any distros.
Agreed. But, IMO, it looks like amateur hour when you compare their stance to the distro support Docker provides.
A slightly different perspective: Podman is made by the distro people (RedHat/Fedora). And they consider it unacceptable to mess with the software distribution channels of a distro. If Debian does not want latest Podman, they are not going to push the latest version to Debian users behind Debian repo's "back". This is a distro-to-distro respect rather than amateur hour.
I do not think this perspective is correct. You are considering official distro repos as a means to control what is allowed to be run on Debian. This is a kind of control commercial platforms often value because they use it to extract rent or to micromanage their experience that they sell to the rubes.
Debian DOES care about about both experience and ethics of what is allowed to be distributed in official repos but it is contrary to the ethos of free software to care what you run on your machine or by extension what others choose to offer. You are intuiting a corporate sort of perspective where neither it nor the raison d'être for it exists.
> You are considering official distro repos as a means to control what is allowed to be run on Debian.
I am rather considering official repos as a means to keeping your Debian system in a "supported" state. Many users, including software developers, want to only install software (or sw versions) that would not put their system in an unsupported configuration.
> Debian DOES care about about both experience and ethics of what is allowed to be distributed in official repos
Podman is widely distributed in official Debian repos, so ethics is not a question in this particular case. We are only talking about Debian repos being conservative with the versions of the software in the repos - not limited to Podman. Debian does not encourage users to install software from 3rd-party repos just to get a newer version of an existing package because the stability of the system (and the ability to do major version upgrades) cannot be guaranteed otherwise.
> As long as they refuse to support installing on Ubuntu (and other popular distros), without relying on the distro repos which are always out of date, they will continue to lose to Docker.
Your needs are incomprehensible to me: that is exactly why I use podman: a predictable version of it is in my distro's repos.
I go to docker.com and how do I even install the thing? What's "docker sandboxes"?
Get the latest version of docker? Why would I want the latest version? I don't want the latest version, I want the same version as my other machines have, so things work everywhere. And I usually don't know what version that is. But I sure do know what Debian version my other machines run!
Again, your needs are utterly incomprehensible to me.
I run Ubuntu 24.04 on my laptop and servers. The Podman version is 4.9.3.
It may be incompressible to you, but I'm not alone in thinking it's a problem:
https://github.com/podman-container-tools/podman/issues/2707...
I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one.
Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay.
Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Universe. Everything in this thread makes sense, it's a matter of who wants to pay for it. End users have been asking for this for years.
The engineers don't make the decisions. Canonical doesn't want to pay, Red Hat doesn't want to pay. Users stuck in the middle.
I get podman from brew even on Linux because the idea that vendors fighting over uploading tarballs to a server is stupid. Fuck distros.
I'm confused, the latest LTS version of Ubuntu is 26.04 (released on 2026/04/23) and has Podman v5.7.0 (released on 2025/11/11). [1]
If they're on a 24.04 LTS release is there any reason they would be on a newer version of Podman (without jumping through hoops)? Ubuntu 24.04LTS released on 2024/04/25 and the Debian Import Freeze was on 2024/02/29.
The bleeding edge Podman release at that time was a pre-release v5.0.0-RC3 (2024/02/22) and the latest actual release was v4.9.3 (2024/02/13). That's the version Ubuntu 24.04LTS has. [2][3][4]
So aren't they on the exact version of Podman they're supposed to be on for the operating system version they're running?
[1] https://packages.ubuntu.com/resolute/podman
[2] https://packages.ubuntu.com/noble/podman
[3] https://documentation.ubuntu.com/release-notes/24.04/schedul...
[4] https://github.com/podman-container-tools/podman/releases?pa...
> 5.7.0+ds2-3build1
No thanks I'll get it from podman.
What's wrong with 5.7.0+ds2-3build1 ?
Ubuntu loves to mess with upstream by shipping a bunch of vendor patches. It's one of the main reasons I run Fedora, they do this the least in my experience
Every distro does this. That's what a distro is.
I don't claim to understand the business or politics between RedHat and Ubuntu.
I do know many projects with way less resources seem to be able to support Ubuntu and other popular distros just fine. Often through PPAs or their own apt repos (like Docker, PostgreSQL, or Incus).
If RedHat doesn't choose to, so be it. But IMO, they can't really compete with Docker when getting a recent release on the most popular distros is such a major cluster F.
If I manage an open source program like this, my job is to write the code and docs, publish it somewhere and maybe make some changes to make it more portable. That's it!
It's the distro's job to package and integrate this software with the rest of the system, to make it easier for their users.
I have 1677 packages installed. I absolutely _do not_ want to go to 1677 places to install or look for the latest version.
> If RedHat doesn't choose to
You still don't get it: Canonical didn't choose to include a newer version in their 24.04 release.
24.04 is a stable release. Package updates in stable releases need to follow the Stable Release Update process https://ubuntu.com/project/docs/SRU/stable-release-updates/ In essence someone needs to do contribute time and effort to make it happen. Canonical is free to choose the packages they want to maintain themselves and which ones go to universe and are community maintained. The upstream, if they care enough, can choose to get involved and try to do the updates. The process isn't exactly easy or fun. There's a bunch of requirements regarding backward compatibility and testing that need to be met. Snapd upstream goes though it for almost every release and it takes anything from a couple of weeks to a month. I don't think anything is stopping either party from updating the packages, although I don't why upstream wouldn't be interested in getting involved making this happen.
Thank you for the explanation!
That's on Ubuntu, and on you choosing to run an old version of Ubuntu, nothing to do with podman.
You're not alone in thinking it, but the other people are just similarly confused. The last reply to that thread explains the situation well[0].
[0]: https://github.com/podman-container-tools/podman/issues/2707...
I think you are taking an overly simplistic and dismissive view.
There's no confusion. I understand Podman's position. I'm simply saying that position keeps them from gaining enough users to really compete with Docker.
I run LTS Ubuntu versions for core stability. That usually doesn't keep me from getting the latest version of software that it makes sense to keep updated. Case in point...Docker!
So, on my "old" version of Ubuntu, which I agree is completely "on me" for choosing it, I'm able to easily run the latest version of Docker. They care about my use case, make my life as a sysadmin easier, so I use their software.
Podman doesn't and I therefore have avoided using their software for years even though they have some compelling features.
If you use an LTS version of Ubuntu (or Red Hat etc.), you are going to have older versions of software. That's just how it works. And is kind of the point of LTS. If you want more recent versions, use a rolling release or a more recent (non-LTS) version of Ubuntu (or whatever). The latest version of podman is going to depend on recent versions of the kernel and systemd, etc. and isn't going to work well on an older distro with older versions of those dependencies.
There's a perfectly legit reason for wanting a stable, non-rolling, OS while keeping some software updated beyond versions the OS provides.
Lots of other software providers seem to care about being compatible with LTS releases of popular distros, like...Docker! They seem to manage supporting the older kernel and systemd versions just fine.
And, my entire argument here, is that this difference between Podman and Docker is glaring and one of the reasons Podman isn't more popular.
It's interesting that Linux users have been conditioned to expect this level of coupling when any other user would find that absurd. Do Windows 10 users expect to be stuck on software from 2015? Should one have to switch to Windows Insiders just to run recent games?
It's just a choice of stability https://vanillaos.org/blog/article/2023-01-31/point-vs-rolli...
And that issue shows the problem with OSS.
Nothing is ever good enough.
> Please report this to your distribution
And the reply:
> but you could create your own .deb packages for each github release, which can be installed much quicker than downloading and compiling source code and all its dependencies.
This is why OSS maintainers have burn out. Always wanting more and more. Not even the source code is good enough.
My point is that it's not good enough to compete in this space.
Look at the distros that Docker supports. That kind of support is what users expect. When Podman just leaves it up to the distros to support, it's understandable. But, yes, it's not enough.
> That kind of support is what users expect.
Then they should also expect enshittification and rug-pulls when it's realised where motivation for that support comes from.
That's a you problem. Either use a rolling distro like Gentoo or Arch or learn to install software from source code yourself (it's not hard).
We both disagree with rsyring but I disagree with you even more! :D
Installing from source code is hard! There's always some broken dependencies and these days I just cba.
I'd sooner go complain on the internet than install a thing from the source code!
And only one of those solves the problem.
that's a really bad stance... nothing wrong with compiling from source
See my comment at: https://news.ycombinator.com/item?id=48785731
You're running an LTS release first released in 2024. What exactly did you expect was going to happen?
See my comment at https://news.ycombinator.com/item?id=48785731
a.k.a. the most recent stable LTS, which will be succeeded by 26.04.1. Unless your hardware doesn't work on 24.04.4, I would not upgrade to 26.04 yet, unless you enjoy unexpected behavior in the console.
One thing I don't like about Podman is that it pretends to be docker-compatible while having some minor differences that will come to bite you. And users of your docker-based project who try to run it on Podman will come to you and complain.
I've found most of the differences to come not from the socket API, or the logical behavior, or CLI differences. But instead from assumptions Docker makes, that it's running rootful, when Podman will not (by default).
As such, most of the fixes for Podman/Docker incompatibilities is just addressing that assumption with a few extra flags on the Podman commands to change how the user namespace maps between the container and the host, etc etc.
This has been my experience too. And that conclusion, I've found that if I really don't want to deal with such quirks, I can indeed literally just run the same docker compose file in rootful mode, and it works.
Making the changes required to run under rootless is often very simple.
There are also different CLI flags (I recall something related to building and pushing multi-arch containers) and different features supported in compose.yml. Even rootful Podman won't be fully Docker-compatible.
My #1 complaint by far is that it --- pretty much silently --- depends on systemd to work correctly.
Try having a docker-compose with a service that waits until a dependency is healthy --- in a host that has no systemd (such as Alpine Linux).
The service will never start because Podman relies on systemd (and only systemd) to do the periodic healthchecks which it needs to do in order to handle such dependencies.
And of course, this fact isn't adequately documented anywhere. And Red Hat says they'll never, ever drop this dependency.
---
But I don't know if there are any tools compatible with the Docker ecosystem other than Podman. I'd love to find one.
Yeah that's an unfortunate downside of the daemon-less design. Service management (like dependencies, health checks, etc) are outsourced to systemd since there's nothing locally available to monitor them. The fact that the documentation doesn't mention this is a major miss.
For anyone curious, there's more details on why this is tricky to do with Podman at https://github.com/podman-container-tools/podman/pull/27033 .
On macOS, there's Orbstack, which is ridiculously compatible (I believe it's based on the same moby engine underneath). On Linux there's oodles of options for working with OCI containers, but nothing else I know of that's compatible with the docker API or CLI.
I've been using Podman on Mac and Linux for 3 years, and unfortunately, I have found this to be perennially true. I am willing to doggedly pursue the root cause and file bugs, but for many people it will just seem broken.
Most recently: Netavark doesn't match Docker's behavior with accepting broadcast traffic on a published port.
Yes! It put me off Podman for years. I do now think it has some clever ideas and if you’re running RHEL it’s a no brainer, but they should be more upfront that you will have to adapt. Especially if you’re moving from rootful docker to rootless Podman.
Anyone have experience switching from Docker to Podman?
I have a lot of compose files in my homelab/automation setup and those are what I’m most concerned about.
We moved from docker to podman about 15 months ago, and I'm never going back. I (personally) love the quadlet (read: systemd) integration, that makes it so much easier to monitor a set of running services, be they regular systemd services or containers. Running rootless is as straightforward as it gets and on top of it, podman is blazingly fast. I, personally, don't miss docker compose all that much, but I understand if the lack of docker compose is a showstopper for others. I've never tried podman's compose plugin.
The one big reason I dread giving up compose files is that they're a great way to have system agnostic documentation on how to setup a new stack. That means every developer can just start the thing locally, and it's pretty much the same as on the server (and everyone elses laptop).
Podman doesn't officially support any thing platform agnostic. How do you (or anyone) deal with this for a project in active development?
podman can work with kube files, which is the YAML format from Kubernetes. That's more "platform agnostic" than docker-compose. And it can be read as a documentation in the same way.
Kubernetes isn’t a great example of you can just read it like a document. The resource kind jargon is huge.
Most compose files are small and use familiar linux jargon.
I can give an non-dev IT person a compose file and they can understand every key. I can’t do that with K8s or Quadlet.
You don't have to learn much resource jargon for a quadlet, just the Pod type, and a relatively small subset of it at that (you're not going to be using things like selectors or priority classes). And there's a script that can convert a compose file to a quadlet, so you don't have to do it from scratch.
I use podman and almost exclusively start containers using podman compose. Haven't noticed any issues after migrating from docker.
I switched from a giant docker compose file to podman quadlets on my homelab. IIRC it look me a little while to translate the first couple of services because there wasn't (at the time, at least) as much documentation/examples of quadlets as compose files, but after that it was a piece of cake. I highly recommend them.
The only issue I have is validation, there isn't a convenient built-in command to validate quadlet files and systemd doesn't warn you if any fail to generate. You either have to do a --dry-run first (and probably alias the full command to something reasonable) or check the journal for errors.
Swapped a few years back (pre 5.0), haven't looked back. For compose files I'd look into using quadlets.
For quick conversions you can use compose files directly with podman-compose or docker compose pointed at the podman socket[0].
There's also podlet[1] which converts compose files into native quadlets. It does a pretty good job of taking care of everything for you and for a lot of simple to medium complexity compose files it will Just Work. There's talk of making it into a library of some kind so other tools can transparently convert compose files to quadlets so hopefully we'll see more stuff like it.
Otherwise, writing your own Quadlet files isn't too hard if you're at all familiar with systemd unit files. Most `docker run` or `podman run` arguments have direct quadlet conversions so once you get used to the INI format versus yaml it's pretty easy to see a compose file and churn out the equivalent quadlet(s).
[0] https://www.redhat.com/en/blog/podman-docker-compose
[1] https://github.com/containers/podlet
I switched everything over to rootless podman a year or two back. Some containers ended up with permissions issues when trying to read their old data - caused by being run with a different UID. This was really the only problem I ran into, but I would have had the same issue switching from rootful docker to rootless docker.
Absolutely zero regrets, would never go back.
I moved in 2021.
Others have pointed out that you can use podman-compose or docker-compose pointed at podman. I did something different: I switched to using systemd to manage all my containers. It was worthwhile as I can just use my usual systemctl and journalctl utilities for both containerized and non-containerized services rather than having to remember two sets of commands.
I only experienced one minor issue with pasta (used by podman) with networking, but by then I had fully committed to podman so I did not even try to see whether I would have had this same issue if I were using docker.
I have switched on production and QA servers. I used AI tools to help with the migration. Easy peasy. On the desktop, I am still using docker. Old habits die hard. Eventually I plan to switch on the desktop as well.
I've been coding solutions against each. I'm currently having issues extracting progress from the current Podman on my TUI build pane, but now switching versions to see if it addresses it and continue working the issue.
I have zero issues with it doing the builds I need. Works same same as Docker from what I can tell.
I took Docker completely off my Macbook which has a tiny drive in it. Hardly ever use it, except for testing. Podman is super lightweight and using a project I'm developing, launches containers with dev agents in it, just the same as Windows running Docker.
I set up my stuff as all Podman when I moved from a VPS to my home server and it's been pretty simple. I didn't use any of the compose functionality because I have a single DBMS of each type and just have multiple DBs on them etc. and I use podman through the systemd quadlet system. Honestly, it's been pretty flawless.
Would be great to know if I can uninstall docker on Mac and just install https://github.com/containers/podman/releases and be good to go with my docker compose files ?!
I have the feeling the docker company is communicating a lot with Apple because virtualisation got better and better over the years. I wonder if podman would be a speed downgrade here?
> I wonder if podman would be a speed downgrade here?
Doubtful. But for sure it would be a compatibility downgrade. When I tried podman-compose a couple years ago, I found it nowhere near usable, though I'm told it's improved since. If you want a better Docker for mac, you're looking for OrbStack.
I switched a few years back and use Quadlets instead of compose now. Converting compose files to Quadlets is pretty mechanical once you get the hang of it.
Highly recommend Podman overall; there are some quirky edge cases, but for the most part it’s a smooth replacement for Docker.
If you don’t want to give up compose entirely, podman-compose exists. I just prefer Quadlets so I haven’t used it much myself.
Do you have a good canonical source on this conversion? I’ve tried the conversion tools that came out around the release of podman v4 and again with v5. But somehow the files being generated contained deprecated features which pointed me to use different commands which led me to yet again different structures which when executed in systemd brought me back to what I originally had. I never got it to work fully.
Have you tried podlet[0]? Not entirely sure if it's compatible with podman v6 [0] https://github.com/containers/podlet
Yes. I think podlet was one of the tools that the output of podman, or the quadlet tool, suggested I use.
I will try again. Currently I have a systemd service that tries to start my services with `podman compose `. Sometimes this fails, when I start the service interactively it just works. Unknown what exactly is the issue.
podman-compose has gotten much better. I used it for a work project a few months ago, and it ran fine. That said, I know there are some random little things podman-compose doesn't support, so be careful.
What I'm experimenting with right now is defining stuff with a Kubernetes yaml, which podman also supports: https://docs.podman.io/en/latest/markdown/podman-kube.1.html.
It's slightly more verbose than docker-compose, but podman supports it natively and you can actually wrap your app containers into a single "pod" for easier management.
I switched from Docker to rootless Podman for our build server. Completely positive experience so far. Our builds went _down_ from 1 minute to 2 seconds.
I'm also using podman-compose that is small and delightful (I had to fix a few bugs there). It's just one Python file that you can copy.
> Our builds went _down_ from 1 minute to 2 seconds.
Just curious, what might be the cause of such speedup?
The biggest differences for me were related to non trivial network setups. Is just that you find docs and how tos for docker, but less so for podman.
Other than that, I haven't found anything that makes me consider using docker again.
Switching quickly turns into "Here is a list of 10 easy steps..."
For anyone with a working homelab there is no reason to switch
If you're worried about security, both need extra work
Good for the most part, I appreciate them being pretty much a drop in replacement (mostly so tools that reference docker can just work usually).
Regardless it works enough for me to run local Kubernetes and Tilt
I have a few containers at home and switched to podman, it was a pleasant surprise to see how how easy it was to drop it in as a replacement.
In our shop, I wasn't one of those who knew Docker in and out, got just enough into it I could containerise applications we needed to have containerised, which was of a modest scope -- no crazy networking setup that required bleeding edge or anything like that. Anyway, after only a few months into Docker, organisation announced migration to Podman across the board. Initial impressions were soured by, ironically, poor out-of-the-box installation experience _on Red Hat Enterprise Linux_ (which we run everywhere where Linux is used) -- getting `podman` to do much of anything useful in the "rootless" mode matched the typical anecdotal evidence requiring a bunch of incancations you may or may not understand fully, as RHEL itself wasn't ready for the package, apparently. That was in 2024 though, and it rapidly got better after that. These days I have all but forgotten we used to use `docker` but use `podman` instead, but then again I have had to learn plenty enough about at least the latter -- enough I am able to navigate problems better than earlier (what with UID/GID mapping, for example -- which too had to be done manually occasionally when we first transitioned).
There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).
We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)
Yes. 99% of things just worked, zero modifications.
The few cases where something was not directly translatable was <10 minutes with a coding agent to make some minor config changes, and then it just worked.
For me, I'm as grateful for Podman as I am for git.
Podman has been mature and sane. In cases where $someone's container depends on su privs, I blame the $someone, not Podman.
Any experiences running k3d on podman? It's my daily provider of local kubernetes.
What I have observed through my limited experience, primarily testing docker-based development env setups in podman, is that it's usually not a straight swap.
Yeah pretty much no big issues in moving over. Even ctop works for which I really wish there was a replacement since it's not updated anymore.
Not a power user but compatibility has been excellent.
You don't have to fully switch. I use podman in socket mode with the docker cli as a frontend.
> You don't have to fully switch
Having a heterogenous fleet can be annoying though, some Podman-only config values[1] stop Docker dead in its tracks because it hates unknown fields.
1. It was a while back, and I can't remember what specific field it was, but it had to do with namespacing and/or (sub)UID mapping.
I can imagine that but I don't have those issues with the default config. So it allows using docker compose with podman directly.
On the other hand I could see it being hard for people to only install the cli part of docker. Luckily on arch that was simple due to how it's packaged.
I mean I should probably also say it’s good enough that Bazzite ships with it enabled (not something I’d have expected)
Sic an AI cli on a copy of it. They take care of that stuff pretty easily.
Cool, been running my home server on podman + quadlets for about two years now and picked up a couple of things in the release notes
Added in v5.6.0, lists quadlets and their containers Flag added in v5.8.0. I remember seeing the bolt db deprecation warnings in the past but there was no tool to do the migration to sqlite, now there is (or just upgrade to podman 6.0.0 and it will do it automatically)No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation.
The new network stuff is a welcome improvement.
I’d wager it’s mainly just that deployment is mildly more annoying and requires more disparate steps.
Especially if you want to go rootless (and you should).
For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat intimidating when compared to just installing docker, whipping up a docker compose file and pressing “start”.
I understand why they’ve taken this approach but it’s pretty clunky and a bit unfriendly.
It's not just mildly annoying, it completely ruins a great thing.
Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose, but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.
I genuinely don't understand how someone can see the value of Docker, but then do things so completely "not-docker" when it comes to deployment/stacks/orchestration.
> but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.
To nit pick slightly, it's not really a bespoke mechanism it's just re-using the mechanisms provided by systemd. Quadlets are implemented as a systemd generator in order to re-use the existing service management system that exists on essentially all major Linux distros. Quadlets are less a direct competitor with compose (hence why Podman implements the compose spec) and more a way to better integrate containers with the rest of a system. The closer Podman native equivalent to compose is Kube files.
Depends on your point of view.
It can be argued that it’s Docker that is reinventing the wheel and doing its own bespoke process management, journal management etc when all of these are solved problems on Linux. Podman is instead reusing the platform which exists, Quadlets are just reusing systemd, so as a sysadmin I can manage, control and monitor docker containers using the same standard tooling that I already use to manage, control and monitor all the other processes which are running on the system.
Architecturally I find the above argument attractive. The problem is chronology. Docker and docker compose came before systems was ubiquitous and long before Quadlets, so it’s natural to think of Quadlets as reinventing the wheel.
Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.
> Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.
It also would have only run on Linux hosts (and not all of those at that), so something else would have been adopted instead. Docker didn't win by being superior to every alternative, it won by being good enough and being everywhere. For portable orchestration, Desktop does ship with kubernetes that's literally one click to enable.
> Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose
This isn't (completely) true. I found podman-compose to be a more or less drop-in replacement for docker-compose. I know that in the past support was patchy, but things are rather good now.
Pretty sure that's because podman-compose literally calls docker-compose under the hood.
e: from the manpage:
"podman compose is a thin wrapper around an external compose provider such as docker-compose or podman-compose. This means that podman compose is executing another tool that implements the compose functionality but sets up the environment in a way to let the compose provider communicate transparently with the local Podman socket. The specified options as well as the command and argument are passed directly to the compose provider."
That's the "podman compose" wrapper command. podman-compose (the implementation referenced in the first sentence of your quote) does not call docker-compose: https://github.com/containers/podman-compose
it calls podman-compose or docker-compose depending on what is installed...
this is literally what manpage you quoted says too
FWIW, for me docker compose works just fine with podman. I am not sure what kind of additional configuration is needed these days, make sure you are running podman with the socket thing and perhaps set DOCKER_HOST. It's just a client / frontend to an API that podman provides.
IIRC `podman compose` can invoke either `podman-compose` or `docker-compose` and sets up the environment for the call, so I don't think you need to even really do anything special other than install either of the 2 commands
The purpose of quadlets is when you want good integration with systemd.
The better equivalent of docker compose is podman kube, which does use a single file. And it isn't bespoke, it uses the same format as kunernetes.
And if you prefer the docker compose format, podman-compose is available as a separate tool.
And FWIW docker compose is a separate tool from docker itself as well (and needs to be installed separately on several linux distros). And can actually work with podman instead of docker.
Have you try podman-compose ?
> the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts
Podman does not require systemd (thank God). I use a simple podman compose up/down in a user systemd file to automatically bring my containers up at boot, but other mechanisms are possible, like quadlets and init scripts.
Quadlets are awesome and honestly I think one of the best additive things that podman has on top of the regular docker toolset.
I use podman regularly, and despite it being a good drop-in replacement like 95% of the time, the 5% of the time where it isn't seamless are super painful. For example, skaffold (https://skaffold.dev/) pukes all over itself when you try to run podman as a drop in replacement. I'm sure there are plenty of other examples, but that one stops me from using podman at work in addition to in my personal projects.
Well, but that's kinda the point, isn't it? You know that other mechanisms are possible, but you opted out for a user systemd file. I know that too, and I also just use systemd for that. Because the alternative doesn't look much easier. I guess it makes sense that they try to discourage it now, because for serious deployment it isn't the best option. But when I install Podman on my laptop, I really wish the systemd configs would be added automatically without me even knowing.
I mean, really, if we keep in mind that formally these are 2 totally unrelated projects, it's hard to complain. Yes, it's almost seamless. But since when installing Podman everyone thinks roughly "I am installing a newer better Docker version", and we all already have a few dozens of custom Docker containers running, it's hard no to wish it was even more seamless and backwards-compatible. I remember the transition process wasn't nearly as smooth as I hoped, and every small glitch is kinda stressful, because you know that currently all of it "somehow works", and if something breaks you probably won't even notice right away.
Are we talking windows here? On Linux and Mac I believe you can install Podman via a package manager like anything else.
Linux. It’s not the installation of podman that can be fiddly. It’s the setting up systemd unit files and local user accounts for rootless / daemonless deployment of containerized apps that can be a headache.
It’s not hard. It’s just fiddly.
> It’s just fiddly.
You could quite simply have a systemd file that calls podman compose up when the service starts and podman compose down when it stops. Basically the same systemd file for every container stack defined in a single compose.yml. It's extremely easy, and does not do stuff behind your back like Docker (such as silently altering iptables rules).
Sure. But that wasn’t OP’s question.
The question was why Podman doesn’t have the adoption levels that Docker does, and my supposition was that (for those that don’t have much Linux administration experience) added steps like systems configs, or quadlets etc are just another barrier to entry that you don’t have with Docker.
I’m not arguing that Docker is better (I think Podman wins in a lot of ways actually) just that Podman requires a bit of extra work to implement well and that is just enough of an annoyance to tip the scales towards Docker.
I think it's just because Docker came before. Podman is more secure and architecturally cleaner, but not touching something that works is an equally good reason not to migrate.
You can just run podman containers as root if you don’t want the fiddllyness of user accounts - it’s no less secure than rootful Docker.
It might not be the popular way here in HN but nowadays I just ask llm to create required configuration files and everything is so easy. Of course you need to review them but tbh no more headaches at least with config files.
Doesn't quadlet fix some or all of those problems? It's supposed to allow you to convert podman containers to systemd unit files automatically
> Doesn't quadlet fix some or all of those problems?
It definitely can solve some of those problems, and that’s the approach I’d generally recommend.
But to answer OP’s question - my supposition was that the mere fact that such a device is even necessary (when compared to docker) is an added work that isn’t obviously easy to implement for someone who is just trying to learn how to containerize their app (and might be a developer but not that experienced with Linux administration) and this one of the main reasons Podman isn’t as popular as Docker.
I think Podman is better in a number of ways, but it isn’t the most intuitive to implement compared to Docker.
Its not only intimidating, its clunky and error-prone. That's the answer to OP's question, this podman thing does not have good UX story.
Or, to look at it another way, the answer is that it’s the developers who don’t want to learn something new that, objectively speaking, might turn out to be better than what they’re used to.
I think it’s probably correct strategy wise to just “do the right thing”
They’re essentially long junior devs asking Claude to set up podman
I use podman on my local dev machine and I don't touch any system-d files for that
I gave up on Podman for some minor reasons: one was that they decided to deviate from Docker and handle SELinux differently, which required effort to change the SELinux security labels on a stock Centos system. That made it a no go.
The other issue is minor differences from Docker, but small enough that a packaged up Docker compose doesn’t work out of the box. It’s not a good use of my time to debug that when I could just switch to Docker, have it work, and get on with my day.
Can you elaborate on SELinux? It affected me too but I just had to add :Z to my mount argument. Curious about whether there's further impact I'm unaware of.
This is my biggest gripe. If you're using docker-compose.yml on a team that mostly uses docker, you can't use use that same docker-compose.yml with rootless podman. Any volume mounts that need to be writable (like the app, or databases) need to have `:X` or `:x` as a suffix, or podman won't set the SELinux label correctly to make it writable. But if you add those, docker blows up because it doesn't understand them.
I've recently been using podman on SELinux... :Z and :z seem to work fine across both podman and docker for writeable volumes. Am I missing something?
There were other problems although it’s been a few years so I’ve forgotten them. I think the container I had trouble with Ory Kratos. We did eventually get it to work but had to change the sample docker deployment a fair bit.
macOS had a seperate set of problems. I ended up just going with buildx and Colima on macOS. (We don’t use Docker Desktop.)
Long term I’d like to try to switch to podman again, but it needs to have a “be 100% compatible with Docker” mode as opposed to this:
https://github.com/podman-container-tools/podman/issues/1478...
> have it work, and get on with my day.
And usability continues for being security’s number one enemy...
> on a stock Centos system
Either an old experience you had, or a newer experience you had on vastly out of date packages and probably podman itself?
CentOS comes with SELinux on by default.
CentOS is very old and very out of date now. Unless you're using stream, which I haven't followed along with that at all. Podman is on v6 now, after all. A lot of systemd changes have also happened since.
Last time I checked podman compose was only a superficial docker compose equivalent. Also stuff like inotify seems to randomly break a lot on the podman side.
I'd love to be able to recommend people use podman but not having a good docker compose compatibility and missing inotify on volumes makes the DX just too problematic.
You can use actual docker-compose with podman, the -compose projects are separate from podman/docker.
podman-compose never worked well for me but docker-compose on podman did.
The CLI plugin or the script? Last time I checked the podman CLI did not support docker CLI plugins and the script is EOL since years.
Podman has supported plugin compose (v2) for years now, and I believe that's the version I used before I switched to Quadlets, but I must have not needed Buildkit features back then because those are apparently still unsupported over v2.
> for years
Don't know about that. I did a ddg search "using docker compose (v2) plugin with podman" I do get some tutorials but they all are from 2026. This also aligns with my experience from late 2024 where you where typical advised to use `podman compose` or the compose script.
Here's the 2022 release announcement for Podman 4.1 claiming support for compose v2. Your distro may have been stuck with an older Podman version for much longer though.
https://podman.io/release/2022/05/09/podman-release-v4.1.0
docker-compose (v1) is obsolete. The new version (v2) is a plugin for the docker CLI.
See my answer to your sibling comment. Podman supports v2 but not with Buildkit.
Check again? I don't have any issues like this and use podman compose in prod.
I spent about a week last year trying to move from docker+compose plugin to a podman hosted variant. It has issues on multiple stages of the lifecycle as I mentioned in my original comment. Mac users lose fs events, a lot of compose.yml features are flaky (post start events), buggy (reset and import), or just not implemented (don't remember the exact features).
If you use podman and have no issues that is awesome but your use case is probably quite narrow, you are most probably on a non fedora based Linux and keep compose usage to a minimum.
It was a pain when i tried it like 5 years ago for what it’s worth.
I think a stronger brand name. Also on macOS I found Docker Desktop to be more straightforward. Also lately it has been very error prone. Randomly failing at mounting files, or cleaning up networking rules, or suddenly becoming bog slow so I have to restart the VM.
Podman on macOS feels miles less refined. Orbstack is a way better choice.
I only use podman on Linux and there it is blazing fast. Even so, most features seem to be geared to be able to replace kubernetes in combination with systemd. And then something simple as docker compose support is flaky and it’s TUI/ux lags behind the original.
I like OrbStack for macOS, much faster.
Now that Apple has containerization api’s probably the gap closed but when I ran benchmarks a couple years ago Orbstack would on average perform the same build at 4x faster wall clock time as docker desktop
Build as in building images or as in building a project when mounted in a container? I notice 3-4x performance degradation of our maven builds in containers. With golang I haven’t noticed much performance degradation, but that may be because it is fast enough anyway.
One advantage of Docker is reliable host-to-container file change notifications, allowing tools like Vite inside the container to detect changes. Podman and many alternatives don’t handle this well for our web development on macOS.
Not even Tart or Apple Container support it, as far as I know. Maybe someone has found a way.
> don’t handle this well for our web development on macOS
In general this seems to be a common complaint here. If you're developing with cloud runners or on linux infra you won't run into this, but on macOS for local development it is impactful.
Thats a use-case I never tried but seems valid. Is it a common issue on macOS?
Yeah, it doesn't work with Apple Containers.
Works with OrbStack though.
Just today, I tried to run docker compose on a remote host via podman-docker on Fedora (Asahi). I ran into all sorts of buildx issues, and the easiest fix for me was to remove podman and install docker instead.
I tried working through it with Claude, but after a few failed attempts I gave up. I'd like to use podman, but the docker compose + buildx compatibility gaps made it more trouble than it was worth for now. I'm definitely going to try it again.
If you want podman equivalents, you can either use pods of multi containers are the need, or if multi arch builds are the main buildx need, OCI manifests work.
Fedora and selinux may be a thing to look into if you were trying to share volumes.
I am posting this from a park on my phone, so this may be slightly wrong, but this is the multiarch case that seems to be harder to find for many people.
All depends on your needs, but even with docker I prefer moving forward with OCI when possible, preferring standards to product specific workflows.Last time I evaluated podman, Ubuntu was second class citizen. Rootless was non trivial and required additional setup. Documentation also suck.
Docker is something we all already hate, milion edge cases and forever bugs but at least well documented and understood. Podman claim to be drop-in replacement does it mean it carry docker shitness? Examples: ufw punch through, env file handling, volumes, etc
Last time I tried rootless podman was about 6 months ago and it was a total mess. I was trying to use it to run a container as me (user 1000) and mount a directory from my home (owned by user 1000) and it drove me and Claude around the bend. It's not a podman vs docker thing per se, just rootless being a total pain. However I just enabled the docker service, ran the same command on docker and it worked. I think I just left docker running after that. I realised that on my home setup I don't care enough to fight with it. Sometimes you just want to do the thing you want to do and not turn it into a 4 hour learning session about some side shit.
Try without Claude. Happy rootless podman user since October. It just works.
Had similar issues with podman on a Steam Deck of mine that I use as a little home server - eventually got a configuration working fine but was a real pain.
With recent advances in both systemd and podman a lot of this is basically a non-issue.
Documentation has also gotten better.
For tools that require docker to work, like testcontainers and tilt, I've found some annoyances using podman, but ultimately I've been able to work around them.
For everything else, it's pretty much a drop in replacement.
They should better manage expectations. They put rootless as a forefront before it was ready and still no proper support for Ubuntu on v4 of Podman.
[1] https://github.com/podman-container-tools/podman/discussions...
When have you tryed ? I have installed podman in Debian with a sudo apt install podman and I didn't to do anything special. It's rootless by default.
One of the key design principles of podman was rootless operation; they were so disgusted by Docker being a daemon they decided to do a full open source implementation. I've never had an issue with it running without root.
Most people simply do not care. They just want a Dockerfile to become an image, and they want to run that image. I use both... rootless podman is nice. Although the promise of ez systemd integration is a bit... oversold. I use it with systemd however with my own hand-crafted unit files. Pretty good combo.
In many places it doesn't matter, because cheap companies don't want to even hear about Docker, so one gets to choose between podman, rancher, and if on Windows wslc is going to be a thing.
Docker (the company) lost the plot in Linux containers, OCI got standardized, alternative runtimes came to be, and very few companies actually care to pay for Docker Desktop or the other services they sell.
Docker CLI is free for commercial use, it's only docker desktop you have to pay for
I know, but companies legal or IT department make it easier, no docker of any kind being installed from https://www.docker.com.
Microsoft also is finally adding their own docker cli (wslc), due to having had enough pressure that many companies don't want to instal third party tools for Linux/Windows containers, even if API is compatible with docker daemon.
Apple is doing a similar approach on top of their virtualisation framework.
I ran into an issue I couldn't figure out how to solve with podman. Some of the testcontainers my test suites would run wouldn't start in time causing tests to fail locally. Switching back to docker desktop solved the problem.
This except in production. Nothing helped. I actually stopped using containers for a bit after that.
I went all in on podman compose last year but went all back because off constant permission errors. I thought it was going to be better than docker because I run the containers as a user… but man the amount of time I wasted on files that either I or the container itself or some other container couldn’t read… With docker I felt that stuff just works.
And then there are the extra steps: Enable user lingering, make a systemd service that starts the compose containers (and there is nothing really “native”, it’s a script.) With Docker compose containers just restart if you say so in the file.
There are many great things about podman, will try again in a year or so perhaps?
> I went all in on podman compose last year but went all back because off constant permission errors.
The issue is that "ease of use" and "it just works" come at the expensive of security and the principle of least privilege. Docker makes things easy by running a daemon as root. Rootless Podman forces you to think about permissions and does not stab you in the back by overwriting your firewall rules.
Yes, the firewall rule altering was what drove us to podman! Was kind of weird to find a container's Postgres wide open on 5432 after a `sudo ufw default deny`. Madness really.
But as said below, the permissions issues got to us.
what kind of stuff is in your compose?
Mostly self made containers, also one with Claude-code, but I couldn't for the life of me get it to be able to store and retrieve credentials in an externally mounted folder (~/.claude). I tried everything from fixing the user creation process in the container, `--userns=keep-id`, `--userns=keep-id:uid=1000,gid=1000`, several tags, :Z, :U, `chown`-ing after creation etc. And I keep running into that stuff.
I wish that "run podman containers as a user, rootless" would just simply mean: All the things are also the property of the user, but you get weird uid/guid combos and stuff on your filesystem as owners you never heard of (like www-data, but not that one in particular) due to the mismatches.
If containers can ever simply be run as user like they are a user process, that would be so nice.
I had to do some extra stuff for my containers, here's some info from a tutorial I wrote:
Following the Arch wiki:
# Dependencies `yay -S podman slirp4netns aardvark-dns`
# Setup podman-compose and the venv ``` python -m venv .venv source .venv/bin/activate pip3 install --user podman-compose ```
On WSL, you'll need to be on Debian bookworm or newer. Older versions of podman-compose for, ie, bullseye, do not work.
# Reserving alternate UIDs/GIDs `# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 username`
# Setup the storage configuration to overlay Create/edit the following file: `vim ~/.config/containers/storage.conf`
Add/edit the following line: ``` [storage] driver="overlay" ```
# Propagate changes to podman `$ podman system migrate`
# Bring the systems up `podman-compose up`
# I'm on WSL and it's not working (DNS issues)
Check if the network created by podman has dns enabled:
``` % podman network inspect $containername_default | grep dns "dns_enabled": true, ```
If it's false, install another dns resolver:
``` sudo apt install golang-github-containernetworking-plugin-dnsname ```
Then delete the network created by podman-compose:
`podman network rm $containername_default`
## Out of memory when running `podman-compose up`
This error may include "could not map anonymous shared memory".
If you're on a mac, try increasing the amount of memory the VM can use, eg:
https://stackoverflow.com/questions/70114200/increase-podman...
``` podman machine stop podman machine set --memory 4096 podman machine start ```
This will provide podman with 4GB of memory to work with when spawning containers.
https://gist.github.com/ijustlovemath/82b4fa31a7c745e87bac5f...
Thanx!
It's a lot of stuff to set up though, compared to disaster recovery instructions being: Install Docker, restore state from x, docker compose up -d.
I want it all "as code", this could certainly be automated (scripts, nix), but it would be nice if it really was as simple as one single compose file, that should be the goal, imho.
To be clear, all of that setup happens once on your host machine, then you never have to think about it again! You can compose to your heart's content. I think podman just doesn't want to commit to a particular DNS solution so they leave that decision to you.
Brand.
"OCI container" doesn't have same ring, unfortunately.
And most Podman things are just clones of Docker, e.g. Containerfile. In a clone situation, the original brand will always have the staying power.
Fuse overlayfs was noticeably slower than Docker's overlayfs setup. Maybe there's a way to reconfigure but I haven't checked lately.
I think it was Zig (building ghostty) was broken in podman with obscure "unknown file" errors. Turns out that was lack of fuse-overlayfs supporting some attributes it was trying to check.
It's random, little things like that which keep biting me every time I try to make the switch. I use it for simple stuff though.
Podman, including rootless podman, uses native overlays since Linux 5.11: https://github.com/torvalds/linux/commit/459c7c565ac36ba09ff...
it has a stronger brand, probably because it was created first. I still hear the term "docker container" (sometimes).
> sometimes
I've never interacted with anyone that knew them by another name. It's always (docker) container, where they may leave out the docker term, but if questioed what kind of container they mean theyll say it.
And the times I've called them OCI container (or image when talking about those) nobody knew what I meant until I clarified to docker
I hear occasionally Image Container, but even that is fundamentally docker flavored because when disambiguating for the term "image".
This comes up because we use both the Image and Package registries on Gitlab, so we sometimes have to absolutely specify, and the conversation lends to "The Docker Image one".
Because they don't publish up to date packages for major distros.
I never liked Docker, but someone pointed out to me that Podman is backwards compatible, doesn't need root, and even has simulated docker commands if you need them so you can just alias podman to docker... and voila same experience, so every online tutorial works just fine.
Default stickiness, tbh.
A few years ago, I started moving towards Podman when it got to that "good enough" point on both Linux and macOS and when Docker started to remind people about Docker Desktop that it needed a license for commercial use.
Even then, it took around a year or so to transition.
Isn't Docker is basically a front end to containerd, the most common k8s container runtime? One could just as well ask why use a completely separate container stack just for local development when docker shares the same business end as the prod environment.
I mean, one answer is that docker configuration on your local dev machine can go one of two ways:
1. You have to use `sudo` for every `docker ...` command; or
2. You add your user to the `docker` group and now anything that can run as your user can use docker to read or write any file on your system, making docker into the best local privilege escalation option out there.
You can also run docker in rootless mode.
Podman has some serious issues they are not really fixing, we ran into an issue where builds just hang for a few minutes before doing anything. So we had to switch back to using docker desktop locally for that.
> No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation.
docker-compose is one big reason. The networking aspect of it still isn't feature-compatible compared to using docker. I keep trying podman+docker-compose again every 6–9 month, and there's also some issue that makes it unfeasible for my use case.
Its IPv6 implementation is also broken, and connections from the host to the container are dropped if the host doesn't have a public IPv6 address (WTF!?). I reported this in June 2024 (#22959). Not being able to reach an HTTP server on a podman container from my host when I'm offline is ridiculous.
Lots and lots of tiny little bugs and quirks which are a nuisance to deal with. With docker, everything just works.
Another recent bug I hit was that the value of the environment variable TMPDIR and XDG_RUNTIME_DIR is persisted to disk with podman's internal state. After a reboot, if either of those has changed, nothing works because podman tries to use directories that don't exist. This… seems to be due to workarounds for wildly broken setups.
I've reported many of these bugs, and have a backlog of a lot more that I haven't bothered to report yet.
What honestly really surprises me is how many people actually manage to use podman for work despite all its issues.
Colima just seems to be easier to work with using Docker.
Devcontainers work without having to pass special arguments and deal with inconsistent stuff once in the devcontainer itself.
K3d is easier to work with Docker.
Docker locally just makes sense.
They really upset me with how they introduced it initially, and I haven't looked at it since.
Redhat swapped in podman and removed docker, and all of the config/images/scripts I had spend 2 years making stopped working on new/replacement hosts... So I had to spend a lot of time in meetings/filling out paperwork to get docker back. I haven't forgiven Redhat for dropping that shitty experience on my head.
For the company I work at, it’s primarily inertia. We started using containers with Docker. And then it just continued. We are two out of 20+ developers who would like to use Podman, but the rest is just ”eh, why bother?”. And I don’t fully fault them for holding that position, Docker generally works. Why switch to something which may or may not provide some benefit (most which will be indirect such as better security and setup)? I still continue to mention Podman regularly though …
You can use podman for your local environment because it's pretty much the same
Mostly but there are a few differences and that causes some friction
PaaS like render.com explicitly support Docker.
As a developer, I wager that any gains I get from Podman will be dwarfed by bugs that I’m encountering in the other software I use.
I’m not implying that Podman causes the bugs. I’m saying that I’ll be more likely to be the first person to encounter the bug.
This comment it's a bit weird, both podman and docker and render etc support dockerfile which is a standard way of packaging.
This was about a year ago, but I had trouble getting podman to add an nvidia GPU so that the container could use it. It was technically possible (I succeeded) but it was annoying and "different".
I used rancher + podman on Windows. Mainly Rancher. The last 8 months I use exclusively Podman + Podman Desktop. Rancher has a slightly better desktop app and can manage podman.
The average developer is much dumber than you think.
Yeah, a great developer I know showed me how he could use it to get a safe dev container for Claude Code, in a way that wasn't doable with Docker.
One answer is ECR/ECS/Fargate ie AWS. You’re not gonna split the ops stories between local and remote.
We need to popularize a "podman btw" meme based on the arch meme.
So any time people talk about docker someone can go:
I use podman btw
I hold that thought about RancherDesktop.
I mean for local dev I like that I can just press one button and have Kubernetes available. Podman Desktop had something approaching that simplicity but I have found Docker Desktop more stable in my limited experience with it.
Quadlets and rootless containers are two major reasons I'll be switching from Docker to Podman.
Rootless was the reason I switched to Podman years ago. It's just so smooth and I don't have to worry about obscure permissions and services errors anymore.
I administrate my home lab using podman desktop and quadlets. It is one of the few GUIs for what is mostly a cli utility that really adds value.
I like Podman, but what's up with that grey text colour? It looks ugly and the contrast of 4.96:1 makes it hard to read (does not reach WCAG AAA level).
How is Podman these days? I use OrbStack on macOS and it seems to be much faster, not sure how everything will shake out now that macOS 27 is adding (more) native and performant Linux containers, similar to WSL with micro-VMs.
I'm not sure about macOS, but it is seamless on Linux for my use cases. One thing to note is that Podman Compose defaults to docker-compose as the provider, and I haven't used the podman-compose provider (confusingly named slightly different to Podman Compose, which is the top level abstraction on top of docker-compose or podman-compose). You can still run containers through the Docker engine with Podman, if you need to.
Same question, same scenario. I tried it on MacOS, and the first issue I experienced (don’t recall what it was) had me deep into Redhat forums to even understand what was happening. Switching to OrbStack was a no-brainer, but there are obvious tradeoffs from a features perspective.
I doubled down on Podman when moving to Fedora a couple years ago- couple small hiccups but mostly my shallow knowledge on SELinux and bind mounts. Big fan, especially quadlets + stow on my homelab- thanks Podman people!
Sanctuary! mercy from grey font
Agreed. My first thought after that page loaded was, "why is this page harder to read?"
You've come to the wrong website to complain about contrast issues, my friend.
? HN’s contrast is great. It’s black on a light yellow-beige.
SO much of the text of a comment thread is not black, though. The line above each comment is gray. Downvoted comments are various shades of gray. The "help" link next to the comment box is gray.
I've seen worse, but gray on beige is not my favorite.
Please tell me you are being sarcastic.
Shift-Cmd-R Reader Mode if on Mac
I think you mean in Safari?
also serif. almost like half the stylesheet is missing.
If any Podman engineers are here: does the new /libpod/local/artifacts/add endpoint let me ingest individual layers? I have an alternative pull client that's currently a little hamstrung on Podman compared to docker+containerd, due to having to convert the entire image to tarball to ingest rather than only new layers.
Does anyone have experience with using podman image builds for cri runtimes other than docker?
If I build an image with podman will it run in cri-o, docker and other misc runtimes?
Been debating on using rootless podman for building images since docker build requires sudo and it gets annoying with agentic workflows.
I wanted to love Podman, but unfortunately, in my current employer's we have macOS machines.
I had issues like when Podman randomly stopped responding and I had to "kill" the podman machine more than once or some container randomly built differently or failed (due to architecture diff).
This was not the case with Orbstack, but they are license-only, closed source and macOS only oriented.
I wish I could find a consistently good container management system that is multiplatform, ideally open source as well.
Having said this, I think I will try Podman (6.0) again, in macOS :)
It is a bit buried, but Podman now follows the UAPI Configuration Files Specification as well as the Base Directory Specification. This is great!
Top of my list as to why I prefer podman...
no "container root" / "docker group" = "host root" shenanigans
podman doesn't spew garbage and punch holes in my firewall (iptables)
(edit: formatting)
> podman doesn't spew garbage and punch holes in my firewall (iptables)
The way Docker silently rewrites iptables rules is just insane. It boggles my mind that someone thought that it would be a good idea, and that it survived a peer review.
It was a major contributor to why I didn't learn more about containers earlier on.
podman's been great for me on macOS for testing stuff quick; which earlier used to need a whole limactl[3]/virt thing.
you can set it up with qemu-user-static for --platform linux/amd64; i don't remember which i exactly used, or if official docs have been updated for it but looked something like [1]
there is one sneaky bug in qemu that breaks uv [2] for cross-platform targets so i keep having to fall back to lima for that, but great otherwise.
[1]: https://www.itix.fr/blog/qemu-user-static-with-podman/ [2]: https://github.com/astral-sh/uv/issues/16024 , https://gitlab.com/qemu-project/qemu/-/work_items/3130 [3]: https://lima-vm.io/
I'd love to switch to Podman but I use Coolify for all of my deployments and it is Docker based, so I am kind of locked into that ecosystem for now
There is the podman-docker package that seamlessly emulates docker using podman. Eg for Arch Linux https://archlinux.org/packages/extra/x86_64/podman-docker/
How my mindset changed :
- What's Docker?
- wow Docker is so convenient
- hmmm all that convenience is creating new problems
- is Docker really open?
- What's Podman?
- Ugh Podman is a great idea but does not work
- Is Podman working better now?
- ... kinda, just for testing on my machine
- wow... Podman works just as well as Docker in 99.99% of my cases
... so yes except for the last .01% (e.g. rather niche https://github.com/containers/podman-compose/issues/792 ) is now my default container engine.
I love the naming of their new networking tools. Now there's pesto to go along with pasta
Does it still completely screw up file/group owners in user containers? Because they keep saying it gets fixed and then that 1 out of 10 times it's not.
single-file quadlets go
[flagged]
I don't understand how podman can be used for serious development work. Sure, if you want to be bound to one single platform (linux), and create a bunch of individual files, you can sort of get something a little bit like compose.
But the beauty of compose is the same as the beauty of the Dockerfile. Portability, reproducibility (mostly), and a single readable file with all the relevant parts. It means a developer can use the same compose file locally that's used for deployment.
How do people actually work with podman? Do you work with a team? How do you setup a local development stack the way you would with compose?
Podman can run compose - either its own, or docker-compose if you tell Podman to listen on the docker socket.
I use Podman on both macos and Windows, with compose files, so I'm a bit perplexed by this whole comment.
We have a consistent wsl image for everyone. So they are all on Linux. Then we have a podman pod defined in a bash script. We have a Justfile where you can run ‘just services’ and it all “just works (tm)”.
Once the pod is defined you can use ‘podman pod up/down’ to interact with it, but mostly we encourage people to use the Just recipes to do the things.
The thing is, podman has docker-compose like management built in, in the form of pods, but it doesn’t seem to be very well socialized.
On the server we use quartet+systemd and it’s great. Never had an issue with that part.
podman-compose is "mostly" compatible. I "plain" podman at work, but there we just have a bunch of shell scripts that spin up/down/build containers. For regular dev work, it's fine.
For personal stuff, I've been experimenting with podman's Kubernetes files: https://docs.podman.io/en/latest/markdown/podman-kube.1.html. Which, IMO, "feel" like docker-compose the most. You can run services via "podman kube play ..." and install them via quadlet install too.
I run podman for local dev containers or for isolated sandboxes mostly. Anything needing orchestration and I go straight to k8s, never liked docker compose.
> Sure, if you want to be bound to one single platform (linux)
Not a big deal if you are developing server software, as most servers nowadays are Linux.