Two services with a dependency
The network is not automatic, and depends_on has no flag
services:
web:
image: nginx:alpine
ports:
- "8080:80"
depends_on:
db:
condition: service_healthy
db:
image: postgres:16 Turn a Compose file into the equivalent docker run commands. Some of what Compose was doing for you has no flag, and the first one bites immediately.
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 Convert. 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 network is not automatic, and depends_on has no flag
services:
web:
image: nginx:alpine
ports:
- "8080:80"
depends_on:
db:
condition: service_healthy
db:
image: postgres:16Means a different directory once it is on a command line
services:
app:
image: myapp
volumes:
- "./data:/data"These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The default bridge provides no DNS, so a service referring to another by name gets a resolution failure that looks like the other container is down.
Instead:docker network create, then --network on every container.
There is no flag for it. Running the commands in order reproduces the short form, and nothing reproduces a health condition.
Instead:Run them in order, and make the application retry its connections.
Compose resolves them against the compose file; docker run resolves them against your shell's directory, and -v creates the missing path rather than failing.
Instead:Make them absolute before running the commands.
Every service in a project joins one network and reaches every other by service name. Run the same containers without that and a reference by name is a DNS failure.
So it is not enough to run the containers: they have to share a user-defined network, which you create yourself. That is the first line of the output here, and leaving it out is why a hand-converted stack cannot find its own database.
The short form waits for the container to start, which running the commands in order reproduces. The long form with condition: service_healthy waits for a healthcheck to pass, and there is no docker run flag for that at all: you would have to poll docker inspect yourself.
The short form is satisfied when the container starts, not when the database accepts connections. The real answer in both worlds is an application that retries its connections.
Compose resolves them against the compose file's directory; docker run resolves them against wherever you are standing. And -v creates a missing host path as an empty root-owned directory rather than failing, so the mount silently points at nothing.
Compose reads .env from the project directory and substitutes before parsing. Your shell knows nothing about that file, so the same expression expands differently, or to nothing.
A compose file describes services and relationships. A list of commands describes a sequence, and the relationships end up in a shell script or in somebody's head. Worth doing to understand what Compose was doing, or for a host without it. Not worth doing as a migration.