Docker run to Docker compose converter

Turn a one-off docker run into docker-compose.yml

All conversion runs locally in your browser

Last updated: February 7, 2026
Frank Zhao - Creator
CreatorFrank Zhao
Docker compose YAML will appear here...

Introduction / overview

The Docker Run → Docker Compose Converter turns a single docker runcommand into a Compose file you can commit, share, and run again later. It’s especially useful when you’ve tested something quickly in a terminal and now want a clean docker-compose.yml for your repo or homelab.

This tool runs entirely in your browser. Your command stays on your device.

Dev & homelab users

Convert quick experiments into a repeatable service definition.

Teams

Share a Compose file instead of a long command in chat.

Documentation

Make setup steps copy-pastable and version controlled.

If you’re working with ports or endpoints, you may also find our random port generator handy when picking a host port, and our URL parser helpful for checking the URLs you’ll hit after you bring the stack up.

How to use / quick start

  1. Paste your full docker run ... command into the input box.
  2. Check the generated docker-compose.yml output.
  3. Use Copy to paste it into your repo, or Download to save it.
  4. Review warnings for flags that are not translatable or not implemented yet.
  5. Run with docker compose up -d and validate behavior.

How to read the result

Compose output is usually structured as servicesyour-serviceports, volumes, environment, ...\text{services} \rightarrow \text{your-service} \rightarrow \text{ports, volumes, environment, ...}. If you’re new to Compose, focus on three things first: image, ports, and volumes.

Mini example (ports)

Suppose your command includes -p 8080:80. That means your host port is 8080 and the container listens on 80.

Ph=8080P_h = 8080\RightarrowPc=80P_c = 80\Rightarrowports entry="8080:80"\text{ports entry} = \text{"}8080:80\text{"}

In Compose, you’ll typically see it under ports\text{ports} as a string.

Step-by-step examples

Example 1: An Nginx container with a bind mount

Background: You tested an Nginx container locally, mapped port 80, and mounted a socket.

Input: docker run -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro nginx

Result: Compose includes ports=["80:80"]\text{ports}=[\text{"}80:80\text{"}] andvolumes=["/var/run/docker.sock:/tmp/docker.sock:ro"]\text{volumes}=[\text{"}/var/run/docker.sock:/tmp/docker.sock:ro\text{"}].

How to use it: Save the YAML, then start the stack with docker compose up -d.

Example 2: Restart policy

Background: You want the service to come back automatically after reboot.

Input: docker run --restart always -p 8080:80 nginx

Result: The converter maps restart policy into Compose. If you’re comparing policies, think of it as a mapping function r(always)=alwaysr(\text{always})=\text{always}.

How to use it: Keep the restart rule in Compose so teammates don’t forget it.

Real-world examples / use cases

Turning a “works on my machine” command into a repo artifact

Input: docker run -p 3000:3000 my-app

Result: ports=["3000:3000"]\text{ports}=[\text{"}3000:3000\text{"}]

How it helps: Commit the YAML so everyone runs the same thing.

Standardizing environment variables

Input: docker run -e NODE_ENV=production -e PORT=8080 my-app

Result: environment={NODE_ENV:production,PORT:8080}\text{environment}=\{\text{NODE\_ENV}:\text{production},\text{PORT}:8080\}

How it helps: Move env into the Compose file so it’s visible and reviewable.

Avoiding accidental secret sharing

Input: docker run -e API_KEY=... my-app

Result: Use .env for secrets\text{Use .env for secrets}

How it helps: Replace literal values with Compose env files and keep secrets out of chat logs.

Tip: if you ever need to generate an HTTP header for protected endpoints during testing, our Basic auth generator pairs nicely with Compose-based local stacks.

Common scenarios / when to use

You have a long docker run

Convert it into a readable, reviewable YAML file.

You need documentation

Compose is easier to paste into READMEs and wikis.

You want teammates to reproduce

Share one YAML instead of a command with hidden gotchas.

You’re iterating configs

Edit ports, volumes, env without retyping flags.

You want a file artifact

Download docker-compose.yml and keep it with your project.

You want fewer mistakes

Compose makes it harder to “forget” a key flag later.

When it may not be a perfect fit

Some docker run flags have no direct Compose equivalent, and others may require manual translation (especially advanced networking or runtime flags). Treat the output as a strong starting point, then review it before production use.

Tips & best practices

Quick checklist before you trust the YAML

  • Confirm the image name and tag are correct (avoid “latest” in production).
  • Validate every published port and make sure it’s reachable.
  • Review volume mounts: paths, permissions, and read-only flags.
  • Move secrets to a .env file or secret store rather than hard-coding.
  • Run it once and compare behavior with your original docker run command.

Avoid common mistakes

The most frequent issue is assuming the converter can infer everything. Compose and docker run are close cousins, but they’re not identical. If the tool reports “not translatable” or “not implemented”, that’s your cue to manually review.

Calculation method / formula explanation

This converter follows a simple principle: interpret your command flags, then emit the closest Compose fields. You can think of it as a transformation:

f(docker run command)    docker-compose.ymlf(\texttt{docker\ run\ command}) \;\rightarrow\; \texttt{docker-compose.yml}

Port mapping rule

A port flag like -p h:c becomes a Compose ports entry. For the common case:

p=h:cp = h:c\Rightarrowports=["h:c"]\text{ports}=[\text{"}h:c\text{"}]

Here hh is the host port and cc is the container port.

Volumes rule

A bind mount like -v /host:/container:ro becomes an entry undervolumes\text{volumes}.

Related concepts / background info

docker run vs docker compose

docker run is great for a quick test. docker composeshines when you want a repeatable setup: multiple services, shared networks, and version-controlled configuration.

Why warnings matter

When the converter reports that an option is not translatable or not implemented, it’s pointing out a gap between the command and what Compose can represent automatically. These messages are a feature, not an error—use them as a review checklist.

Frequently asked questions (FAQs)

Does the converter send my command to a server?

No. The conversion runs locally in your browser.

Why is my output empty?

The most common reason is an incomplete or non-standard command. Make sure it starts with docker run and includes an image name at the end.

What happens to unsupported flags?

The tool lists them as warnings. You can still use the YAML, but you may need to add manual equivalents or accept behavior differences.

How do I verify port mappings?

Compare your original flag -p h:c to the Compose entry. In notation:"h:c"\text{"}h:c\text{"} should match your intended host/container ports.

Should I commit secrets into docker-compose.yml?

Avoid it. Prefer environment files (like .env) or a dedicated secrets solution.

Can I share a link with my command?

Yes—use the Share button and enable “share with results”. Just be careful: if your command contains credentials, sharing the link may expose them.

Limitations / disclaimers

Treat the output as a starting point

Not every docker run option maps cleanly to Compose. Always review the generated YAML and test the resulting stack.

Security note

If your command includes tokens, passwords, or API keys, don’t paste it into screenshots or public links. Consider redacting sensitive values before sharing.

External references / sources

Docker run to Docker compose converter | CalculatorVast