19 ms·

I ditched Docker for Podman

• deleted 1y ago
  [deleted]
• travisgriggs 1y ago
  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.
• gtirloni 1y ago
  Same here. Podman Desktop is great. podman/buildah and the whole ecosystem is much more reliable on the server as well.
• xyst 1y ago
  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/ https://docs.docker.com/engine/security/rootless/
  • srid 1y ago
    Or if you are on macOS, there is https://github.com/juspay/services-flake https://github.com/juspay/services-flake which is based on process-compose. So you get an unified alternative to docker-compose but based on Nix and works on both platforms.
• jnovacho 1y ago
  > 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.
  • eddieroger 1y ago
    Don't run it in rootless for your reverse proxy? Having one container running that way is still better than having all of them work that way.
  • deleted 1y ago
    [deleted]
• CraigJPerry 1y ago
  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.
  • colechristensen 1y ago
    The core of docker needs to be free. The docker registry can charge corporate customers for storage and such, but besides being the default registry, there's not much money there because it's a commodity service, not anything unique. There's just not much money to be made there, especially considering that docker is a pretty thin wrapper built on top of a bunch of other free technology. When somebody can make a meaningful (though limited) clone of your core product in 100 lines of bash, you can't make much of a business on top of it [1] Docker suffers from being useful in the open source space but having no reasonable method to make revenue. https://github.com/p8952/bocker https://github.com/p8952/bocker
  • jen20 1y ago
    They have the second problem that `container` [1] will eat up a ton of their business when it ships properly in a month or two. [1]: https://github.com/apple/container https://github.com/apple/container
    • mdaniel 1y ago
      uh-huh, maybe for the corps that have a predictable hardware refresh schedule but I've never worked in such a place https://github.com/apple/container#:~:text=is%20supported%20on%20macos%2026 https://github.com/apple/container#:~:text=is%20supported%20...
      • jen20 1y ago
        Why does the hardware refresh schedule matter? What you appear to be referring to is the _operating system_ refresh schedule, which should be every year even at enterprises where corporate IT is problematic.
• gr4vityWall 1y ago
  I wonder if we'll see Podman running on Illumos at some point. SmartOS does currently support running Dockerized programs if I remember correctly.
  • mdaniel 1y ago
    Only if Illumos supports kernel namespaces; it's the same problem as "podman on XNU" (I don't mean via VM, I mean on XNU): there's nothing stopping them, but it evidently isn't important to them, either
• tristor 1y ago
  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.
• mathfailure 1y ago
  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.
• deleted 1y ago
  [deleted]
• dktalks 1y ago
  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/ https://orbstack.dev/
  • dktalks 1y ago
    Setup is really easy once you install alpine 1. ssh orb (or machine name if you have multiple) 2. sudo apk add docker docker-cli-compose (install docker) 3. sudo addgroup <username> docker (add user to docker group) 4. sudo rc-update add docker default (set docker to start on startup) Bonus, add lazydocker to manage your docker containers in a console 1. sudo apk add lazydocker
  • classified 1y ago
    You mean, you let Docker containers run inside the OrbStack container, or how does that work?
    • dktalks 1y ago
      No, you don't run the Docker containers run in OrbStack, you can spin up an Alpine instance and run all docker instance on it. The benefit is that, Alpine has access to all your local and network drives so you can use them. You can sandbox them as well. It's not a big learning curve, just a good VM with access to all drives but isolated to local only.
      • dktalks 1y ago
        And you can run Docker inside OrbStack too, it is really good. But most of my containers are optimized Alpine containers so I prefer to run them on an OS they were built for and others in OrbStack.
  • ghrl 1y ago
    I use OrbStack too and think it's great software, both for running containers and stuff like having a quick Alpine environment. However, I don't see the point of running Docker within Alpine. Wouldn't that defeat the optimizations they have done? What benefits do you get?
• deleted 1y ago
  [deleted]
• ac130kz 1y ago
  Podman compose isn't compatible with Docker compose, end of story.
• nunez 1y ago
  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).
  • mdaniel 1y ago
    > that doesn't support the full spec I'd guess that's because "the spec" is more .jsonschema than a spec about what behaviors any random version should do. And I say "version" because they say "was introduced in version $foo" but they also now go out of their way to say that the file declaring what version it conforms to is a warning
  • figmert 1y ago
    Docker compose works fine with podman via its socket.
    • nunez 1y ago
      Correct.
• mychael 1y ago
  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.
  • odie5533 1y ago
    The UI is what held me back from switching last time I tried podman. Docker Desktop is nice.
    • figmert 1y ago
      Podman Desktop also exists.
• righthand 1y ago
  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.
• tsoukase 1y ago
  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.
• SamInTheShell 1y ago
  It’s gotten a lot better on MacOS as the virtualization framework had virtio functionality added to it.
• bval 1y ago
  I have used Podman before, and it just works. However, for the past 8 months, I've been using https://orbstack.dev/ https://orbstack.dev/, and I can confidently say that it's much better.
• bval 1y ago
  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.
• jayd16 1y ago
  Any alternative for Windows containers?
  • coffeecoders 1y ago
    There isn't anything really. The WSL backend is the pain point, which doesn't go away with Docker or Podman or anything else.
    • jayd16 1y ago
      I actually mean windows kernel containers so I don't think wsl is involved. Windows server can run them without docker but for local dev I'm not sure what the alternative is.
      • esseph 1y ago
        Just.. run linux for those?
• rweichler 1y ago
  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.
  • drzaiusx11 1y ago
    This is what Lima is, which is the basis for Colima which runs on top with all the Docker runtime stuff https://github.com/lima-vm/lima https://github.com/lima-vm/lima https://github.com/abiosoft/colima https://github.com/abiosoft/colima
    • rweichler 1y ago
      Interesting, thanks. Looks much better than Docker/Podman. But seems to suffer from the same incentive issue. I think I'll stick with my raw QEMU setup, Lima seems like QEMU + batteries, but I already built the batteries.
      • drzaiusx11 1y ago
        Fun fact podman desktop is just a front end to Lima, or was last I checked
        • rweichler 1y ago
          Yeah, seems like the power law is at play here. I made my test harness in 2020 so I didn't have a choice as Lima didn't exist back then. I should have waited a year. I'll certainly keep an eye on it
