You can use the same containers with Podman, but docker-compose is not recommended with Podman and you rather use Quadlets which integrate nicely with Systemd.

Docker’s main advantage is just being more well known and hence more supported as a default option.

Even then, I feel that this availability of docker compose files is an illusion, due to their verbosity and limitations inherent to docker. Less granular control of permissions, clunkiness in updating images, and multi container stacks feeling like an afterthought.

In pretty much all other ways podman feels superior. Cockpit provides a basic web gui, but quadlets are the main draw. Way easier to configure, explicitly designed for multi containers, and updating all images is a single command.

Roughly, the different ecosystems from least to most complex are:

Docker/Portainer -> Podman/Cockpit/Quadlets -> Kubernetes

Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn’t recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you’re best to take the compose file and write it out to Quadlet unit(s).

Other differences not mentioned can include:

• Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as localhost, 127.0.0.1, or ::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures.
• Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you’re not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
• Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
• Podman by default won’t shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the docker.io/ prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor.
• Podman can optionally let you auto-update containers based on the release tag specified for the container.
• Because of Podman’s integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).

Honestly, not entirely certain I did it right, but it was super easy. I literally spun up Komodo, spun down Portainer without shutting any of the other containers/stacks down, then added the same stacks back through the GUI option into Komodo with the same exact compose/title/env options. It literally just recognized that the containers that were already running on my server were the correct ones and “added” them back to the stack in Komodo. I vaguely remember reading that there is a more “correct” way to do it, but I only read about it after the fact.

I like the fact that there isn’t a distinction between the community edition and the business edition. Its all the same thing for Komodo, whereas I felt like Portainer had a bunc hof random things locked away behind the “Business Edition” and that just rubbed me the wrong way. If I’m self hosting something, I feel like I should be able to access all portions of it.

The GUI is a little different but once you’re used to it, I feel like it makes more sense for the most part. It has a nice way to connect other machines, so I can monitor all of the different machines in my network that are hosting things. I also wanted to mess around with some of the automation features, but I haven’t had as much time to dick around with that as I would like. I also wanted to start doing stuff from a personal Forgejo, and it was super easy to integrate. (No idea how easy it is on Portainer, as I had already jumped ship at that point)

I just recently switched from portainer to dockhand and I really like it. The UI is great and the setup and config wasn’t too complicated. I like that I can put both of my servers into one instance and can update all of my containers from dockhand vs manually. The other thing I like is being able to view the logs for my containers. Idk if it’s a me thing, but whenever I would try to view logs in portainer I would never be able to scroll up as it would update and send me back to the bottom. Again, I could’ve just been doing something wrong, but it always bothered me and I don’t have that issue with dockhand.

I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run helm install … either directly or via the CI and stuff is deployed.

So for example at my last job, our GitLab CI just had a section ran only when merging into master that ran helm install. We had three values.yaml files, one for each environment, and when we wanted to deploy a new version, the process was:

1. Create a tag for our release version (ie. 1.2.3) and push it to the repo. This would trigger a build and pus the resulting image into the container registry.
2. Push an update to the repo with the new tag set in the appropriate Helm values file. If we wanted to deploy 1.2.3 to development but not yet to staging or production, then the tag: value in each of the environment files would look like this:

• k8s/chart/environments/development.yaml: tag: 1.2.3
• k8s/chart/environments/staging.yaml: tag: 1.2.2
• k8s/chart/environments/production.yaml: tag: 1.2.2

Once that change is pushed, the CI will automatically apply it with helm install … and make sure that all three environments are what they’re supposed to be.

As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:

The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:

#!/bin/sh

while ! nc -z postgres 5432; do
  echo "Waiting for postgres..."
  sleep 0.1
done
echo "PostgreSQL started"

touch /tmp/ready

exec "$@"

I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.

you will have to spend a lot of time learning the Nix language

I’d say you shouldn’t use any system (be it nixos, ansible or even bash scripts) if you are not willing to learn it.

That said, I too find pre-made modules less useful that I initially thought when I got into nixos: unless you want to do very basic stuff, a lot of times it’s easier to just generate whatever scripts/configuration files you need directly (using one of the trivial builders in lib or writing a custom derivation) rather than learning how the corresponding nixos module works.

One could say nixos modules make easy things slightly easier, and hard things much harder (this is adapted - possibly imprecisely - from a quote on ORMs, I think by Joel Spolsky).