Docker Compose Generator

Recreating a container takes more than remembering its image name. The application may also depend on a host port, a data directory, environment values, and a restart policy. Docker Compose records these choices in YAML, a text format whose indentation describes structure, so the service configuration can be reviewed and reused.

A Compose file can describe a single application or several cooperating services. It is useful for a development API, a background process, or an application that needs the same configuration after a container is replaced. Three terms help explain what the file controls.

Image

The packaged application and filesystem from which Docker creates a container. An image reference selects an existing image; a build context supplies files for building one.

Service

A named definition of how Compose should create and run a container, including its image, arguments, connections, and storage.

Project

The group of services and resources managed together. Project names normally help distinguish network and volume resources belonging to different applications.

For a web application, the container's listening port and the host's published port serve different purposes. Mapping host port 8080 to container port 3000 directs connections to the application's listener. A loopback binding such as 127.0.0.1:8080:3000 restricts that host binding to the local machine. Omitting the host address normally publishes on all host interfaces. Leaving a port unpublished still allows networking within the container's network and does not itself disable outgoing connections.

Storage needs a separate decision. A named volume identifies data managed by Docker, while a bind mount connects a host path to a path inside the container. The resource name or source path determines which data the application sees. A read-only mount prevents writes through that mount; making the container's root filesystem read-only is a different setting. Applications that write logs, caches, or temporary files may still need writable mounts.

Environment variables supply application settings, but a reference such as ${API_TOKEN} only asks Compose to substitute a value. It does not encrypt the value or create a Docker secret. Similarly, choosing a versioned image tag makes the intended version clearer, but tags can change. A digest identifies particular image content.

Health checks and restart policies address different failures. A health check tests a condition inside the container, while a restart policy controls recovery after the container exits. Neither proves that the application can serve requests correctly. Moving settings from a terminal command into YAML makes them reviewable, but successful startup still depends on the image, supplied values, host resources, and actual application behavior.

How to Use This Tool:

Choose Manual to configure one service, or Docker run to review a supported command before accepting its conversion. The two drafts remain separate.

Configure a service manually

1. Enter a Service name and choose a published image or local build context under Runtime source. Replace the illustrative image reference with the image or directory you intend to use.
2. Set the application's network, environment, and storage requirements. The initial values bind host port 8080 to container port 3000 on localhost, include sample environment assignments and a named mount, and use unless-stopped. Replace or remove sample values that do not belong to your application.
3. Review the Compose file as valid edits update it. Use Advanced when you need a project name, a healthcheck command, or a read-only root filesystem. Correct any input error before copying the draft.

Convert a Docker run command

1. Paste one docker run or docker container run command into Docker run command. The supplied sample can be used to inspect the conversion before entering your own command.
2. Choose the import Secret handling policy under Advanced. The default creates references and setup placeholders for recognized secret-like keys.
3. Review Conversion review for the generated service name, host binding, mount identity, environment overrides, and any required local setup. A valid preview can be inspected and its review table exported before Apply. Blocking diagnostics prevent a successful conversion.
4. Click Apply reviewed import to make the Compose file and its related results available.
   Changing the command or import secret policy makes the previous output unavailable. Review and apply the new version, or use Cancel to restore the last applied command and policy. Before any import has been applied, Cancel returns to Manual. Clear removes the import draft without changing the Manual draft.

For either route, save the Compose output and supply any referenced environment values on your own machine before running docker compose config --quiet in its directory. Read any warnings as well as errors. Start the service deliberately with docker compose up, or docker compose up -d when detached operation is intended, after reviewing the configuration and local requirements.

Interpreting Results:

Compose draft ready to review means a draft is available for the current inputs. The line count includes internal blank lines and excludes the final newline. It measures file length, not completeness or deployment quality.

The Configuration ledger explains the generated settings. For an import, Conversion review additionally records preserved choices, generated names, duplicate environment overrides, and intentional changes such as replacing a literal secret with a reference. Check those changes against what the original command was meant to do.

The Readiness profile assigns six independent review scores. An area counts as ready at 80% or higher. These are Simplified Tools review priorities, not official Docker security scores, measured success probabilities, or deployment certification. A suitable application may intentionally have no mount, no automatic restart, or a public port.

Local Compose validation checks the configuration that Compose can resolve. It does not establish that an image is available, a port is unused, a host path has suitable permissions, or a healthcheck succeeds. Confirm those conditions on the intended host. The generator does not establish full runtime equivalence between a command and its converted file.

Technical Details:

Transformation Core

A Docker run command contains Docker options, an image reference, and optional application arguments. Conversion first recovers the quoted argument boundaries, reads supported options before the image, and preserves the remaining arguments as a YAML array. Environment assignments are resolved in order, the selected secret policy is applied, and the resulting service is written as Compose YAML. Unsupported input blocks the whole conversion rather than producing a partially translated file.