• evertheylen 1y ago
  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-systemd-in-a-container 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.)
• sspiff 1y ago
  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.
  • rsyring 1y ago
    Do you have a summary of those most common issues and their workarounds?
    • wyoung2 1y ago
      Broadly, the claim that Podman is a drop-in replacement for Docker is true only for the simple cases, but people have developed assorted dependencies on Docker implementation details. Examples: 1. People hear about how great rootless is with Podman but then expect to be able to switch directly from rootful Docker to rootless Podman without changing anything. The only way that could work is if there was no difference between rootful and rootless to begin with, but people don't want to hear that. They combine these two selling points in their head and think they can get both a drop-in replacement for Docker and also rootless by default. The proper choice is to either switch from rootful Docker to rootful Podman *or* put in the work to make your container work in rootless, work you would also have had to do with rootless Docker. 2. Docker Compose started out as an external third-party add-on (v1) which was later rewritten as an internal facility (v2) but `podman compose` calls out to either `docker-compose` (i.e. v1) or to its own clone of the same mechanism, `podman-compose`. The upshot is a lot of impedance mismatch. Combine that with the fact that Podman wants you to use Quadlets anyway, resulting in less incentive to work on these corner cases. 3. Docker has always tried to pretend SELinux doesn't exist, either by hosting on Debian and friends or by banging things into place by using their privileged (rootful) position. Podman comes from Red Hat, and until recently they had Mr SELinux on the team. Thus Podman is SELinux-first, all of which combines to confuse transplants who think they can go on ignoring SELinux. 4. On macOS and Windows, both Podman and Docker need a background Linux VM to provide the kernel, without which they cannot do LXC-type things. These VMs are not set up precisely the same way, which produces migration issues when someone is depending on exact details of the underlying VM. One common case is that they differ in how they handle file sharing with the host.
• lisbbb 1y ago
  Orbstack if you have a Mac.
• awoimbee 1y ago
  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
  • physicles 1y ago
    I had this problem on the latest Pop OS LTS (I know, I know). Took about 4 hours to find the magic incantation that would let me install podman >= 4 without breaking anything else.
  • alyandon 1y ago
    Yeah, the lack of an official upstream .deb that is kept up to date (like the official Docker .deb repos) for Ubuntu really kills using podman for most of my internal use cases.
  • rsyring 1y ago
    Additionally, there aren't even any trusted repos out there building/publishing a .deb for it. The ones that I could find when I searched last were all outdated or indicated they were not going to keep moving forward. I could get over this. But, IMO, it lends itself to asking the "why" question. Why wouldn't Podman make installing it easier? And the only thing that makes sense to me is that RedHat doesn't want their dev effort supporting their competitor's products. That's a perfectly reasonable stance, they owe me nothing. But, it does make me feel that anything not in the RH ecosystem is going to be treated as a second-class citizen. That concerns me more than having to build my own debs.
    • kiney 1y ago
      debian trixie has podman 5 packages in official repos. Good chance thqt those work on ubuntu
      • gm678 1y ago
        Also on Ubuntu 25.04, which I updated a homeserver too despite it not being LTS just for the easy access to Podman 5. Once Ubuntu 26.04 comes out the pain described by some sibling comments should end. Podman 4 is a workable version but 5.0 is where I'd say it really became a complete replacement for Docker and quadlets fully matured.
• condenser 1y ago
  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?
  • rsyring 1y ago
    Might be part of your solution: https://github.com/psviderski/unregistry https://github.com/psviderski/unregistry > Unregistry is a lightweight container image registry that stores and serves images directly from your Docker daemon's storage. > > The included docker pussh command (extra 's' for SSH) lets you push images straight to remote Docker servers over SSH. It transfers only the missing layers, making it fast and efficient. But, given that podman rootless doesn't have a daemon like Docker, I think using Podman in a push-to-remote scenario is just going to have more pieces for you to manually manage. There are PaaS solutions out there, like Dokku, that would give you a better devx but will also bring additional setup and complexity.
  • gucci-on-fleek 1y ago
    podman-compose [0] is a mostly drop-in replacement for local usage, but I have no idea if it works remotely. "podman image scp" [1] looks like it could be helpful though. [0]: https://github.com/containers/podman-compose https://github.com/containers/podman-compose [1]: https://docs.podman.io/en/latest/markdown/podman-image-scp.1.html https://docs.podman.io/en/latest/markdown/podman-image-scp.1...
• miki123211 1y ago
  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.
  • mixmastamyk 1y ago
    Sounds like you need to grant the user sufficient permissions. What else might go wrong?
    • iTokio 1y ago
      Mounting Volume and dealing with FS permissions. They are many different workarounds but it’s a known pain point.
    • marcel_hecko 1y ago
      It's mostly the subgid subuid mapping of ids between guest and host which is non trivial to understand in rootless envs. Add selinux in the mix....
      • galangalalgol 1y ago
        What actual issues do you run into? We have selinux and rootless and I didn't notice the transition from docker as a user.
      • strbean 1y ago
        > subgid subuid mapping trigger warning please D:
  • marcel_hecko 1y ago
    I have done the same. It's not too bad - just don't rely on LLMs to design your quadlets or systemd unit files. Read the docs for the exact podman version you use and it's pretty okay.
  • prmoustache 1y ago
• rsyring 1y ago
  I believe rootless containers require Linux user namespaces which have historically been the source of many vulnerabilities: https://news.ycombinator.com/item?id=43517734 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?
  • gucci-on-fleek 1y ago
    All containers use user namespaces, but only rootless containers require unprivileged user namespaces. Unprivileged user namespaces didn't have a great security record for the first few years, but vulnerabilities are relatively rare these days. Running podman with SELinux enforcing (the default) and with "--security-opt=no-new-privileges" combined with running applications as non-root inside their containers should further reduce the security risk. You could also disable unprivileged user namespaces inside the containers if you want, which would mean that exploiting unprivileged user namespaces would first require arbitrary code execution on the host.
