Podman Desktop: A Free OSS Alternative to Docker Desktop

Replaced Desktop with `colima` as well few months ago. I've been using it daily since then. I did not have any issue, sometimes I just delete / start a instance to upgrade the docker version, it only takes few minutes.

I like the fact that I decide when I upgrade, not Docker Desktop nagging me every week.

Looking to convert, but I still can't understand how this is more performant. Docker Desktop has lots of engineering going into performance crossing the host/VM barrier. IIRC lima just pipes over SSH. How could that be faster?

Best part: it's QEMU so you can choose your CPU architecture and run x86_64 containers on ARM Macs

my personal experience. Much earlier this year at work, we migrated everyone to colima and I had to support devs with their issues. So many small issues kept popping up, and was definitely not a drop in replacement for us.

The higher ups eventually let us just buy docker desktop and we are all happier now.

Please help me understanding: Why is `brew install docker` not sufficient, why do you also need Colima or Docker Desktop? Is it so that there is a docker _daemon_ installed which `docker` doesn't ship with?

Same. My requirements are very basic, so the switch to colima was basically seamless. I also appreciated being able to avoid Docker Desktop constantly trying to update itself (which is what ultimately motivated me to make the switch).

As a bonus, you can install the Docker CLI (e.g. `brew install --formula docker`) and use that to interact with any containers you start with colima.

Switched to colima a while back after the licensing debacle and have been mostly happy with it. Only real issue has been with some tools making assumptions about the docker socket location, which was easy to fix in the config file.

Thanks for sharing. I missed something like that. Docker is too enterprisy to my taste. I'm using VPS with docker right now which works good enough, but no volume mounts is not very nice.

> For personal use I found it great and lighter than Docker Desktop.

I don't know what Docker Desktop is doing but on a top end i9 with 128gb of ram it still takes 60 seconds to start

and the UI takes forever to do anything

it makes Teams look responsive

You can use wsl-gvproxy(*), which uses our CRC usermode network stack to allow use with VPN. We are working on making this an option for podman machine. Alternatively, or to test, you can use CRC from our crc-org project and run the podman preset. This uses a dedicated VM using native hypervisors and the gvproxy setup.

I am the teamlead of CRC and work on the Windows enablement of podman machine, with the podman desktop team. Gladly take questions here or by email.

(*) also known as wsl-vpnkit

I had similar issues with a different VPN/Proxy at an earlier role. I solved with https://github.com/sakai135/wsl-vpnkit and trusting the root certificate of the proxy on the rancher desktop WSL2 vm (Assuming you're on Windows as I was).

Docker desktop pays for itself by solving these issues though IMO (I wasn't able to get a licence at the old role however)

I suppose Docker Compose won‘t work with those alternatives?

At the moment podman machine on macOS uses Qemu and their filesharing stack. Qemu allowed us to move quickly utilizing the same deployment stategy. However I work on CRC (a related project) and we have a driver based on virtualization framework using virtiofs. We hope to integrate this in `podman machine` soon as it will improve performance. Ideally we want to boot with the kernel and ramdisk provided by the image, though this isn't the case until macOS 13 (which brings EFI support). So, yes... hopefully soon. We just want to make sure we provide a stable and maintainable solution.

I work on the Windows enablement team of podman machine andam glad to take question or feature requests.

We are looking into enabling systemd, though as said, this isn't GA yet. The functionality would only work for Win11, so we have to enable a win10 workaround for this (we have), but this has to be based on feature detection.

Arm binaries is being looked at, but can't commit to a timeframe when this will be delivered.

I've been running Docker on WSL 2 for a while now, without systemd or Docker Desktop. There's no need to wait for systemd.

You can install Docker following their Linux guide and then in your shell's profile file add:

    if grep -q "microsoft" /proc/version &>/dev/null; then
        if service docker status 2>&1 | grep -q "is not running"; then
            wsl.exe --distribution "${WSL_DISTRO_NAME}" --user root \
                --exec /usr/sbin/service docker start >/dev/null 2>&1
        fi
    fi

Been running Docker under WSL for a few years. Don't need systemd if you're either happy to start it manually with an alias or poke it into one of your profile/logon scripts.

The experience is light-years ahead of the monstrosity that is Docker Desktop

Thanks for this! I was curious if the windows dev kit would be a good arm64 container build box, but I wasn't sure if getting Docker or buildah etc. on there would be a pain. Sounds like this is totally doable.

Podman Desktop will release Windows arm64 binaries if there is a demand for it

I've been using this approach for some time on my Pro X. I wrote a script to start the docker daemon on first shell startup prior to systemd support.

> This isn't a problem with Docker, which has tight control over what is deployed.

That contention is heavily dependent upon how Docker was installed. Docker desktop, yes. Command line Docker on Linux? That used to be much more complicated and depended on if you had an OS vendor provided version or had a Docker provided repo install.

RHEL’s repo version always seemed particularly out of date to me.

> The problem with podman at the moment (IMO) is version drift. RHEL/Fedora and friends get the latest and greatest (4), Debian/Ubuntu are stuck on 3.x.

Podman has no control on this. Each Linux distribution deals with packaging in its own way. If this packaging is not to your taste, podman can easily be installed from alternatives sources: unofficial deb packages, or plain binaries.

BTW, podman v4 is in debian/experimental. I don't know why it didn't land into unstable yet.

> This isn't a problem with Docker, which has tight control over what is deployed.

AFAIK, Docker (now Moby) has no control over what is packaged in Debian/Ubuntu (unless the Debian maintainer works for Moby?). If you install Docker from the official Debian repositories, the "docker" package is an alias for "docker.io", which is a version 20.10.19 in debian/unstable. The latest 20.10.21 is not yet packaged by Debian.

a workaround to get the latest and greatest podman on debian/ubuntu is to use opensuse's kubic repo - it's even mentioned on the podman installation page [0]. but they don't recommend it for production use (though i haven't noticed any issues so far on ubuntu 22.04 and 22.10).

[0] https://podman.io/getting-started/installation

It might be possible to use a Podman machine on Linux as well. ( You may loose performance but could update as soon it's available)

Or use https://software.opensuse.org/package/podman

If you want something as non-root to bind below 1024, there's a sysctl for it.[1]

Docker bypasses this essentially because it uses root privs to set up the port forwarding rules.

[1]: https://www.kernel.org/doc/html/latest/networking/ip-sysctl.... -> ip_unprivileged_port_start

Running into edge issues and always trying to figure out if it was my container, Podman, or SELinux is making me very close to installing regular docker.

I'm pretty sure the main reason there's a push to move from Docker Desktop now is because earlier this year they started charging larger businesses/teams to use it.

So if you're just using it for yourself you probably don't need to bother

https://www.docker.com/blog/updating-product-subscriptions/

For me the main reason to use Podman over Docker is rootless containers. Another one is also that Docker is really not pleasant to install on Linux.

Besides the licensing issues, I found it bloated and flaky. For me, the friendly GUI just added pain. I use docker in Hyper-V as my home media server instead. WSL2 also works.

They can run side by side and Podman Desktop is also able to show you all Docker containers, images, etc.

Google Mac hibernate issues. Over 1 million results. Windows, over 3 million.

I gave up on hibernation being a valid concept in the 1990's, there's too many things that can go wrong and computers are more complex today.I don't use hibernation and Docker has no issues.

huh, so that's what's happening to me. I was wondering what the likely cause of the kernel panic issue might be. This might be the impetus I needed to try one of these Mac docker alternatives.

You are probably referring to Sysbox (https://github.com/nestybox/sysbox), which I believe will meet your requirements (systemd, inner containers, security, etc).

Btw, Sysbox is already supported in Docker-Desktop (business tier only), so you can easily do what you want with this instruction:

$ docker run -it --rm -e SYSBOX_SYSCONT_MODE=TRUE ghcr.io/nestybox/ubuntu-focal-systemd-docker:latest bash

Disclaimer: I'm Sysbox's co-creator and currently working for Docker.

Not entirely sure about the usecase, but podman itself integrates well with systemd, like creating services. But it feels like you want a full systemd OS in a container instead of a VM. Not the best practice. VM might better for this, though Podman can run systemd based services. And Podman in docker or podman in podman is not an issue.

https://blog.while-true-do.io/podman-systemd-in-containers/

Podman machine starts a VM that is just a Fedora distro, with systemd and you can create multiple instances. This way you can run these system containers easily.

systemd-nspawn, LXC, and podman should all be able to do that (though doing recursive containers can be kind of weird). In theory https://github.com/firecracker-microvm/firecracker should as well, it runs very lightweight VMs.

kind (kubernetes inside docker) does this by building a specialized container that includes and uses systemd as the entrypoint:

https://github.com/kubernetes-sigs/kind/blob/main/images/bas...

You could run this as a standalone container

      docker run --rm -d --name my-node --volume=/lib/modules:/lib/modules:ro --volume=/var --volume=/kind  --privileged docker.io/kindest/node:v1.25.3

      docker exec -it my-node bash

Proxmox allows you to launch LXC containers via a UI. I use it at home and I'm able to run Docker in both a privileged LXC and an unprivileged LXC.

LXC/LXD are probably the closest to that on Linux, although I'm not sure about nesting containers.

"these “system” containers should be able to run containers inside them as well (docker in docker?)."

I think you can run podman in podman. But your comment actually makes me wonder how easy it would be to run docker/podman in chroot

One more vote for LXD/LXC. Very neat and quick