The following mappings define the supported import. Long options that take a value accept either a separate operand or --option=value. Short options that take values require a separate operand.

Every supported option except environment assignment may occur at most once, even if repeated values agree. The token -- can end Docker option parsing. Clusters such as -dp and attached short forms such as -p8080:80 are not accepted.

Flags outside this list block conversion. Examples include --rm, --env-file, --privileged, --network, and options for capabilities, devices, resource limits, logging, entrypoints, and health checks. Preserve any required behavior when choosing another way to author the configuration; removing an unsupported flag solely to pass the importer can change the service.

Command limits, quoting, and image names

The complete import accepts at most 16,384 UTF-8 bytes, 256 decoded tokens, and 50 explicit environment occurrences. These limits are inclusive. The token count includes the command prefix, options, operands, image, and application arguments. Repeated environment keys still count toward the 50-occurrence limit. Each import contains one image, at most one published TCP mapping, and at most one mount.

• Only docker run and docker container run prefixes are accepted. Shell prompts, sudo, preceding assignments, remote or context options, and multiple commands are outside this syntax.
• Spaces and tabs separate arguments. Quotes group text, adjacent quoted and unquoted segments form one argument, and empty quotes preserve an empty argument. Single quotes retain literal content. Outside quotes, a backslash escapes the next admitted character.
• Inside double quotes, backslash escapes a dollar, backtick, quote, backslash, or line continuation; before another character it remains literal. Outside single quotes, backslash followed by LF or CRLF continues a command across lines. Unescaped interior newlines and quoted multiline values are rejected.
• Unquoted shell operators, redirects, variable expansion, command substitution, globs, tilde or brace syntax, and comments at the start of a token are rejected. Quoted or escaped metacharacters can be literal data, but an unescaped dollar or backtick inside double quotes is still rejected.
• Unclosed quotes, dangling escapes, unsupported control characters, malformed Unicode, and inputs exceeding the limits produce errors without a usable conversion.

Port ranges, missing host ports, IPv6 bindings, other bind addresses, UDP, SCTP, and repeated publications are unsupported. Imported mounts reject relative paths, tilde paths, Windows or UNC paths, anonymous sources, extra colons, and modes other than the optional :ro. A named source starts with a letter or digit and otherwise uses letters, digits, dots, underscores, or hyphens. Quoted Linux absolute paths may contain spaces.

Imported image references follow a bounded form of [registry[:port]/]repository[:tag][@sha256:digest]. The complete reference is limited to 512 characters and the name before its tag or digest to 255. Repository path components use lowercase letters and digits separated by a dot, one or two underscores, or one or more hyphens. Tags contain up to 128 characters, start with a letter, digit, or underscore, and otherwise allow letters, digits, underscores, dots, and hyphens. A SHA-256 digest requires exactly 64 hexadecimal digits.

Registry names use dot-separated alphanumeric labels with optional interior hyphens and an optional port from 1 to 65535. A first path component containing a dot or colon, or equal to localhost, is treated as the registry. URL schemes, credentials, IPv6 registry syntax, and other digest algorithms are unsupported. An accepted reference is preserved verbatim; its availability and platform compatibility are not checked.

The Compose service key comes from the final repository component without its tag or digest and is shortened to 63 characters when necessary. The review identifies this generated key separately from an explicit container name. This is a conversion rule, not a promise to accept every image reference supported by Docker.

Manual configuration and network meaning

Manual entry writes either an image value or a build section containing the chosen context. A nonblank project name adds the top-level name; leaving it blank retains Compose's directory or command-line project naming. The source reference is limited to 512 characters. The service and project fields allow up to 63 characters beginning with a letter or digit, followed by letters, digits, dots, underscores, or hyphens. Local Compose validation remains necessary.

Host publication and network attachment are separate decisions. The four Manual choices produce these configurations.

Both Manual port fields must contain integers from 1 to 65535, including when the chosen scope does not publish a host port. Imported services instead use network_mode: "bridge" without creating a Compose network. When -p is absent, neither ports nor expose is added. Networking stays enabled, and the image's EXPOSE declarations are not inspected. Docker's default bridge also lacks the automatic service-name resolution provided by user-defined networks.

A bare imported mapping is classified as public, as is an explicit 0.0.0.0 binding. An explicit 127.0.0.1 binding is classified as local. Docker configuration can change the default bind address, and actual reachability depends on host routing and firewall rules. These classifications describe the entered mapping rather than a live exposure test.

Mount identity, health checks, and recovery

Manual mounts accept one source and an absolute container target with an optional :ro. A relative bind such as ./config:/app/config:ro is available in Manual entry even though the import requires Linux absolute bind paths. Manual named volumes receive an empty top-level declaration and normal Compose project scoping.

Imported named volumes receive an explicit top-level name equal to the original resource name. For example, an imported demo_data volume continues to refer to that exact resource, which may already contain data used by another container. Compose can create it if missing. The conversion does not add external: true or assume that the resource already exists.

