Docker Run → Compose

about this tool

docker run → compose

The command is split the way a shell splits it — double and single quotes, escapes, and \ line continuations — so a quoted health check or a sh -c command survives intact. Then each option is looked up in a table that follows the docker run reference: long names with = or a space, short names attached or apart (-p8080:80, -eKEY=value), and clusters of short boolean flags (-dit). Everything after the image is the command, kept as a list so arguments with spaces stay single arguments.

Two things about the table are worth knowing. Named volumes are declared in a top-level volumes: section because Compose refuses to start without that; a bind mount (a source beginning ./, /, ~ or a Windows drive) needs nothing. And a --network name is declared external: true, because docker run assumes the network exists; delete that line to have Compose create it. --mount specs are converted to the short source:target:ro form, tmpfs mounts to tmpfs:, --gpus all to a deploy reservation.

There is no version: line. The Compose specification made it obsolete.

What is reported rather than dropped

-d is dropped without comment, since docker compose up -d is where that lives. Everything else with no Compose equivalent is listed under the output: --rm (use docker compose run --rm or down), --publish-all, --gpus with a device list, and any option the table does not know. --link is kept but flagged as legacy, since services on a Compose network already reach each other by name.

compose → docker run

Each service becomes one docker run -d command, named after container_name or the service key, with environment, labels, sysctls and extra_hosts accepted in either the map or the list form, health checks in the CMD or CMD-SHELL spelling, and ulimits as a number or a soft/hard pair. Arguments are single-quoted only where a shell would otherwise split or interpret them. Keys with no docker run equivalent — build, depends_on, deploy, profiles, configs, secrets — are listed per service. A service with build: and no image: gets its name as a placeholder image, with a note.

The "use output as input" button feeds a conversion back the other way, which is a quick way to see what a round trip preserves: the sample does, flag for flag.

Limits

One command at a time in the forward direction; docker compose run and docker exec are not docker run. Long-syntax volume entries in a Compose file are not converted back. Neither direction validates values — a port of abc:def is passed through as written — and neither knows anything about the images themselves.

questions

Why is there no version: line in the output?

The Compose specification made it obsolete. Modern Compose ignores it, and a "3.8" at the top invites people to look up what that version allowed. Leave it out; the file is read by the spec, not a version.

What happened to --rm?

Compose has no such flag on a service: containers from `docker compose up` are removed by `docker compose down`, and one-off jobs use `docker compose run --rm`. The tool says so under the output rather than dropping the flag silently.

Why did a named volume get a volumes: section at the bottom?

Because Compose requires every named volume to be declared at the top level, or it refuses to start. A bind mount — a path starting with ./, / or ~ — needs no declaration. The tool tells the two apart the way Docker does.

Why are networks marked external: true?

A docker run --network name assumes the network already exists, so the conversion declares it external to match. If you would rather Compose create it, delete external: true.

Can it convert a whole compose file back?

Yes: each service becomes one docker run command, and keys with no docker run equivalent — build, depends_on, deploy, profiles, configs, secrets — are listed per service. The commands do not create the network that lets services find each other by name; that is what Compose does for you.