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.
The new network stuff is a welcome improvement.
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.
They’re essentially long junior devs asking Claude to set up podman
It’s not hard. 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
this is literally what manpage you quoted says too
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 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.
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...
And usability continues for being security’s number one enemy...
Either an old experience you had, or a newer experience you had on vastly out of date packages and probably podman itself?
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.
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.
podman-compose never worked well for me but docker-compose on podman did.
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.
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.
Not even Tart or Apple Container support it, as far as I know. Maybe someone has found a way.
Works with OrbStack though.
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.
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.
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.
podman manifest create my-image:latest
podman build --platform linux/amd64 --manifest my-image:latest .
podman build --platform linux/arm64 --manifest my-image:latest .
podman manifest push my-custom-image:latest docker://docker.io/user/my-image:latest
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
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.
[1] https://github.com/podman-container-tools/podman/discussions...
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.
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.
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 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.
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...
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.
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.
But as said below, the permissions issues got to us.
"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.
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
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 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.
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.
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.
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.
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.
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.
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.
So any time people talk about docker someone can go:
I use podman btw