How osprey up picks a compose command shape Before starting anything, osprey up asks the runtime which compose implementation stands behind it and reads the banner that comes back. Docker Compose v2 is handed the rendered files where they sit, one -f each, with both env files. podman-compose is handed one merged document at the repository root with one merged env file. Anything else is refused before a single container is touched. osprey up read the compose banner the provider that parses the command, not the binary that forwards it Docker Compose v2 any 2.x release podman-compose ≥ 1.0.6 EPEL 8 ships 1.0.6 as standard anything else v1 · unknown banner · probe failed -f build/services/<svc>/docker-compose.yml one -f per rendered file, where it sits --env-file .env.shared --env-file .env -f .osprey-compose.yml every file merged into one, at the repo root --env-file build/.env.merged COMPOSE_PROJECT_DIR=<repo> refused before a single container is touched why the merge exists: podman-compose 1.0.6–1.3.0 resolves relative paths against the first -f file's directory, 1.4.1 and newer against COMPOSE_PROJECT_DIR — same inputs, different result, and no error on either version