A Manual healthcheck command is limited to 1,024 characters and is emitted with CMD-SHELL, a 30-second interval, a 5-second timeout, and 3 retries. Its shell and commands must exist in the selected image. Leaving the field blank adds no healthcheck override; an image may already define one. Imported healthcheck options are unsupported, so imports add no explicit check.

The Manual restart default is unless-stopped; the import default is no. The on-failure policy concerns an unsuccessful process exit. A health status change alone is not a process exit. Root filesystem read-only status and a mount's :ro remain independent permissions.

Environment values and literal dollars

Environment keys must match [A-Za-z_][A-Za-z0-9_]*. Assignments split at the first equals sign, allowing further equals signs and empty values in the value. Manual entry accepts one assignment per nonblank line, up to 12,000 characters, and trims each line before reading it. Blank lines are skipped; comment lines are not accepted. Imported assignments preserve decoded spaces within values. Both routes keep the last value for a duplicate key; import review also records which occurrence overrides another.

Secret detection examines key names only. It matches these terms case-insensitively only when each term begins the key or follows an underscore, and also ends the key or precedes an underscore: PASSWORD, PASS, TOKEN, SECRET, API_KEY, ACCESS_KEY, PRIVATE_KEY, CREDENTIAL, DATABASE_URL, DB_URL, and AUTH. For example, API_TOKEN is recognized, while APIKEY is not. Sensitive values under other names can remain literal.

The environment example contains only recognized keys moved to references. Its .env.example filename does not make Compose load it automatically. Supply actual values in the shell environment used to run Compose or in a local .env file used for substitution. An imported replace-locally value is a setup instruction, not the original credential. Reference conversion intentionally requires this local step. An unset reference can become an empty value with a warning, so configuration validation alone does not confirm that a credential was supplied correctly.

There are two opportunities for a dollar sign to be interpreted: command quoting and Compose substitution. Single-quoted '$HOME' becomes the literal argument $HOME during import. The generated YAML then uses "$$HOME", allowing Compose to pass $HOME to the container without substituting the host's value. YAML double quotes alone do not prevent Compose interpolation. Unescaped "$HOME" in the pasted command is rejected because shell expansion is outside the import syntax.

Every imported literal dollar is doubled, including dollars in application arguments and literal environment values. Intentional ${KEY} references remain single-dollar expressions. Manual values retain normal Compose interpolation behavior and are not automatically given the import's dollar escaping. A later shell or application inside the container can still interpret the text it receives.

Readiness rules and count formula

Readiness percentages are fixed values assigned to configuration choices. They are not calculated from live Docker tests. The table gives the complete six-area scoring rule.

For imported images, an explicit tag other than latest, compared case-insensitively, or an admitted SHA-256 digest meets the source check. Manual image scoring uses a simpler text check: a colon anywhere unless the reference ends in :latest, compared case-insensitively, or the presence of @sha256:. Consequently, a Manual reference such as registry.example.com:5000/team/app can receive 100 even though its colon belongs to a registry port and it has no explicit tag. Import parsing distinguishes those cases.

A supplied healthcheck earns its score without being run or inspecting any inherited image check. The Storage score concerns the mount, not the root filesystem's read-only setting. These distinctions explain why a favorable score cannot establish that a configuration will work or protect sensitive data.

Count each area scoring at least 80 as ready. The remaining areas require review, so the two counts always total six.

The chart uses green for scores of 80 or higher, amber for scores from 55 up to but not including 80, and red for scores below 55. Both amber and red areas count as review. Scores and counts are exact integers with no rounding, and no overall average is calculated.

Privacy Notes:

Command parsing and YAML generation happen in your browser. The conversion does not run commands, connect to Docker, query an image registry, read host environment variables, or inspect local files. A build context or mount path is treated as text.

• Manual environment values and imported commands remain in the current page's memory. They are excluded from generated Share URLs and browser storage, and the conversion does not upload them.
• Share retains the other Manual settings, not the imported service. Review those remaining fields before sharing, since paths, image references, and healthcheck text can themselves contain private information.
• Recognized legacy environment or import values in a URL are discarded and removed from the current address. This cleanup cannot erase an earlier server request or older browser-history entries.
• Copying or downloading deliberately transfers the selected result to the clipboard or a file. Protect those outputs according to their contents, especially literal YAML and Manual environment examples.

Worked Examples:

References:

• Define services in Docker Compose, Docker.
• Port publishing and mapping, Docker.
• Define and manage networks in Docker Compose, Docker.
• Define and manage volumes in Docker Compose, Docker.
• Interpolation, Docker.
• Set environment variables within your container's environment, Docker.
• Docker image reference structure, Docker.
• Pin base image versions, Docker.
• docker compose config, Docker.
• How to use an env file with Docker Compose, Simplified Guide.