• danousna 1y ago
  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 ...
• thesurlydev 1y ago
  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.
• jimt1234 1y ago
  Great, if you're on Mac: https://apple.github.io/container/documentation/ https://apple.github.io/container/documentation/
• sudoshred 1y ago
  Rancher Desktop was far easier to get up and running on macOS than podman for me. Drop in compatible with docker compose syntax too.
• dev_l1x_be 1y ago
  What is the current way of running a dokcer container as a systemd service? Is it podman?
  • ethagnawl 1y ago
    Just create a unit file that starts/stops/restarts/etc. the container.
    • dev_l1x_be 1y ago
      what do you mean exactly? What is the tool that you invoke? Or you use systemd's container executing ability?
      • ethagnawl 1y ago
        Whenever I've done this, I've used the system service's ExecStart|Stop directives to run a Bash script which handles starting/stopping the container (e.g. `docker run ...`) and any other setup teardown behavior that's appropriate.
• dathinab 1y ago
  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).
• bjt 1y ago
  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.
• Eji1700 1y ago
  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.
• todotask2 1y ago
  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.
• Gud 1y ago
  FreeBSD jails ftw!
• betaby 1y ago
  Can `podman` use `macvlan` network if run as non-root? I'm talking about that scenario https://stackoverflow.com/questions/59515026/how-do-i-replicate-a-docker-macvlan-network-with-podman https://stackoverflow.com/questions/59515026/how-do-i-replic... but for non-root containers.
• dathinab 1y ago
  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 !?)
• codethief 1y ago
  > 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.
• BinaryIgor 1y ago
  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.
  • chuckadams 1y ago
    Allowing binding to a privileged port should be as simple as adding CAP_NET_BIND_SERVICE to the process, most likely in a systemd unit file or something . I still suggest using a reverse proxy like nginx or traefik, so add the capability to those. There's no reason for the proxy to run as root.
• minton 1y ago
  We are are migrating back to Docker org-wide after 5 months on Podman.
• acdha 1y ago
  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.
  • jamra 1y ago
    Very nice. Macs have a new containers program. It’s open source on github but not ready for the current MacOS version. Might be an even better approach as it’s made by Apple.
    • acdha 1y ago
      Yeah, I’ll take a look after I upgrade but I haven’t had to spend time on Podman in years so there’s an upper bound for how much it can improve my life.
• rglover 1y ago
  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.
  • TrainedMonkey 1y ago
    Containers and container orchestrators are complex tools. The constant cost of using them is pretty high compared to bash scripts. However the scale / maintenance factor is significantly lower, so for a 100 boxes simplicity of bash scripts might still win out over the containers. At 1000 machines it is highly likely that simplest and least maintenance overall solution will be using an orchestrator.
    • rglover 1y ago
      That's what I found out, though: the footprint doesn't matter. I did have to write a simple orchestration system, but it's literally just me provisioning a VPS, bootstrapping it with deps, and pulling the code/installing its dependencies. Short of service or hardware limits, this can work for an unlimited number of servers. I get the why most people think they need containers, but it really seems only suited for hyper-complex (ironically, Google) deployments with thousands of developers pushing code simultaneously.
      • chickensong 1y ago
        > it really seems only suited for hyper-complex (ironically, Google) deployments with thousands of developers pushing code simultaneously There are many benefits to be had for individuals and small companies as well. The piece of mind that comes with immutable architecture is incredible. While it's true that you can often get quite far with the old cowboy ways, particularly for competent solo devs or small teams, there's a point where it starts to unravel, and you don't need to be a hyper-complex mega-corp to see it happen. Once you stray from the happy path or have common business requirements related to operations and security, the old ways become a liability. There are reasons ops people will accept the extra layers and complexity to enable container-based architecture. They're not thrilled to add more infrastructure, but it's better than the alternative.
• AsmodiusVI 1y ago
  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.
• Lariscus 1y ago
  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.
• user94wjwuid 1y ago
  Man I’m tired
• rasmus-kirk 1y ago
  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.
• s_ting765 1y ago
  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.
  • vaylian 1y ago
    What part of podman is not working for you?
    • s_ting765 1y ago
      Many things but summarily it would be the promise of a 1:1 drop-in replacement for Docker.
• timcambrant 1y ago
  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?
• rubenv 1y ago
  Is there anything like Skaffold that works with Podman?
• payong 1y ago
  what dot mee
• MadVikingGod 1y ago
  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.
• deleted 1y ago
  [deleted]
• udev4096 1y ago
  > 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
• vermaden 1y ago
  I ditched Docker and Podman for FreeBSD Jails :) More here: - https://vermaden.wordpress.com/2023/06/28/freebsd-jails-containers/ https://vermaden.wordpress.com/2023/06/28/freebsd-jails-cont... - https://vermaden.wordpress.com/2025/04/11/freebsd-jails-security/ https://vermaden.wordpress.com/2025/04/11/freebsd-jails-secu... - https://vermaden.wordpress.com/2025/04/08/are-freebsd-jails-containers/ https://vermaden.wordpress.com/2025/04/08/are-freebsd-jails-... - https://vermaden.wordpress.com/2024/11/22/new-jless-freebsd-jails-list-manage-tool/ https://vermaden.wordpress.com/2024/11/22/new-jless-freebsd-...
  • cheema33 1y ago
    Can you run MS SQL Server inside a FreeBSD jail? Or any of the thousands of other ready to run docker containers? Whatever you gain by running FreeBSD comes at a high cost. And that high cost is keeping FreeBSD jails from taking over.
  • udev4096 1y ago
    How is that any different than running VMs on a linux host?
    • vermaden 1y ago
      Because containers are not virtual machines - You can run 1000 FreeBSD Jails on your laprop while you will not be able to run 1000 VMs - Jails are a lot lighter on resources then VMs.
  • matrix12 1y ago
    Very distro specific however.
  • chuckadams 1y ago
    That's ... a lot of setup. Does FreeBSD have anything similar to containerd?
    • vermaden 1y ago
      Check BastilleBSD https://bastillebsd.org/ https://bastillebsd.org/ along with Rocinante - https://bastillebsd.org/rocinante/rocinante/ https://bastillebsd.org/rocinante/rocinante/ from here.
