Concept and mechanism
Compose describes services and the relationships needed to run them. Startup order and readiness are different properties. A started dependency may still be recovering files or preparing connections. service_healthy allows waiting for the healthcheck defined for that dependency. The value of waiting depends on what the check measures: checking a process does not establish a complete transaction. service_completed_successfully serves a dependency that must finish successfully, such as approved initialization. Keep unavailability handling in the application because the dependency can also fail after startup. Review configuration alongside effective environment values, supported versions, and access granted to each service.
Guided application
In a fictional example, a test job requests daemon socket access to list containers. With a rootful daemon, docker group membership grants elevated privileges; the group name does not restrict the API to reading. Evaluate an integration providing only required information or an isolated executor appropriate to the work. Running the application as a non-root user limits some access but does not neutralize a privileged socket granted to the process. Rootless also changes daemon privileges and uses user namespaces; it is not equivalent to declaring USER in a Dockerfile. Review mounts, networking, and capabilities together and avoid privileged as a generic solution to an undiagnosed permission problem.
Database running at 09:00, ready at 09:01: a started dependency does not guarantee a connection at 09:00.
Common pitfalls
Order as readiness; USER as rootless; socket as read-only access; privileged as diagnosis.
Related topics: Processes and images · Build and distribution · Networking and access
Connect each dependency to an observable condition and each access to a need.
Reference: Compose dependency readiness · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped