jrgd

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

Might take a little bit of effort to do a conversion if you’re locked into explicitly how Docker interacts with OCI containers, but over in the Podman camp you have two options.

• Cockpit with the Podman containers interface: a graphical web-based solution for managing podman containers and the rest of the system.
• Podman Quadlets: a config file-based way to manage Podman containers, volumes, pods, networks with custom SystemD units. Great if you want to version control your deployments.

Other than that, the more usable solutions I’ve tried of graphical Docker container management interfaces would be the ones in Unraid and Proxmox, though those solutions may not be suitable depending on your use case and have their own caveats to be aware of.

If Google kills AOSP, a lot more than just GrapheneOS will stop being able to exist lest some entity maintains a fork that diverges from Google’s path. Vendors that aren’t shipping in line with Play Services and the rest of the ecosystem as well as LineageOS and other custom ROM development teams will suffer as well.

This kind of decision would essentially kill adoption of Android in a good number of countries within a few years as well as be the end of Android adoption for anyone that cares about security and/or privacy. Yes, It would either kill or put a large burden upon GrapheneOS as a project, but that is also true for so many other projects in the ecosystem. If the developers shutter their AOSP usage due to upstream abandonment, the users will likely follow in the same pattern.