Docker Run to Compose

Inheriting a project's setup as a long docker run command and being expected to maintain it is a productivity killer compared to a clean compose file.

Paste a docker run command — including ports, volumes, environment variables, networks, restart policies, and image — and the converter produces an equivalent docker-compose.yml service definition. Multi-line commands with backslash continuations are handled, as are the various short and long-form flags (-p vs --publish, -e vs --env).

Flags that don't have a clean compose equivalent — such as --rm or --interactive — are flagged in the output with a comment, since they typically don't make sense in a compose context where containers are expected to be long-lived. The output uses compose schema version 3.8, which is widely supported by recent Docker and Podman releases.

The parser walks the docker run command token by token. Single-character flags (-p, -v, -e) are paired with their next argument. Long-form flags (--publish, --volume, --env) work the same way. Flags without arguments (--rm, --interactive, --tty) are toggles. After all flags are consumed, the next token is the image name, and everything after that is the container's command. The output is a YAML structure with these fields mapped to their compose equivalents — ports, volumes, environment, image, command, depends_on, networks.

Worked example: paste 'docker run -d --name web -p 8080:80 -v /data:/var/www -e DEBUG=true nginx:alpine'. The converter produces: ``` services: web: image: nginx:alpine ports: - "8080:80" volumes: - /data:/var/www environment: DEBUG: "true" restart: unless-stopped ``` The -d flag is implicit in compose (services run detached by default). The container name becomes the service key. Restart policy defaults to unless-stopped because the typical compose use case is long-running services.

The pain that drives this: inheriting a project with a docker-run.sh script that's grown 40 lines of flags over years of additions. Reading it is fine; modifying it without breaking something is hell. Compose files are declarative, version-controllable, and separate concerns into discrete services. Converting once gets you to a maintainable starting point. After that, you fix the conversion's quirks and live with a sane setup.

Where it can't help: docker run commands that depend on shell features. Subshells in environment variables (-e PATH=$PATH:/extra), command substitution, runtime interpolation — these don't translate to YAML directly. Compose has its own variable substitution syntax (${VAR}) and reads .env files, but the migration from shell to compose syntax can require manual intervention. The converter flags these cases rather than silently mistranslating them.