HN Reader

The main issue is podman support on Ubuntu. Ubuntu ships outdated podman versions that don't work out of the box. So I use podman v5, GitHub actions uses podman v3, and my coworkers on Ubuntu use docker. So now my script must work with old podman, recent podman and docker

I also ditched docker when I could. In my experience...

Podman with pods is a better experience than docker-compose. It's easy to interactively create a pod and add containers to it. The containers ports will behave as if they were on the same machine. Then `podman generate kube` and you have a yaml file that you can run with `podman kube play`.

Rootless networking is very slow unless you install `passt`. With Debian, you probably should install every optional package that podman recommends.

The documentation is lacking. Officially, it's mostly man pages, with a few blog posts announcing features, though the posts are often out of date.

Podman with its docker socket is often compatible with Docker. Even docker-compose can (usually) work with podman. I've had a few failures, though.

Gitlab-runner can use podman instead of docker, but in this case the is no network aliases. So it's useless if the runner needs to orchestrate several images (e.g. code and db).

I really wish Docker didn't take over the industry like it has. In my experience not enough people know how to debug yet another layer of abstraction.

Remove layers, keep things simple.

That being said, it is here to stay. So any alternative tooling that forces Docker to get it's act together is welcome.

I've been on Podman for about two years now. My coworkers and the entire company codebase / scripts etc are on Docker.

Podman has a number of caveats that make it not a drop in replacement out of the box, but they are mostly few and far between. Once you've learned to recognize a handful of common issues, it's quite simple to migrate.

This might sound like me trying to explain away some of the shortcomings of podman, but honestly, from my point of view, podman does it better, and the workarounds and fixes I make to our scripts and code for podman are backwards compatible and I view them as improvements.

The "podman generate systemd" command from the article is deprecated. The alternative are Podman Quadlets, which are similar to (docker-)compose.yaml, but defined in systemd unit files.

Back in 2001/2002, I was charged with building a WiFi hotspot box. I was a fan of OpenBSD and wanted to slim down our deployment, which was running on Python, to avoid having to copy a ton of unnecessary files to the destination systems. I also wanted to avoid dependency-hell. Naturally, I turned to `chroot` and the jails concept.

My deployment code worked by running the software outside of the jail environment and monitoring the running processes using `ptrace` to see what files it was trying to open. The `ptrace` output generated a list of dependencies, which could then be copied to create a deployment package.

This worked brilliantly and kept our deployments small and immutable and somewhat immune to attack -- not that being attacked was a huge concern in 2001 as it is today. When Docker came along, I couldn't help but recall that early work and wonder whether anyone has done a similar thing to monitor file usage within Docker containers and trim them down to size after observing actual use.

I love podman, and, like others have said here, it does not always work with every container.

I often try to run something using podman, then find strange errors, then switch back to docker. Typically this is with some large container, like gitlab, which probably relies on the entirety of the history of docker and its quirks. When I build something myself, most of the time I can get it working under podman.

This situation where any random container does not work has forced me to spin up a VM under incus and run certain troublesome containers inside that. This isn't optimal, but keeps my sanity. I know incus now permits running docker containers and I wonder if you can swap in podman as a replacement. If I could run both at the same time, that would be magical and solve a lot of problems.

There definitely is no consistency regarding GPU access in the podman and docker commands and that is frustrating.

But, all in all, I would say I do prefer podman over docker and this article is worth reading. Rootless is a big deal.

To provide 1 contrary opinion to all the others saying they have a problem:

Podman rocks for me!

I find docker hard to use and full of pitfalls and podman isn't any worse. On the plus side, any company I work for doesn't have to worry about licences. Win win!

> If your Docker Compose workflow is overly complex, just convert it to Kubernetes YAML. We all use Kubernetes these days, so why even bother about this?

I find that kubernetes yaml are a lot more complex than docker compose. And while I do, no, not everybody uses kubernetes.

One challenge I have come across is mapping multi-UID containers to a single host user.

By default, root in the container maps to the user running the podman container on the host. Over the years, applications have adopted patterns where containers run as non-root users, for example www-data aka UID 33 (Debian) or just 1000. Those no longer map to your own user on the host, but subordinate IDs. I wish there was an easy way to just say "ALL container UIDs map to single host user". The uidmap and userns options did not work for me (crun has failed executing those containers).

I don’t see the use case for mapping to subordinate IDs. It means those files are orphaned on the host and do not belong to anyone, when used via volume mapping?

I've been dealing with setting up Podman for work over the last week or so, and I wouldn't wish that on my worst enemy.

