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 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

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...

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.

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.

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)

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.

Quadlets and rootless containers are two major reasons I'll be switching from Docker to Podman.

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 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

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 :)

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'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/

It is a bit buried, but Podman now follows the UAPI Configuration Files Specification as well as the Base Directory Specification. This is great!

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

I love the naming of their new networking tools. Now there's pesto to go along with pasta

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.

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

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.

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.

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.

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 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 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'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 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.

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.

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.

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.

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

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.

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

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.

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.

Any experiences running k3d on podman? It's my daily provider of local kubernetes.

You don't have to fully switch. I use podman in socket mode with the docker cli as a frontend.

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.

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.

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.

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.

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.

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.

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.

      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

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

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 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?

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.

it has a stronger brand, probably because it was created first. I still hear the term "docker container" (sometimes).

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.

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.

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 …

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 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.

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.

The average developer is much dumber than you think.

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.