• 0xbadcafebee 1y ago
  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/ 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.
  • amclennon 1y ago
    > 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. This is only partially true. Google's runtime (gvisor) does not share a kernel with the host machine, but still runs inside of a container.
    • s_ting765 1y ago
      Google cloud dropped gVisor in favor of micro VMs. https://cloud.google.com/blog/products/serverless/cloud-run-jobs-and-second-generation-execution-environment-ga https://cloud.google.com/blog/products/serverless/cloud-run-...
    • carwyn 1y ago
      Second generation moved away from gVisor: https://cloud.google.com/blog/products/serverless/cloud-run-jobs-and-second-generation-execution-environment-ga https://cloud.google.com/blog/products/serverless/cloud-run-...
      • amclennon 1y ago
        Ah, today I learned
• icanthulahoop 1y ago
  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
• varispeed 1y ago
  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.
• tietjens 1y ago
  How does Podman work with Alpine? Lots of talk of Ubuntu and Debian below.
• ThomW 1y ago
  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.
• ttul 1y ago
  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.
  • sroerick 1y ago
    The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend. We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. While I've used Docker a lot since then, that remains the single easiest deployment I've ever had. I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7?
    • Shog9 1y ago
      Reproducibility? No. Not having to regularly rebuild the whole dev environment because I need to work on one particular Python app once a quarter and its build chain reliably breaks other stuff? Priceless.
      • janjongboom 1y ago
        This false sense of reproducability is why I funded https://docs.stablebuild.com/ https://docs.stablebuild.com/ some years ago. It lets you pin stuff in dockerfiles that are normally unpinnable like OS package repos, docker hub tags and random files on the internet. So you can go back to a project a year from now and actually get the same container back again.
• qalmakka 1y ago
  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"
• smoyer 1y ago
  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.
• sharts 1y ago
  The fact that people keep conflating docker desktop and the docker engine is crazy.
• MorehouseJ09 1y ago
  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.
• pvtmert 1y ago
  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.
• Kon5ole 1y ago
  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.
• PufPufPuf 1y ago
  > 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.
• thatxliner 1y ago
  Supabase is sort of wonky on Podman
• tuananh 1y ago
  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 https://github.com/containerd/nerdctl/releases/tag/v2.1.4
• jchw 1y ago
  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.)
• bzmrgonz 1y ago
  So who's gonna do a Podman v. Rancher? OP? You ready for that challenge??
• aprilfoo 1y ago
  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.
• pbd 1y ago
  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?
  • arcfour 1y ago
    At a high level, Docker and Podman implement the same standard for containers, but my understanding is that Podman implements more of said standard (more/newer features) and in a more standards compliant way. This can be a good or a bad thing—good because it's better, but bad because the popularity of Docker sometimes means things aren't compatible and require some tweaking to get running.
    • pbd 1y ago
      fair enough. thanks.
  • mechanicalpulse 1y ago
    Podman is daemonless while docker is a client/server pair. Podman also shipped with support for rootless containers, though Docker now has that capability as well. The podman CLI is nearly a drop-in replacement for docker such that `alias docker=podman` works for many of the most common use cases. If you don't care about the security implications of running containers as root via a client/server protocol, then by all means keep using Docker. I've switched to podman and I'm happy with my decision, but to each their own.