If you use rootless Podman on a Redhat-derived distribution (which means Selinux), along with a non-root user in your container itself, you're in for a world of pain.

I've wanted to migrate multiple times. Unfortunately, it failed on multiple places.

Firstly, podman had a much worse performance compared to docker on my small cloud vps. Can't really go into details though.

Secondly, the development ecosystem isn't really fully there yet. Many tools utilizing Docker via its socket, fail to work reliably with podman. Either because the API differs or because of permission limitations. Sure, the tools could probably work around those limitations, but they haven't and podman isn't a direct 1:1 drop in replacement.

I may be the odd man out, but after getting unbelievably stressed out by containers, k8s, etc., I couldn't believe how zen just spinning up a new VPS and bootstrapping it with a bash script was. That combined with systemd scripts can get you relatively far without all of the (cognitive) overhead.

The best part? Whenever there's an "uh oh," you just SSH in to a box, patch it, and carry on about your business.

Podman networking is extremely unreliable. Our company made an effort to switch to get away from Docker Enterprise. We had to kill the effort because multiple people had random disconnects and packet drops with a range of services including K8S, Kafka, and even basic applications, both internal and in host network.

```

> kubectl port-forward svc/argocd-server -n argocd 8080:443

Forwarding from 127.0.0.1:8080 -> 8080

Forwarding from [::1]:8080 -> 8080

Handling connection for 8080

Handling connection for 8080

Handling connection for 8080

E0815 09:12:51.276801 27142 portforward.go:413] an error occurred forwarding 8080 -> 8080: error forwarding port 8080 to pod 87b32b48e6c729565b35ea0cefe9e25d8f0211cbefc0b63579e87a759d14c375, uid : failed to execute portforward in network namespace "/var/run/netns/cni-719d3bfa-0220-e841-bd35-fe159b48f11c": failed to connect to localhost:8080 inside namespace "87b32b48e6c729565b35ea0cefe9e25d8f0211cbefc0b63579e87a759d14c375", IPv4: dial tcp4 127.0.0.1:8080: connect: connection refused IPv6 dial tcp6 [::1]:8080: connect: connection refused

error: lost connection to pod

```

People had other issues also. It looks nice and I would love to use it, but it just currently isn't mature/stable enough.

If "security" is the reason you're switching to Podman, I have some bad news.

Linux gets a new privilege escalation exploit like once a month. If something would break out of the Docker daemon, it will break out of your own user account just fine. Using a non-root app does not make you secure, regardless of whatever containerization feature claims to add security in your own user namespace. On top of all that, Docker has a rootless mode. https://docs.docker.com/engine/security/rootless/

The only things that will make your system secure are 1) hardening every component in the entire system, or 2) virtualization. No containers are secure. That's why cloud providers all use mini-VMs to run customer containers (e.g. AWS Fargate) or force the customer to manage their own VMs that run the containers.

In the beginning, Docker DID have "standalone mode" where it would launch just one container as a child process. That was actually an easier way to manage the mounts and cgroups necessary to stand up a container. I made a ticket to bring it back after they removed it, and it was closed with a wontfix. The cynic in me says it was done more for commercial reasons (they wanted a more full featured daemon on the server doing things they could charge for) as opposed to just being a little shim that just did one thing.

Tried to migrate (M1 MBP) a couple of times and it wasn't working well resuting in reverting to docker...

Podman is really painful if you do anything interesting inside of a container, it's great and simple if all you're doing is running nginx or a scripting language runtime or something in a container, but for folks who write actual software that gets compiled to target a system and utilizes syscalls, running in Podman is a pain in the ass unless you disable most of the "benefits". Docker on the other hand pretty much just works.

Most of my containers end up on k8s clusters as pods. What else would one use podman or docker for beyond local dev or maybe running a local containerized service?

