Every declared Compose dependency on this eight-server fleet ends in :false

Compose v2 writes `com.docker.compose.depends_on` onto a container at create time, and the value is the resolved dependency in the form `service:condition:restart` ^[4]. Reading the label beats reading the YAML on disk, because the label records what the running container was actually created with ^[4]. The last token is the restart flag, and `false` means: when Compose updates the dependency, do not restart me ^[7]. Seven containers on this fleet declare a dependency at all, all seven wait for `service_healthy`, and all seven end in `:false` ^[6].

The specification scopes the flag narrowly. `restart: true` means "Compose restarts this service after it updates the dependency service" ^[10], and the update in question is the `docker compose up -d` that swaps a container for one on a new image ^[11]. Runtime crashes are covered by the restart policy instead ^[11]. So `condition` sets the order on a cold boot, and `restart` decides what happens to a service when the thing underneath it is replaced ^[12].

The post's own illustration is a server that boots once a year and deploys twice a month ^[13]. Twenty-four deploys plus one boot is 25 ordering events in a year, so the declared health conditions govern one of them, about four percent ^[14].

The 2026-07-31 incident is the case the flag covers. Postgres was healthy on the question its healthcheck asked, which was whether it accepted connections ^[16]. The n8n main container and the worker both came up against that database and both began running migrations; main won, and the worker died on a half-applied schema with its stack trace in `MigrationExecutor.executePendingMigrations` ^[15][16]. It went unhealthy and stayed there ^[15]. Rewriting the Postgres healthcheck cannot help, because whether the application's schema is current is a fact about the sibling container doing the migrating ^[17].

Switching the flag on changes deploy behaviour. Because restart fires when Compose updates the dependency, a worker declared `restart: true` will restart on every deploy that replaces main, including the bumps that migrate nothing ^[21]. The hand-typed step has the same effect on the deploys where someone remembers it ^[1][18]. The post's author wrote: "My runbook is a human being standing in for one boolean." ^[20]

The author declared the dependencies being audited, so the zero describes one operator's defaults on eight servers running clients' work ^[22][3]. For it to say anything about other fleets, the same label pull would have to come back the same way on Compose files other people wrote. Thirty-one of the 38 containers carry no `depends_on` at all, and the post sets those aside as a separate question ^[8]. Its account of the 2026-09-04 engine upgrade, where live-restore carried every container through 29.7.2 to 29.8.0 at 8, 5 and 3 per host, ends mid-sentence ^[19].