• puilp0502 1y ago
  > 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`.
• brokegrammer 1y ago
  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/ https://joshkaramuth.com/blog/docker-vs-podman/
• taspeotis 1y ago
  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.
• polskibus 1y ago
  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?
  • polskibus 1y ago
    By drag I mean 3-4 hrs until all e2e passed on an ephemeral k8s stack on a vm.
• daitangio 1y ago
  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 https://firecracker-microvm.github.io
  • virgoerns 1y ago
    Podman 4.7 supports both the ordinary compose (Go implementation) and older Python podman-compose. But personally I moved to quadlets and didn't look back.
  • vrotaru 1y ago
    There is a podman-compose which works almost as drop-in replacement. Almost because most common commands work, but I have not check all. And almost, because for some docker-compose.yaml which you downloaded/LLM generated you may need to prepend `docker.io/` to the image name
• wonrax 1y ago
  I love the container auto update feature. It's so nice to have them built in whereas for Docker I had to use watchtower.
• WhyNotHugo 1y ago
  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.
• jesprenj 1y ago
  > 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/dockerd-rootless.sh https://github.com/docker-archive/engine/blob/master/contrib...
• rldjbpin 1y ago
  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.
• davidcatalano 1y ago
  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?
• tomrod 1y ago
  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?
  • jeffhuys 1y ago
    For a while we used it for scalable preview environments: specify the branch, hit deploy, and have a QA-able environment, with full database (anonymized) ready to go in 15 minutes (DB was time bottleneck). We ditched it for EC2s which were faster and more reliable while being cheaper, but that's beside the point. Locally I use OrbStack by the way, much less intrusive than Docker Desktop.
    • spicyusername 1y ago
      EC2 and containers are orthogonal technologies, though. Containers are the packaging format, EC2 is the infrastructure. (docker, crio, podman, kata, etc are the runtime) When deploying on EC2, you still need to deploy your software, and when using containers you still need somewhere to deploy to.
      • jeffhuys 1y ago
        True; I conflate the two often. The EC2s run on an IAM image, same as production does, which before was a docker image.
        • spicyusername 1y ago
          Arguably it would still be beneficial to use container images when building your AMIs (vs installing use apt or copying your binaries), since using container images still solves the "How do I get my software to the destination?" and the "How do I run my software and give it the parameters it needs?" problems in a universal way.
          • jeffhuys 1y ago
• ZeroConcerns 1y ago
  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...
• kdumont 1y ago
  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.
  • cpuguy83 1y ago
    BTW, undrstandable to not have an example on the spot. In general we do actually try to provide full context for errors from dockerd. Some things can be cryptic because, frankly, they are cryptic and require digging into what really happened (typical of errors from runc), but we do tend to wrap things so at least you know where the call site was. There's also tracing data you can hook into, which could definitely be improved (some legacy issues around context propagation that need to be solved). I've definitely seen, in the past, my fair share of errors that simply say "invalid argument" (typically this is a kernel message) without any context but have worked to inject context everywhere or do better at handling errors that we can. So definitely interested in anything you've seen that could be improved because no one likes to get an error message that you can't understand.
  • cpuguy83 1y ago
    Do you have an example?
• raquuk 1y ago
  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.
  • stingraycharles 1y ago
    Which actually makes a lot of sense, to hand over the orchestration / composing to systemd, since it’s not client <> server API calls (like with docker) anymore but actual userland processes.
    • solarkraft 1y ago
      It totally does! On the con side, I find systemd unit files a lot less ergonomic to work with than compose files that can easily be git-tracked and colocated.
      • mariusor 1y ago
        What makes a systemd service less ergonomic? I guess it needs a deployment step to place it into the right places where systemd looks for them, but is there anything else?
    • Cyph0n 1y ago
      Yep. It works even better on a declarative distro like NixOS because you can define and extend your systemd services (including containers) from a single config. Taking this further (self-plug), you can automatically map your Compose config into a NixOS config that runs your Compose project on systemd! https://github.com/aksiksi/compose2nix https://github.com/aksiksi/compose2nix
  • broodbucket 1y ago
    With almost no documentation, mind
    • raquuk 1y ago
• irusensei 1y ago
  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.
  • jpeeler 1y ago
    Haven't tested this yet, but --link support was just added: https://github.com/containers/buildah/issues/4325#issuecomment-3251167324 https://github.com/containers/buildah/issues/4325#issuecomme...
• mococa 1y ago
  I have ditched docker desktop on macOS for OrbStack.
  • chrisweekly 1y ago
    OrbStack looks pretty nice, BUT an $8/mo/user subscription? Blech.
    • otterley 1y ago
      Useful software that makes our lives more convenient is worth paying for--after all, it pays most of our salaries, doesn't it? It feels a little hypocritical for us to feed our families through our tech talent and then complain that someone else is doing the same.
      • chrisweekly 1y ago
        It's the subscription model that chafes. For SaaS? Ok, sure. But for a desktop app, I just don't like it. It might not be entirely rational. shrug
    • jbverschoor 1y ago
      vs $11 for docker? blech
      • elliottr1234 1y ago
        Honestly just the debug shell alone is worth a good amount of $. You can remotely run shell commands on your deployed docker container and install packages that are not available in the base image without modifying the base image which can be a life saver. https://docs.orbstack.dev/features/debug https://docs.orbstack.dev/features/debug Let alone the local resource monitor, increased, performance, automated local domains (no more complicated docker network settings to get your app working with local host), and more.
        • chrisweekly 1y ago
• 1a527dd5 1y ago
  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.
  • goku12 1y ago
    > ... how to debug yet another layer of abstraction. > Remove layers, keep things simple. Due to the first line above, I'm not sure if I'm reading the second line correctly. But I'm going to assume that you're referring to the OCI image layers. I feel your pain. But honestly, I don't think that image layers are such a bad idea. It's just that the best practices for those layers are not well defined and some of the early tooling propagated some sub-optimal uses of those layers. I'll just start with when you might find layers useful. Flatpak's sandboxing engine is bubblewrap (bwrap). It's also a container runtime that uses namespaces, cgroups and seccomp like OCI runtimes do. The difference is that it has more secure seccomp defaults and it doesn't use layers (though mounts are available). I have a tool that uses bwrap to create isolated build and packaging environments. It has a single root fs image (no layers). There are two annoyances with a single layer like this: 1. If you have separate environments for multiple applications/packages, you may want to share the base OS filesystem. You instead end up replicating the same file system redundantly. 2. If you want to collect the artifacts from each step (like source download, extract and build, 'make install', etc) into a separate directory/archive, you'll find yourself reaching out for layers. I have implemented this and the solutions look almost identical to what OCI runtimes do with OCI image layers - use either overlayfs or btrfs/zfs subvolume mounts. So if that's the case, then what's the problem with layers? Here are a few: 1. Some tools like the image builders that use Dockerfile/Containerfile create a separate layer for every operation. Some layers are empty (WORKDIR, CMD, etc). But others may contain the results of a single RUN command. This is very unnecessary and the work-arounds are inelegant. You'll need to use caches to remove temporary artifacts, and chain shell commands into a single RUN command (using semicolons). 2. You can't manage layers like files. The chain of layers are managed by manifests and the entire thing needs a protocol, servers and clients to transfer images around. (There are ways to archive them. But it's so hackish.) So, here are some solutions/mitigations: 1. There are other build tools like buildah and packer that don't create additional layers unless specified. Buildah, a sister project of Podman, is a very interesting tool. It uses regular (shell) commands to build the image. However, those commands closely resemble the Dockerfile commands, making it easy to learn. Thus you can write a shell script to build an image instead of a Dockerfile. It won't create additional layers unless you specify. It also has some nifty features not found in Dockerfiles. Newer Dockerfile builders (I think buildkit) have options to avoid creating additional layers. Another option is to use dedicated tools to inspect those layers and split/merge them on demand. 2. While a protocol and client/servers are rather inconvenient for lugging images around, they did make themselves useful in other ways too. Container registries these days don't host just images. They can host any OCI artifact. And you can practically pack any sort of data into such an artifact. They are also used for hosting/transferring a lot of other artifacts like helm charts, OPA policies, kubectl plugins, argo templates, etc. > So any alternative tooling that forces Docker to get it's act together is welcome What else do you consider as some bad/sub-optimal design choices of Docker? (including those already solved by podman)
• Tajnymag 1y ago
  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.
  • anilakar 1y ago
    SELinux-related permission errors are an endless nuisance with podman and quadlet. If you want to sandbox about anything it's easier to create a pod with full host permissions and necessary /dev/ files mounted, running a simple program that exposes minimal functionality over an isolated container network.
    • Aluminum0643 1y ago
      Udica, plus maybe ausearch | audit2allow -C, makes it easy to generate SELinux policies for containers (works great for me on RHEL10-like distros) https://www.redhat.com/en/blog/generate-selinux-policies-containers-with-udica https://www.redhat.com/en/blog/generate-selinux-policies-con...
  • bonzini 1y ago
    > podman had a much worse performance compared to docker on my small cloud vps. Can't really go into details though. Are you using rootless podman? Then network redirection is done using user more networking, which has two modes: slirp4netns is very slow, pasta is the newer and good one. Docker is always set up from the privileged daemon; if you're running podman from the root user there should be no difference.
    • Tajnymag 1y ago
      Well, yes, but rootless is basically the main selling point of podman. Once you start using daemons and privileged containers, you can just keep using docker.
• mehdibl 1y ago
  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!
• gigatexal 1y ago
  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 ;-)
• xrd 1y ago
  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.
  • nunez 1y ago
    I presume that the bulk of your issues are with container images that start their PID 1s as root. Podman is rootless by default, so this causes problems. What you can do if you don't want to use Docker and don't want to maintain these images yourself is have two Podman machines running: one in rootful mode and another in rootless mode. You can, then, use the `--connection` global flag to specify the machine you want your container to run in. Podman can also create those VMs for you if you want it to (I use lima and spin them myself). I recommend using --capabilities to set limits on these containers namespaces out of caution. Podman Desktop also installs a Docker compatibility layer to smooth over these incompatibilities.
    • xrd 1y ago
      This is terrific advice and I would happily upvote a blog post on this! I'll look into exactly this.
    • bsder 1y ago
      Is there a blog post on this somewhere? I'd really love to read more about it beyond just the official documentation.
• ktosobcy 1y ago
  Tried to migrate (M1 MBP) a couple of times and it wasn't working well resuting in reverting to docker...
• 2OEH8eoCRo0 1y ago
  I've been on Podman since 2019 since Docker didn't support Cgroups v2 for a very long time.
• ravenstine 1y ago
  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.
  • Hackbraten 1y ago
    Exactly this. Plus, I don’t see the point in babysitting a separate copy of a user space if systemd has `DynamicUser`.
• t43562 1y ago
  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!
  • goldman7911 1y ago
    You only have to worry about licences if you use Docker DESKTOP. Why not use RANCHER Desktop? I have been using it by years. Tested it in Win11 and Linux Mint. I can have even a local kubernetes.
    • seabrookmx 1y ago
      Why not use Docker Engine/CE on Linux so you don't have to run a VM?
    • lmm 1y ago
      Low-quality UX (e.g. you have to switch tabs and switch back if you ever want to see the current state of your containers, because it loads it once when you open the tab and never updates, and doesn't even give you a button to refresh it), lack of documentation, behavioural changes that happen silently (e.g. it autoupdates which changes the VM hostname, so the thing that was working yesterday doesn't work today and you have no idea why) and general flakiness.
    • mpawelski 1y ago
      I concur. My company is using Rancher Desktop on Windows machines. No problems. As long as you use don't care about GUI, and just use CLI dommands ("docker" , "docker compose" ).
  • deleted 1y ago
    [deleted]
  • ac130kz 1y ago
    It's works great until you need that one option from Docker Compose that is missing in Podman Compose (which is written in Python for whatever reason, yeah...).
• crinkly 1y ago
  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?!?
• cramcgrab 1y ago
  Isn’t Portman ibm?
  • aargh_aargh 1y ago
    https://www.redhat.com/en/about/press-releases/ibm-closes-landmark-acquisition-red-hat-34-billion-defines-open-hybrid-cloud-future https://www.redhat.com/en/about/press-releases/ibm-closes-la...
  • johannes1234321 1y ago
    Podman is created by RedHat, thus IBM.
• GrumpyGoblin 1y ago
  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.
  • dpkirchner 1y ago
    I've had similar issues using kubectl to access some tools that made a lot of requests (polling, which is something argocd does I believe). Setting this environment variable helped a lot: KUBECTL_PORT_FORWARD_WEBSOCKETS=true Note: because Google's quality is falling you won't be able to find this variable using their search, but you can read about it by searching Bing or asking an LLM.
• jbverschoor 1y ago
  Whenever I see portmappings I die a little inside. OrbStack makes so much more sense be default
• kodama-lens 1y ago
  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
• vb-8448 1y ago
  i'm the only one that wished docker swarm became the standard instead of k8s?
  • skor 1y ago
    no, wish swarm had a feature or two more, but I'm happy with how simple it is.
    • vb-8448 1y ago
      the sens of my comment was: I would have liked that k8s looks like swarm.
  • papascrubs 1y ago
    Swarm syntax is much better than the YAML sprawl of k8s. That said the underlying engine was pretty buggy and lack of customization for lower level components was a pain. Their whole plugin system was a great idea, but actual plugins developed by vendors ended up being very brittle. That said, yeah I'd prefer that timeline
    • notpushkin 1y ago
      I’m still using Swarm personally and agree 100%. I’ve dealt with a fair bit of Swarm internals for https://lunni.dev/ https://lunni.dev/, and I’m ready to switch to k8s any moment. Don’t wanna lose Compose Spec support though, so I’ve started an IaC thingy that can map it to both k8s and Swarm resources. (Now I need to find some time for it!)
  • leetrout 1y ago
    Or Nomad...
• mrighele 1y ago
  > 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.
  • vbezhenar 1y ago
    I disagree with you on that. Kubernetes YAML is on the same level of complexity as docker compose and sometimes even easier. But verbosity - yeah, kubernetes is absolutely super-verbose. Some 100-line docker-compose could easily end up as 20 yamls of 50 lines each. kubectl really needs some sugar to convert yamls from simple form to verbose and back.
    • physicles 1y ago
      We have about 30 services running in 4 environments, including dev. I desperately want a better kustomize that removes most of the boilerplate and adds linting (like, every process should have a ram limit, but no cpu limit). I estimate about 75% of the lines of YAML are redundant.
      • ThatFave 1y ago
        Have you thought about using jsonnet? It has a good library for k8s (https://jsonnet-libs.github.io/k8s-libsonnet/ https://jsonnet-libs.github.io/k8s-libsonnet/). I like how I don’t need to worry about white spaces and how I can use functions to reduce boilerplate. For an example environment: https://github.com/ThatFave/homelab https://github.com/ThatFave/homelab
        • physicles 1y ago
          Is that intended to be a good example? There's still tons of duplication between the environments. Kustomize eliminates the vast majority of the duplication (i.e. a unique fact about the cluster being expressed in more than one place), it's just the boilerplate that's annoying.
• bryangrigorie 1y ago
  Docker daemon had been freaking me out for a while. If it's really so seamless I'll look into migrating.
• avereveard 1y ago
  same, not because compose, but because I wanted a software to run containers and docker only provides a solution
• fh973 1y ago
  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.
• mrits 1y ago
  My favorite part of the blog is how the author lets us know he is pretty young to reference vagrant as old.
  • codesmash 1y ago
    Thank you - you've made my day! Last time I felt like that when a lady asked my about the ID at the liquor store :)
  • the__alchemist 1y ago
    Vagrant was one of my first intros to programming (2 Scoops of Django tutorial). It and Chef were a nightmare that almost made me quit in frustration!
  • esseph 1y ago
    vagrant was released 15 years ago (2010) =)
    • mrits 1y ago
      About 20 years after the IRC crowd peaked which seems to be a large portion of this community
• usrbinbash 1y ago
  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.
• sc68cal 1y ago
  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.
  • osigurdson 1y ago
    Why not just use Kubernetes?
    • sc68cal 1y ago
      My workload is not dynamic
• hatch_q 1y ago
  Don't give iXsystems (TrueNAS) ideas. 3 times was enough.
• idoubtit 1y ago
  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).
  • rsyring 1y ago
    > Rootless networking is very slow I came across just how slow recently: - Container -> host: 0.398 Gbps vs. 42.2 Gbps - host -> container: 20.6 Gbps vs 47.4 Gbps Source: https://github.com/containerd/nerdctl/blob/main/docs/rootless.md#bypass4netns https://github.com/containerd/nerdctl/blob/main/docs/rootles...
    • codedokode 1y ago
      The slow speed is for using slirp4netns, not containers in general.
      • gm678 1y ago
        (and to be clear, podman 5.0 changed the default from slirp4netns to passt/pasta in 5.0)
  • gucci-on-fleek 1y ago
    > Rootless networking is very slow unless you install `passt`. If the software that you're running inside the container supports it, you can use socket activation [0] to get native performance. [0]: https://github.com/containers/podman/blob/main/docs/tutorials/socket_activation.md https://github.com/containers/podman/blob/main/docs/tutorial...
• diarrhea 1y ago
  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?
  • mixedbit 1y ago
    If I understand things correctly, this is Linux namespaces limitation, so tools like Docker or Podman will not be able to support such mapping without support from Linux. But I'm afraid the requirement for UIDs to be mapped 1:1 is fundamental, otherwise, say two container users 1000 and 0 are mapped to the same host user 1000. Who then should be displayed in the container as the owner of a file that is owned by the user 1000 on a host?
  • teekert 1y ago
    This. And then some way to just be “yourself” in the container as well. So logs just show “you”.
  • privatelypublic 1y ago
    Have you looked at idmapped mounts? I don't think it'll fix everything (only handles FS remapping, not kernel calls that are user permissioned)
    • diarrhea 1y ago
      I have not, thanks for the suggestion though. A second challenge with the particular setup I’m trying is peer authentication with Postgres, running bare metal on the host. I mount the Unix socket into the container, and on the host Postgres sees the Podman user and permits access to the corresponding DB. Works really well but only if the container user is root so maps natively. I ended up patching the container image which was the path of least resistance.
• vbezhenar 1y ago
  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.
  • r_lee 1y ago
    have you tried nerdctl? its basically just the containerd cli which is close to k8s and etc. not a for profit thing, just following containerd spec
  • wyoung2 1y ago
    > huge uid didn't work in podman (like 1000000 I think) You're running into the `/etc/sub[ug]id` defaults. The old default was to start your normal user at 100000 + 64k additional sub-IDs per user, but that changed recently when people at megacorps with hundreds of thousands of employees defined in LDAP and similar ran into ID conflict. Sub-IDs now start at 2^19 on RHEL10 for this reason.
    • deleted 1y ago
      [deleted]
  • osigurdson 1y ago
    Instead of using compose, you can create Kubernetes like yamls and run with podman play kube. Of course if you have really large / complex compose files or just don't feel like learning something else / aren't using k8s, stick with docker.
• drzaiusx11 1y ago
  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?
  • osigurdson 1y ago
    Keep using docker, who cares. The article is concerned about CVEs, etc, but this doesn't matter for development very much. If you use k8s for anything, podman might help you avoid remembering yet another iac format.
    • drzaiusx11 1y ago
      My laptop isn't exposing any ports outside localhost, so all I care about is validation of my containers for local-only testing (similar use case to Docker desktop.) Colima would/should never be used in production for a number of reasons, but yeah it's great for local only development on a laptop.
    • cpuguy83 1y ago
      Concerned about cve's but doesn't pay attention to the massive list of cve's for rootless setups which have a much broader scope/impact.
• leoc 1y ago
  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.
  • 0_gravitas 1y ago
    I'm a fan of grammatical radicalism, the parens are appropriate if they're meant to convey a certain tone/voice in the writing, like a quick added-in-fragment after you're done saying the original title (as if you were giving a presentation).
    • deleted 1y ago
      [deleted]
    • leoc 1y ago
      It sounds as if what you want there is an em-dash.
      • 0_gravitas 1y ago
        Also valid--but I think both work.
  • unethical_ban 1y ago
    The HN title was altered from the exact title to a modified title that changes the meaning. I don't understand why.
  • osigurdson 1y ago
    "You should too" is the part that annoys me. I use podman but if you are happy with docker, fill your boots.
• manbitesdog 1y ago
  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 https://github.com/p8952/bocker/tree/master
• whobre 1y ago
  Tried a couple of times and gave up. Just didn’t work at all for too many containers
• duxbuse 1y ago
  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
• markstos 1y ago
  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#discussioncomment-13591433 https://github.com/containers/podman/discussions/20573#discu...
  • hvenev 1y ago
    What I personally do is User=per-service-user ExecStart=!podman-wrapper ... where podman-wrapper passes `--user=1000:1000 --userns=auto:uidmapping=1000:$SERVICE_UID:1,gidmapping=1000:$SERVICE_GID:1` (where the UID/GID are set based on the $USER environment variable). Each container runs as 1000:1000 inside the container, which is mapped to the correct user on the host.
• hyperpape 1y ago
  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-rootless-containers https://www.redhat.com/en/blog/user-namespaces-selinux-rootl... - https://www.redhat.com/en/blog/sudo-rootless-podman https://www.redhat.com/en/blog/sudo-rootless-podman I'd summarize these posts as "very carefully explaining how to solve insane problems."
  • Kerbiter 1y ago
    Fedora is rather aggressive in pushing Podman. They have their Cockpit control panel for Fedora Server, and they've simply made the Cockpit Docker plugin unavailable when it was working fine, because "use Podman integration plugin instead".
• CuriouslyC 1y ago
  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.
• rcarmo 1y ago
  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…
  • goku12 1y ago
    Which compose? Podman-compose [1] wasn't fully up to date with the latest compose-spec [2] the last time I checked it. However, the docker-compose v2 [3] (the one in Go, not Python [4]) is compatible with the Podman engine [5] and works like a charm for me. I have also had no issues with networking, permissions or volumes while running as non-root user. Are you simply facing issues setting it up, or are you hitting some bugs or missing features? [1] https://github.com/containers/podman-compose https://github.com/containers/podman-compose [2] https://compose-spec.io/ https://compose-spec.io/ [3] https://github.com/docker/compose https://github.com/docker/compose [4] https://github.com/docker/compose/tree/v1 https://github.com/docker/compose/tree/v1 [5] https://www.devopsroles.com/how-to-use-docker-compose-with-podman-on-linux/ https://www.devopsroles.com/how-to-use-docker-compose-with-p...
• Hizonner 1y ago
  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.
  • causal 1y ago
    I generally find rootless pretty easy, it's just annoying that it's an additional few steps. Feels like an afterthought when it should be the default.
    • phito 1y ago
      It's easy in theory. I'd say about 30% of my containers require root and just wouldn't work on Podman.
      • Hizonner 1y ago
        You can run containers as root under Podman. You just don't have to.
  • sroerick 1y ago
    I could not agree more with this, and I am baffled by most of the tech scene's complete ignorance of security in this regard
  • matesz 1y ago
    Rootless containers are a pain but only on mac, otherwise it’s just pure upside.
• gregors 1y ago
  Iv been using podman for around 2 years now without issue. Works great for my use cases.
• tannhaeuser 1y ago
  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
• cyrialize 1y ago
  > 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!
  • mdaniel 1y ago
    In fairness, Vagrant solves a slightly different problem than does containerization, so I doubt the need went away but rather folks realized no one cares very much about fresh VM, rather it's all about the application configs Also, fuck them: https://github.com/hashicorp/vagrant/blob/v2.4.9/LICENSE https://github.com/hashicorp/vagrant/blob/v2.4.9/LICENSE who the fuck are they expecting to pay for Vagrant, or that "AWS gonna steal our ... vagrant?"
    • Dunedan 1y ago
      I'm so angry about that license change, as it makes impossible to use Vagrant anymore. For example the version of Vagrant in Debian is stuck to the pre-license change commit and Debian doesn't publish Vagrant boxes for new releases anymore. I've yet to find a replacement, which works as seamlessly across different operating systems.
      • mdaniel 1y ago
        Yeah, I was actually participating in a soft-fork for a while but I think the project ran out of steam. My guess is that it's very hard to pay attention to something that you don't use every day, so they let it drift. But if you ever hear of someone starting up again, let me know I'm aware that I, too, could be the someone but like I said it's hard to dedicate all the time and energy when the last time I used vagrant was years ago I also just remembered that I haven't revisited the forks list to see if there's some meaningful activity https://github.com/hashicorp/vagrant/forks?include=active&page=1&period=1mo&sort_by=last_updated https://github.com/hashicorp/vagrant/forks?include=active&pa...
• der_gopher 1y ago
  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
• pnathan 1y ago
  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.
• EE84M3i 1y ago
  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?
• sirmike_ 1y ago
  ever try to dev with it on a Mac? haha. Nope. No thank you. Not sure if Windows has that issue.
  • mring33621 1y ago
    I'm using 'podman' with 'k8s/kind' on my M1 macbook and have had very few issues Maybe a couple quirks with TCP port access, but a quick convo with gemini helped me
• dingi 1y ago
  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.
• arein3 1y ago
  Reminder that docker still doesn't support nftables
• disqard 1y ago
  Does anyone here have more than "initial impressions" of systemd-nspawn? It seems chronically overlooked in these sorts of threads.
• giamma 1y ago
  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.
  • ehaughee 1y ago
    I also had issues with Podman on an M2 Mac. I'm currently using OrbStack as I had network performance issues with Colima (I have 10GbE between the Mac and a NAS). Outside that issue, Colima was awesome.
  • ehaughee 1y ago
    I also had issues with Podman on an M2 Mac. I'm currently using OrbStack as I had network performance issues with Colima (I have 10GbE between the Mac and a NAS). Outside that issue, Colima was awesome.
    • giamma 1y ago
      Thanks, I did not know OrbStack, will give it a try.
  • xtracto 1y ago
    This mirror my experience. Ive been testing podman over the few years since Docker changed its license. But every time there's some thing that just doesnt work. So i find myself always returning to docker
  • brikym 1y ago
    I had some issues with Colima (mac) and switched to Orbstack which fixed everything.
• pitah1 1y ago
  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 https://github.com/data-catering/insta-infra
• deleted 1y ago
  [deleted]
• lpln3452 1y ago
  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.