I would love to love Podman, but the fact that it regularly just fails to work on my Windows laptop (the WSL2 instance seems fine, but can't be connected to, the UI just says 'starting', and none of the menu options do anything) and that I can't figure out how to make IPv6 networking work on any platform means that Docker isn't going anywhere for the foreseeable future, I'm afraid...

Most projects only offer docker compose files and podman compose failed with too many of them contrary to developer claims.

I did not want the hassle of writing new quadlets for every project so I just went back to rootless Docker.

Also I believe the `podman generate systemd` mentioned in the article is now deprecated.

Author lists vulnerabilities of Docker, but it doesn't mean podman is more secure. Maybe it's more obscure so it is not as attractive for hackers as a target.

I tried to use podman, but that was largely a waste of time and I reverted to Docker. I don't have time going through docs to figure out why something that supposed to work is not working.

I use both Podman and Docker pretty regularly, and to be honest I don’t see a huge amount of differentiation or practical value in Podman for my day-to-day. It feels like another OCI runtime with some quirks compared to Docker.

One pain point for me is rootless mode: my Podman containers tend to stop randomly for no obvious reason. I tried the recommended “enable user lingering” fix and it didn’t help. I’ve never run into this with Docker.

I get the theoretical advantages, daemonless architecture, better systemd integration, rootless by default, podman generate kube, etc. But if you’re just using containers for development or straightforward deployments, Docker feels smoother and more reliable. Maybe if you’re in a security-sensitive environment or need tighter system integration Podman shines, but for my use cases I’m still not convinced.

I'm probably going to finally give podman a try, but apart from the security advantages of daemonless, I pretty much have all these features solved on my Docker hosts already. For home/lab workloads I define one docker compose project in a directory, using local path mounts for directories. Then I manually define a systemd service per docker compose project, which just runs "docker compose up -d <dir>" on start, and the opposite on stop. The hundreds of containers I run at home have higher uptime than the thousands of containers in the orchestration platform I run at work has.

Does the "podman generate kube" command just define pods, or does it support other K8s components such as services and ingresses?

I already use podman for local development. While docker can run under rootless mode [1] and alleviate the security concern. The concern about docker being resource intensive is still quite true (which is why I avoid using it in my self hosted setup).

Rather _declaratively_ define configuration with nix. Deploy nixOS to machines (rpi4/5, x86, arm) and vms (proxmox) and manage remotely with nixos-anywhere.

One of these days, I’ll get around to doing a write up.

[1] https://docs.docker.com/engine/security/rootless/

I'm interested in using podman for my homeserver because of the deamonless and rootlessnes nature, but I haven't found a convenient replacement for docker compose.

On my dev machine I do `docker compose up -d --build` in the directory of the Dockerfile, and it builds, uploads, and restarts the service on the server. In the podman world you're supposed to use Quadlets, which can be rsynced to the server, but I haven't found something simple for the build-step that doesn't involve an external registry or manually transferring the image.

What's the end-to-end solution for this?

I'm happily using podman only. Lightweight, secure by design, sweet integration with systemd as an orchestrator: a perfect middle ground when the complexity of k8s isn't needed.

Sadly "docker" is just a synonym for "container" for most people, so the main issue is that most projects only ship a compose file. Hopefully they'll ship quadlet files too, some day.

Alternatively, a public repository for sharing quadlets for popular open source software would be great.

On the topic of ditching Docker, has anyone else created a custom test harness with QEMU? I feel like I'm the only person doing it this way. QEMU's target userbase is emulators in general, which is a much broader audience with way more development effort going into it, therefore I don't think it can ever go "out of fashion" or get hijacked by perverse corporate interests like Docker can. Podman seems to have the same vulnerability.

I wonder if we'll see Podman running on Illumos at some point. SmartOS does currently support running Dockerized programs if I remember correctly.

Can `podman` use `macvlan` network if run as non-root? I'm talking about that scenario https://stackoverflow.com/questions/59515026/how-do-i-replic... but for non-root containers.

Same here. Podman Desktop is great. podman/buildah and the whole ecosystem is much more reliable on the server as well.

In addition to rootless podman / root docker there are some other options:

- rootless docker, works fine, not fully sure why it's not the default by now (I do have issues form time to time but I had the same issues with root docker)

- rootfull podman

- running docker/podman daemon as a different and non root user (but have fun trying to mount anything !?)

Yeah I have done this as well.

I write programs that run on the target OS again. It's much easier, turnaround time is much quicker, it's faster. Even battery lasts longer on my laptop. What the hell have we done to ourselves with these numerous layers of abstraction?!?

I have used Podman before, and it just works. However, for the past 8 months, I've been using https://orbstack.dev/, and I can confidently say that it's much better.

So who's gonna do a Podman v. Rancher? OP? You ready for that challenge??

Getting fs permissions in Docker can be a real chore when not running a container in root. Does podman make this easier or just make it required work?

Has anyone ported distrobox to MacOS? or know of a project doing that?

I could reverse engineer all the cool user land stuff it does to make things seamless ... but who has the time ;-)

on a related note, nerdctl latest release adds a lot of compat command features as well

https://github.com/containerd/nerdctl/releases/tag/v2.1.4

Orbstack if you have a Mac.

Is there anything like Skaffold that works with Podman?

same, not because compose, but because I wanted a software to run containers and docker only provides a solution

Supabase is sort of wonky on Podman

