⌘ Config & DevOps

docker run to Docker Compose Converter

Convert one or more docker run commands into a Compose file (compose.yaml, no obsolete version key): ports, volumes, env, networks, healthchecks, GPUs and more.

Compose Specification Multiple services Named volumes & networks Secrets masked

Loading docker run → Compose…

What this page sends

Your input: Processed in this tab and not sent to a server.
Share links: Share links put a Base64 copy of your input and output in the URL itself (after #d=). Anyone with the link can read it, so don't share a link that contains secrets.
Editor: On desktop screens the code editor (Monaco) is downloaded from cdn.jsdelivr.net; phones get a built-in lightweight editor instead.
Page load: Loading the page requests HTML, scripts and images from ByteKiln, fonts from Google Fonts, and sends Google Analytics page views, tool-usage events and catalog interactions (tool/category IDs, result status and whether a click followed search — never your input, output or search terms). Privacy & sharing

How the docker run to Docker Compose Converter Works

Most container setups start as a docker run command in a README and end up in a compose.yaml. Translating by hand means remembering that -p becomes ports, -e becomes environment, --restart keeps its value, --health-cmd becomes a healthcheck test, --gpus becomes a deploy.resources.reservations.devices block, and that named volumes and networks must also be declared at the top level. This converter does that for one or many commands. It parses bash, cmd and PowerShell quoting (with line continuations) using the same tokenizer as the cURL converter, understands both "--flag value" and "--flag=value" as well as clustered short flags like -dit, and supports about sixty flags: ports, volumes and --mount, environment and env files, networks and network modes, restart policy, user, working directory, entrypoint and command, capabilities, devices, GPUs, healthchecks, labels, extra hosts, DNS, resource limits, ulimits, logging, tmpfs, sysctls and more. The output follows the current Compose Specification, validates against its JSON schema, masks secret-looking environment values as ${VAR} references if you choose, and lists every flag it could not convert.

Parsing

Commands are split per line (continuations with \, ^ or ` are joined), tokenized with the right shell rules, and read as docker run [options] image [command]. sudo and "docker container run" are accepted. Anything after && or ; on a line is ignored with a note.

Mapping

Each option maps to its Compose key; list options (ports, volumes, labels, cap_add…) accumulate. Services are named after --name, or the image name when there is none, and get container_name when --name was given. Keys are written in a conventional order: image, name, restart, command, environment, ports, volumes, networks, and so on.

Top-level resources

Named volumes are declared under volumes:. User-defined networks are declared under networks: with a comment explaining external: true for networks that already exist. host, none and container:<name> become network_mode.

Validation

The test suite converts Postgres, Redis and Nginx commands among others, parses the YAML and validates it against the official Compose Specification JSON schema. Values that YAML would misread — port mappings like 80:80, yes/no, numbers-as-strings — are quoted.

Limitations

Only docker run commands are converted; docker build, docker network create and other commands after && are noted and skipped.
Flags without a Compose equivalent are listed rather than guessed, and --env-file contents are referenced, not read.
Several commands become services in one file, but depends_on and healthcheck-based start order can't be inferred — add them if one service needs another.
Secrets typed into the command are copied into the YAML; move them to an .env file or Docker secrets before committing.

FAQ

Short answers for the things developers usually ask before trusting a tool.

Is my command uploaded?

No. The conversion runs in your browser, which matters because docker run commands often contain passwords in -e flags. Share links are turned off when the command contains what look like secrets.

Why is there no "version:" line?

The top-level version key is obsolete. Docker Compose v2 follows the Compose Specification, ignores version and warns about it. The generated file validates against the Compose Specification JSON schema.

What happens to -d, -it and --rm?

-i and -t map to stdin_open: true and tty: true. -d (detached) and --rm have no key in a Compose file: you get detached mode with "docker compose up -d", and one-off removable containers with "docker compose run --rm". The output includes a comment explaining this rather than silently dropping them.

How are volumes handled?

Bind mounts (paths starting with /, ./ or ~) stay as they are, and $(pwd)/x becomes ./x because Compose resolves relative paths from the compose file's folder. Named volumes (-v pgdata:/var/lib/postgresql/data) are also declared under the top-level volumes: key so Compose creates them. --mount is converted to the long volume syntax.

What about several containers that talk to each other?

Paste several docker run commands, one per line. Each becomes a service, and a shared --network becomes a top-level network. Within one Compose project, services can reach each other by service name, so --link is no longer needed.

Which flags aren't converted?

Anything without a Compose equivalent (like -P, publish all) or not recognised is listed under the output instead of being dropped silently. Check that list before relying on the file.

Related tools

Useful follow-ups when one conversion usually turns into three more.

config-devops