Rootless Docker or Podman for Omarchy 4.5?

I've been implementing two container proposals for Omarchy: rootless Docker and native Podman. I recommend rootless Podman with Docker Compose and optional Docker command compatibility for Omarchy 4.5. Quadlet fits the local services I want Omarchy to provide. Docker retains an advantage for tools tied to its exact engine, but moving to rootless operation has compatibility costs with either choice. Release validation is still underway.

Podman combines rootless containers with a daemonless native CLI: you manage containers as your user without a central engine daemon. Rootless Docker retains its daemon architecture, running both the daemon and containers in a user namespace. Both avoid the root-level privileges granted by the Docker group. Neither protects files you deliberately expose to a container.

The differences in our proposals are:

Service management is Podman's strongest argument here. Quadlet turns container and volume definitions into systemd services. Our new databases use it for lifecycle and dependencies, with persistent volumes and localhost ports. Docker's daemon instead owns container lifecycle; systemd manages the daemon. Podman's native CLI needs no central daemon, but TUI, Desktop and SDK clients use its socket-activated API. “Daemonless” does not automatically mean more secure.

Compatibility has several layers. Familiar run, ps, logs and exec commands cover similar work. The optional podman-docker package supplies the docker command, while SDKs connect through a separate Docker-compatible API. Neither promises identical engine behavior. Fresh installs use podman directly; Docker upgrades retain the compatibility layer for existing scripts and compatible package dependencies.

The proposals use the same Compose frontend. podman compose invokes an external provider; our Podman proposal ships Docker Compose as the default. This gives developers Docker Compose's parsing and CLI options with a rootless Podman backend, without installing Docker Engine. The optional shim also makes it available as docker compose. Networks, mounts, builds and API behavior still depend on the engine, so this reduces compatibility friction without promising identical behavior.

Dockerfiles are more portable than build tooling. Podman accepts Dockerfiles and uses Buildah code; Docker uses BuildKit. An ordinary Dockerfile may work with both while a pipeline depending on particular Buildx builders or cache behavior needs changes. Podman's buildx build alias does not implement every Buildx feature.

Rootless changes permissions in both engines. Root inside a container is mapped rather than being host root. Access to mounted directories depends on those mappings and host permissions; changing an alias cannot fix ownership. Rootless networking also has different machinery, and low ports or resource limits can require additional host configuration. Rootless Docker keeps Docker's API, but uses a separate socket and data store from rootful Docker. Both proposals need data migration and recovery paths.

Keeping Docker does not make the rootless transition free. An application that mounts /var/run/docker.sock assumes a rootful engine. Both rootless proposals use a different socket. Setting DOCKER_HOST selects the client endpoint; it does not rewrite a Compose bind mount. Applications that launch other containers need the correct socket mounted and accessible, regardless of which engine runs them.

ONCE, 37signals' application manager, runs as a user service in both proposals, with the appropriate engine socket and local unprivileged ports. Both use an Omarchy-maintained ONCE package; Docker API compatibility alone does not cover every backup and restore behavior. Existing rootful ONCE deployments require an explicit, verified backup/restore migration.

Windows remains an explicit exception in both proposals: the managed VM uses an authenticated rootful engine for KVM, TUN and its network setup. Its Podman helper retains Podman Compose separately.

Starting from scratch, I would choose Podman for its native service model, with Docker Compose for development projects. Rootless Docker remains a strong choice when workloads require Docker's exact API, BuildKit or Buildx behavior. Both need testing beyond installation and health checks.

For Omarchy 4.5, the comparison is shared rootless-transition costs plus engine-specific differences. We should count Podman's additional compatibility work honestly, without attributing every rootless failure to Podman. I favor its systemd integration, with tested migration, recovery and explicit handling of unsupported workloads as conditions of shipping it.