Whenever I see portmappings I die a little inside. OrbStack makes so much more sense be default

Sorry, but I tried and just couldn’t get compose and networking to work the way I wanted - as well as permissions, volumes and a lot of other stuff…

Reminder that docker still doesn't support nftables

I use both Podman and Docker at work, specifically I had to use the same docker images / container setup in a RHEL deployment and it worked great.

A huge pain was when I used "podman-compose" with a custom podman system storage location, two times it ended corrupted when doing an "up" and I had to completely scratch my podman system storage.

I must have missed something though ...

I'm a podman user and fan, but there is one gotcha to know about the systemd integration.

You might expect that setting User=foo via systemd would enable seamless rootless containers, but it turns out to be a hard problem without a seamless solution.

Instead, there's this discussion thread with 86 comments and counting to wade through to find some solutions that have worked for some people in some cases.

https://github.com/containers/podman/discussions/20573#discu...

I started working at Red Hat this past year, so obviously all Podman, all day long. It's a super easy switch. I moved to using Containerfiles in my LinkedIn courses as well, if for no other reason than it having a much more "open" naming convention!

Rootless works great, though there are some (many) images that will need to be tweaked out of the box.

Daemonless works great as well. You can still mount podman.sock like you can with Docker's docker.sock, but systemd handles dynamically generating the UNIX socket on connect() which is a much better solution than having the socket live persistently.

The only thing that I prefer Docker for is Compose. Podman has podman-compose, which works well and is much leaner than the incumbent, but it's kind of a reverse-engineered version of Docker Compose that doesn't support the full spec. (I had issues with service conditions, for example).

I ditched Docker and Podman for FreeBSD Jails :)

More here:

- https://vermaden.wordpress.com/2023/06/28/freebsd-jails-cont...

- https://vermaden.wordpress.com/2025/04/11/freebsd-jails-secu...

- https://vermaden.wordpress.com/2025/04/08/are-freebsd-jails-...

- https://vermaden.wordpress.com/2024/11/22/new-jless-freebsd-...

I tried podman for multiple times. Normal testing & sandox stuff just works and you really can do alias docker=podman. But ass soon as you add nertworking me broke for me. And for me it is really just a tool and I need my tools working. So I switched back.

Recently I did the GitLab Runner migration for a company and switched to rootless docker. Works perfectly, all devs did not notice all there runs now use rootless docker and buildkit for builds. All thanks to rootless kit. No podman problems, more secure and no workflow change needed

I did numerous attempts to switch from docker to podman. Latest one worked, and so far I didn't feel the need to get back to docker. There was only one issue that I had: huge uid didn't work in podman (like 1000000 I think), but I fixed the dockerfile and rest worked fine for me. podman-compose does not work well in my experience, but I don't use it anymore.

I have ditched docker desktop on macOS for OrbStack.

Still happily using Colima as a Docker Desktop for Mac replacement. It even allows mixed architecture containers in the same compose stack. What's podman gain me besides a half baked Docker compose implementation?

I primarily use Podman but it is worth noting a few things:

- Podman is usually used "rootless", but it doesn't have to be. It can also be used with rootful containers. It's still daemonless, though it can shim the Docker socket (very useful for using i.e. Docker Compose.)

- Docker can be used in a rootless fashion too. It will still run a daemon, but it can be a user service using user namespaces. Personally I think Podman does much better here.

Podman also has some other interesting advantages, like better systemd integrations. Sometimes Kubernetes just isn't necessarily; Podman + Systemd works well in a lot of those cases. (Note though that I have yet to try Quadlets.) Though unfortunately I don't think even the newer Quadlets integration has some basic niceties that Kubernetes has (like simple ways to do zero downtime deployments.)

I keep seeing Podman mentioned as a Docker alternative, but I'm unclear on when the juice is worth the squeeze. For someone doing typical web development (Node.js/Python services, Postgres, Redis), what specific problems would Podman solve that Docker doesn't? Is this more about security/compliance or are there developer experience benefits too?

i'm the only one that wished docker swarm became the standard instead of k8s?

We where using Podman for certain deployments to AWS recently. However, it was in an EC2 instance and the overhead was unnecesary, so we ended up pasting Bocker[1] to AI, and stripping it of anything unnecesary until leaving just the few isolation features we needed.

[1] https://github.com/p8952/bocker/tree/master

I have a tool[1] that solely worked with docker before and was putting off supporting podman for a while because I thought it would take some time. But it turned out to work straight out of the box without tweaking. Essentially frictionless.

[1] Tool for reference: https://github.com/data-catering/insta-infra

There can be interesting differences, I'm not sure which of them still apply but some I ran into:

- podman having a more consistent CLI API/more parameters (but I think docker did at least partially catch up)

- user-ns container allow mounting the context instead of copying it, this means that if you somehow end up with a huge build context user-ns build can be _way_ faster then "classical" docker builds (might also apply to rootless docker, idk.). We ran into that when that one person in the team using Mac+Docker asked if we can do something about the unbearable slow docker build times (no one else on the team experienced :/)

- docker implicitly always has the docker Hub as configured as source which resolves "unqualified", this might not be true for your podman default setup so some scripts etc. which should work with both might fail (but it's easy to fix, preferable always qualify your images as there are increasingly more image hosts, in worst add docker hub in the config file).

- "podman compose" supports some less feature, this might seem like a huge issue but compose doesn't seem the best choice for deploying software and if I look how it turned out in dev setups the moment things became larger/more complicated I came to the conclusion that docker/podman compose is one of the easy to start with then get trapped in a high complexity/maintenance cost "bad" corner technologies. But I'm still looking for alternatives.

- podman sometimes missing some resource management features, but also docker sometimes does have differences in how it effectively enforces them not just between version but also with the same version between OSes, this had lead to issues before where docker-rootless kills a container and docker on Mac doesn't because on Mac it didn't notice spikes in resource usage (in that specific case).

We were using podman at our company, and it was great for a while but we recently migrated to orb.

The UX with orb is just much easier and the small gotchas between docker/podman started to add up. Especially with buildkit issues we had run into and things like using a remote buildkit instance (which we now use), was not supported well enough.

I have been running Podman in production for a number of years now, and have been very happy with the results.

Podman pods have been super useful, and the nature of my workload is such that we just run a full pod on every host, so it's actually removed the need for an orchestrator like Kubernetes. I manage everything via Ansible and it has been great.

I ditched containers. After a few years it seemed like one of those things that FAANGs use because they need it, while most others are using it just because the FAANGs do.

I'm sure I've spent more time writing and troubleshooting YAML files than I ever did just installing stuff on vm's.

I certainly like demon-less architecture; much simpler and there are less potential security issues and no single point of failure.

The one thing I don't necessarily agree:

"Privileged ports in rootless mode not working? Good! That's security working as intended. A reverse proxy setup is a better architecture anyway."

I usually use Ngix as a reverse proxy - why not have it set up in the exact same way as the rest of your apps? That's a simplicity advantage. So with Podman, I would just run this one exact container in root mode - that's still better than all of them, but quite.

I am not a fan of docker-compose - a classic example of a tool trying to do too much for me, so the lack of something similar in Podman is not a drawback for me :)

Not sure about tooling around logs and monitoring though - there is plenty for Docker.

I've been on Podman since 2019 since Docker didn't support Cgroups v2 for a very long time.

> With Podman, even if someone somehow escalates privileges inside a container to root level, they're still just an unprivileged user on the actual host.

As much as I like Podman (and I really do), Docker has supported rootless mode for a long time and it's not any harder to set up than Podman.

> Use podman-compose as a drop-in replacement

Oh, if only it were a drop-in replacement. There are so many ways in which it is not exactly compatible with docker-compose, especially when it comes to the network setup. I have wasted more hours on this than I can count.

> If your Docker Compose workflow is overly complex, just convert it to Kubernetes YAML.

Is this also applicable for single-host services? I have a lot of my toy projects packaged as a Docker Compose, and I just `docker compose up -d` in my EC2 host and it's ready to go. Last time I dabbled with K8s I remember it requiring separate etcd cluster, and a lot of configurations. I wonder if my existing projects could be converted to K8s manifest and it would be just as convenient as the `docker compose up -d`.

> I'm old enough to remember when Vagrant looked like a promised land where every development environment would look the same.

Oh no... does this mean I'm old too?!? This feels just like yesterday!

We did the same. Switching was a cinch honestly - the only thing that screwed me up was some dumb page that returned a bunch of nonsense I was supposed to do to my docker-compose.yml file to make it more compatible with podman-compose. I spent a couple hours trying to figure out why things weren't working, until I finally rolled back all the stupid suggested changes, and my app fired right up.

The only impactful difference I've noticed so far is that the company is moving to an artifact repository that requires authentication, and mounting secrets using --mount doesn't support the env= parameter -- that's really it.

I treat podman like I did docker all day long and it works great.

Podman has full compatibility and same command syntax with docker. Perfect cockpit and kubernetes co existence. Daemonless, rootless and open source are killer features and reasons to switch.

