Docker Run to Compose Converter

A long docker run command works once. As soon as you need to remember it tomorrow, share it with a teammate, or run it alongside a database container, you need docker-compose. This converter takes a docker run invocation and produces an equivalent compose.yml snippet — saving you the field-by-field translation.

The translation map

• -p 8080:80 → ports: ["8080:80"]
• -v $(pwd)/data:/data → volumes: ["./data:/data"]
• -e DEBUG=1 → environment: { DEBUG: "1" }
• --restart unless-stopped → restart: unless-stopped
• --name api → service key api:
• --network mynet → networks: [mynet] (with networks block at top level)
• -d → no equivalent (compose runs detached by default with up -d)
• --health-cmd → healthcheck: { test: ... }

Why move to compose

• Repeatability. Anyone with the file can recreate the stack in one command. No more "what flags did I use last time?"
• Multi-container apps. An API + Postgres + Redis stack lives in a single file with explicit dependencies (depends_on).
• Networking. Compose creates a default network where every service can reach every other by service name. No more IP addresses.
• Version control. Compose files commit cleanly into the repo.
• Local dev / staging parity. The same compose file (with overrides) drives local laptops and staging EC2 hosts.

Pitfalls during conversion

• Default network conflict. Compose creates a project-named bridge network. Containers on the legacy bridge network can't reach compose services without an explicit network shared.
• Volume mount paths. $(pwd) in docker run resolves at command time. In compose, ./data is relative to the compose file's directory.
• Environment file vs flags. Many -e flags compress nicely into env_file: .env.
• Ports vs expose. ports publishes to the host. expose only allows other compose services to reach the port. Choose deliberately.
• Privileges. --privileged, --cap-add, and SELinux flags translate but should be reviewed before keeping.

When to skip compose entirely

For production at any scale, compose is a stepping stone — not a destination. Production wants Kubernetes, ECS, or Nomad with proper rolling deploys, secrets management, and observability. Compose is right for laptop-local dev, single-host staging, and CI test fixtures. Past that, see our guide on running secrets-aware workloads on Kubernetes.

Frequently Asked Questions