Bring a Compose file up to the Compose Specification. For most files the whole migration is deleting one line, and the rest is things that were always questionable.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Migrate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The version key, a fixed container name, and a depends_on that does not wait for readiness
version: "3.8"
services:
web:
image: nginx
container_name: my-web
depends_on:
- db
db:
image: postgres:16replicas is silently ignored, and deploy.resources is not
services:
web:
image: nginx
deploy:
replicas: 3These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It selects nothing and produces a warning on every command, which is how teams learn to ignore Compose's warnings.
Instead:Delete it. Nothing else changes.
It waits for the container to start, not for the service to accept connections, so the dependent starts too early and exits.
Instead:Use the long form with condition: service_healthy, and give the dependency a healthcheck.
docker compose up ignores it silently, so the file says three and one runs.
Instead:Use --scale on the command line, or accept one. deploy.resources is the only subkey Compose honours.
The 2.x and 3.x split existed because 3.x was written for Swarm and dropped keys 2.x had. The Compose Specification merged them, and the key that used to select between them is obsolete.
Which is noise on every up, down and config, and noise trains people to stop reading warnings. Deleting the line changes nothing else: v2 reads every file the same way regardless of what the key said.
They were the casualties of the 3.x split and are back at the service level in the specification. So you do not need a deploy block to set a memory limit outside Swarm.
replicas, placement, update_config and restart_policy under deploy are silently ignored by docker compose up. deploy.resources IS honoured, which is the confusing part: one subkey works and the rest are decoration.
A database container starts in a second and accepts connections some time later. The short form is satisfied by the first, so the application starts, fails to connect and exits. Everybody meets this once and concludes depends_on is broken; it is doing exactly what it says.
Services on the same network already resolve each other by name. The only remaining behaviour is an implied startup order, which depends_on says better.
Docker container names are unique per host, so a fixed one means exactly one replica and refuses to coexist with another project using the same name.