I believe rootless containers require Linux user namespaces which have historically been the source of many vulnerabilities: https://news.ycombinator.com/item?id=43517734

I'm conflicted about whether or not it's better to run a root daemon that can launch unprivileged non-root containers or run rootless containers launched by a non-root user.

Anyone have thoughts or more definitive resources they could point to that discuss the tradeoffs?

I don't understand why it's so popular to run the docker daemon as root.

Rootless mode seems to support all the same features, but is obviously more secure than the "run everything as root" mode. In fact, most of the CVE's mentioned would allow an attacker to escalate to the privilege of the user running docker, instead of escalating to he root user.

Comparing the security of rootless-podman to rootful-docker is an absurd (and obviously unfair) comparison.

My go service in podman container requires a container restart after waking up. That's the only downside I've felt after switching from docker to podman.

> Or rather NO, because this daemon runs with root privileges.

note that docker daemon does not have to be running with root privileges. you can use this script to start docker rootless: https://github.com/docker-archive/engine/blob/master/contrib...

Docker swarm is great on single servers. Apparently still no such thing for Podman.

Even if the tech is not top notch, Docker got a few things right on product management.

I would love to switch to podman, but rely on docker's credential helpers with gcloud CLI for authentication to pull from Google Artifact Registry on Mac with hyperkit. Last time I tried I couldn't figure out how to do this with podman machine in a way that respected gcloud credentials properly and could only find some hacks that involved passing short term tokens instead of supporting proper refresh flows. Is there a guide how to do that now?

me: great can target POSIX for stuff

them: not so fast here's glib

me: great can use debian for stuff

them: not so fast, here's rpm

me: great can use docker for "abstracting" over Linux diversity

them: not so fast, here's podman

if you mount local path's, it's a pain.

I know a lot of kubernetes fans migrate to podman, but if you use dev stacks.

Use in dev: devcontainer, podman can't replace docker!

I had the opposite experience with Podman and decided to stick with Docker because I prefer the "daemon-full" architecture and ease of installation.

I even wrote wrote an article about that: https://joshkaramuth.com/blog/docker-vs-podman/

my team switched to podman due to docker desktop licensing (and only using engine pain). personally it has been quite annoying to work with on windows with cuda.

the need to spin its own wsl instance (which takes a lot of disk space) and gpu workarounds are just not there yet.

others have mentioned about podman compose but the old docker-compose do work to be fair.

What do you guys use to profile whole ci/cd pipelines that involve building software , building (many) containers, running tests, running e2e tests etc. Ci/cd can be a huge drag on the lead time of delivery teams, containerisation helped with one thing but prolonged another. Is there a way out of this performance drag?

You are going to have to pry Docker from my cold dead hands.

Podman is a failed reverse-engineering of cherry-picked so-called "good" parts of Docker.

In my experience Podman is better but always ends up having some wonky bug (like, the other day, secrets didn't mount anymore during builds). Rootless, daemonless is great but it's basically bound to have some extra tinkering required compared to "a stupid daemon running as root"

As much as I’d like to switch to Podman, I’m using Vite inside a container and need to monitor file changes on the host folder. It doesn’t detect them, and polling isn’t ideal. Does anyone have tips I might not know about yet?

But Apple Container is another option with direct IP network support on macOS Tahoe, not possible with macOS Sequoia.

Does anyone here have more than "initial impressions" of systemd-nspawn? It seems chronically overlooked in these sorts of threads.

As bad as the horror stories about switching might be, I don't see how docker can remain as is. The level of vulnerability it causes seems like a fundamental flaw. I assume docker itself hasn't changed because it took off so fast and now it'd be breaking changes galore, but eventually everyone is going to have to pull the trigger.

To add to the article: systemd integration works in the other way too! Running systemd in a Docker container is a pain. It's much easier in Podman: https://developers.redhat.com/blog/2019/04/24/how-to-run-sys...

(Most people use containers in a limited way, where they should do just one thing and shouldn't require systemd. OTOH I run them as isolated developer containers, and it's just so much easier to run systemd in the container as the OS expects.)

If you are on a Mac, I have been using OrbStack[1] and it has been fantastic. I spin up few containers there, but my biggest use is just spinning up Alpine linux and then running most of my Docker containers in there.

[1] https://orbstack.dev/

Both podman and docker have pretty poor error handling in my experience. It depends on the error, but for me it often comes down to a docker compose misconfiguration, resource, permissions, etc. In docker always find the errors quite difficult to trace back to root cause. In podman you get a python a stack trace. I wish both projects would assert different assumptions/requirements at runtime and report errors/warnings in a human-readable way.

Docker is failing in that trap where they feel the need to try (and mostly fail so far) to add net-new value streams (e.g. mcp catalogue, a bunch of other stuff i immediately turned off that last time i installed it) rather than focus on the core value.

It's not the case that they've maximised the utility of the core build / publish container nor the acquire / run container workflows and but they're prioritising fluff around the edges of the core problem.

Podman for its various issues is a whole lot more focussed.

I have a few links saved from my joyful experience using podman with Fedora (and therefore selinux). Iirc, I tried using podman because Fedora shipped cgroups v2, which didn't work with Docker (in my own ignorance, I would've thought coordinating with major dev tools would be important, but distros often have other ideas).

- https://www.redhat.com/en/blog/user-namespaces-selinux-rootl... - https://www.redhat.com/en/blog/sudo-rootless-podman

I'd summarize these posts as "very carefully explaining how to solve insane problems."

I do not know: the lack of proper docker compose support it is a problem for me. About security: gVistor adoption failure in Google is a proof that containerization cannot be enforced easily and container will always be less secure than a VM.

If you want proper security go to firecracker [^1]. Podman is the "RedHat/IBM docker-way" but I see very little benefit overall; never less if it works for you great and go with it!

[^1]: https://firecracker-microvm.github.io

I am still on an x86 Mac.

When Docker Desktop changed licensing I tried to switch to Podman and it was a disaster, Podman was brand new and despite many blog posts that claimed it was the perfect replacement it did not work for me, and I have very simple requirements. So I ended up using Rancher Desktop instead, which was also very unstable but better.

Fast forward 1 year, Rancher was pretty good and Podman still did not work reliably on my mac.

Fast forward another year or so and I switched to colima.

I tried podman last time about one year ago and I still had issues on my old mac. So far colima has been good enough for my needs although at least two times a brew update broke colima and I had to reinstall from scratch.

OP fails to understand that in practice people use Docker Desktop on their laptop and deploy to a container platform or Kubernetes cluster that uses ContainerD. So all of these so-called issues are moot. Further, Docker Inc (and the people behind Docker CLI, Compose etc), have way better UX taste and care for DX than their competitors which matters a lot in local development.

I don't know how podman compares to docker in terms of performance, and I do know that rootless containers can be a real pain.

But Docker is simply a non-starter. It's based on a highly privileged daemon with an enormous, hyper-complicated attack surface. It's a fundamentally bad architecture, and as far as I've been able to tell, it also comes from a project that's always shown an "Aw, shucks" attitude toward security. Nobody should be installing that anywhere, not even if there weren't an alternative.

Great, if you're on Mac: https://apple.github.io/container/documentation/

Rootless podman in combination with systemd quadlet works great for me. I host all my personal services like that. Having containers integrated directly into systemd makes mapping out dependencies between mounts and other non containerized services much more reliable and easier.

My favorite part of the blog is how the author lets us know he is pretty young to reference vagrant as old.

I had an issue where docker was not producing repeatable sha's. Somehow a time based metadata was affecting the image sha after every build.

Switching to podman immediately fixed it, never looked back

This is a hell of a lot like saying you ditched driving cars to ride a monorail with only two stops in the wrong neighborhood. You’re comparing apples and oranges and selectively leaving out info to highlight that.

Could never get rootless to work properly. I wanted to like Podman, but every time I wanted to use it there was some bump in the road that made me give up and use Docker.

I switched about 3 weeks ago. I’m not a power user of either. But I don’t smell the odor of coming enshitification anymore either. Podman doesn’t feel like a platform or an ecosystem. It’s just a tool.

5 years ahead of you on that.

Interesting how slowly this advice has bubbled up. This is another software example where people didn’t care about resource usage and were “fine” with the Docker daemon.

I did the same first, then went with Colima, nowadays with Orbstack. My point is, there are so many great options apart from Docker Desktop

I have used Podman before, and it just works. However, for the past 8 months, I've been using orbstack, and I can confidently say that it's much better.

> Privileged ports in rootless mode not working? Good! That's security working as intended. A reverse proxy setup is a better architecture anyway.

So, how are you supposed to run the proxy inside the container? Traefik for example? Genuinely curious.

So did I ... But I've started writing my applications to run locally, in a WASM runtime and in a container so most of my debug and test occurs right on my OS.

The fact that people keep conflating docker desktop and the docker engine is crazy.

The out of the box DX on podman needs improvement, the automated image management logic is bad, but besides that it's a pretty good tool.

What is the current way of running a dokcer container as a systemd service? Is it podman?

Last third party container I’ve built had COPY —-link statements that didn’t worked on podman. Granted it worked just fine with a normal copy but it’s not 1:1.

I like Podman with it's API for hosting (no k8s) but I reverted back to Docker for local because of docker-compose incompatibilities. This was a year or more ago so it may not still be an issue.

I love the container auto update feature. It's so nice to have them built in whereas for Docker I had to use watchtower.

Iv been using podman for around 2 years now without issue. Works great for my use cases.

To bikeshed a little, "Why I Ditched Docker for Podman, And Why You Should Too" would be better than the current headline of "Why I Ditched Docker for Podman (And You Should Too)": the "you should too" part is after all the main message of the article, not a side-point.

How does Podman work with Alpine? Lots of talk of Ubuntu and Debian below.

Docker daemon had been freaking me out for a while. If it's really so seamless I'll look into migrating.

docker works well enough.

podman avoids having to deal with the Purchasing department, but doesn't work great.

would definitely suggest doing docker if you're up to dealing with the purchasing department.

We are are migrating back to Docker org-wide after 5 months on Podman.

I switched for local development work a couple of years back and can count on no fingers the number of times I thought about switching back. It let me stop thinking about the Docker Mac high CPU issue which was open for years with no progress, too.

I wish podman was more common in documentation. Want to use podman with your CI platform, it will probably work with socket compatibility but good luck finding instructions and anyone know if it’s tested. How about using some service with podman? Yeah the container is the same, but all the instructions or docker this or docker that, and god help you if you if they used networking or compose.

I prefer to use podman if it’s available on my system but it still hasn’t hit the critical mass needed for it to be targeted and that’s a shame.

Also is there something like a dockerfile for buildah? I’ve tried a few times to understand how to use buildah and just fall back on a dockerfile because I can’t seem to wrap my head around how to put it into something IAC like.

> I literally just aliased docker=podman in my shell and carried on with life.

Thanks, I hate it. It might look fine at first but once you need anything more advanced than running a hello world container, it falls apart. Fun fact, there is no set of flags that would correctly build a multi-platform image on both Docker and Podman -- I found out the hard way.

I guess Podman may work if you go all in on it, but pretending that it's a drop-in replacement for Docker will bring you only pain.

I use podman since I can simply enable it using home-manager:

`services.podman.enable`

This also means that it's in the reproducible part of my setup which is a bonus.

Isn’t Portman ibm?

what dot mee

Rancher Desktop was far easier to get up and running on macOS than podman for me. Drop in compatible with docker compose syntax too.

docker was harder to pick up than vim but once it works, it just works. podman seems interesting at first but it's a complete mess to pick up and once you pick it up you realize it isn't worth the hassle. more power to podman afficionados but I can't see this taking off

> just convert it to Kubernetes YAML

Either you haven't worked on k8s at scale or you're seriously suggesting an overly complex solution to elegant docker-compose. Docker compose exists because of it's simplicity and stability. I have also started using swarm and it doesn't get the recognition it deserves for the most easy-to-manage orchestration. Podman doesn't have such a thing. And yes, podman-compose is absolute garbage

Man I’m tired

Tried a couple of times and gave up. Just didn’t work at all for too many containers

Yeah, no, sorry.

Too many problems with things that worked out of the box with docker.

I don't have time to waste on troubleshooting yet another issue that can be solved by simply using the thing that just works.

rootless is not an argument for me, since the hosts are dedicated docker hosts anyway.

FreeBSD jails ftw!

Podman works 99% for me, it’s getting better each release. But every so often I get bitten by some incompatibility and have to use Docker.

At the moment it seems docker compose misbehaves with Podman when WSL2 gets involved.

I look forward to when I can replace Docker entirely.

It’s gotten a lot better on MacOS as the virtualization framework had virtio functionality added to it.

ever try to dev with it on a Mac?

haha.

Nope. No thank you. Not sure if Windows has that issue.

Any alternative for Windows containers?

Podman compose isn't compatible with Docker compose, end of story.

I mean I get the overall benefits of having rootless and all, but the premise of security in this article is a bit misleading.

Obviously having a daemon running as root is larger attack surface than a program running as the user.

Going to the github.com/containers/podman/releases, the latest release is actually addressing a security risk that involves overwriting files of the host.

    # v5.6.1 (Latest)
    ## Security
    - This release addresses CVE-2025-9566, where Kubernetes YAML run by podman play kube containing ConfigMap and Secret volumes can use crafted symlinks to overwrite content on the host.

As always, the most secure computer is the one that is unplugged & turned off.

Don't give iXsystems (TrueNAS) ideas. 3 times was enough.