# Docker/Podman Composer — Tips & Tricks

> The converter's limits, round-trip loss, which flags get dropped, and how to combine the Composer with cheat sheets and other JPKCom tools.

Source: https://www.jpkc.com/db/en/tools/docker/tips/

Back to the overview: [Docker/Podman Composer](https://www.jpkc.com/db/en/tools/docker/) · Open the tool live: [www.jpkc.com/tools/docker/](https://www.jpkc.com/tools/docker/)

The [manual](https://www.jpkc.com/db/en/tools/docker/manual/) lists every flag, the [examples](https://www.jpkc.com/db/en/tools/docker/examples/) show the walkthroughs. This page is about what both assume: where the converter deliberately has limits, what gets lost in a round trip, and how to use the tool well.

## What the converter does NOT map

The Composer is a text-to-text translator for **one** container or service. Some things fall away in the process — not a bug, but the nature of the two formats:

- **`--rm` and `-d`/`--detach`** have no meaningful Compose equivalent and are discarded on Run → Compose. `detach` is implicit in Compose anyway; on Compose → Run, a `-d` is **always** added.
- **`--network-alias`** is recognized but discarded — there's no direct Compose mapping at the service level.
- **Unknown flags are silently skipped.** If something you had in the command is missing from the result, the flag is either unknown or one of the special cases above. A look at the **Reference** tab shows you which flags are mapped at all.
- **There's no such thing as multiple services in one run command.** A `docker run` starts exactly one container, so Run → Compose always produces exactly one service. You build a multi-part setup by converting several commands individually and merging the service blocks into one file.

## Compose-only: what you add by hand after conversion

These Compose constructs simply can't be derived from a `run` command — and are lost going Compose → Run. The **Reference** tab lists them as "Compose-only Features":

- **`depends_on`** — start order and health conditions between services.
- **`build`** — build an image from a Dockerfile instead of pulling a finished one (including build context and arguments).
- **`profiles`** — activate services conditionally.
- **`deploy`** — Swarm, replica, and resource constraints.
- **`secrets` / `configs`** — Swarm secrets and configs.
- **Top-level `volumes`/`networks`** — named volumes and networks with driver options. On Compose → Run, only a service's *reference* to a network becomes `--network`; the actual driver definition falls away.

The practical trick: the YAML output in the run tab is **editable** ("editable" badge). Convert your run command first, then type a `depends_on`, a `build:` block, or a top-level `networks:` definition right inside the tool before you copy or download the file.

## Round trip isn't lossless

If you convert a command to Compose and then back to `run`, you won't necessarily get your exact input back:

- **Discarded flags don't come back.** `--rm`, `--network-alias`, and unknown flags are gone after the first step.
- **`-d` is re-added.** Compose → Run prepends a `-d` to every command, even if the original had none.
- **Health-check form changes.** `--health-cmd "…"` becomes `test: [CMD-SHELL, …]`. If you import a Compose file whose `test` is in the `["CMD", …]` list form (instead of `CMD-SHELL`), the converter joins the elements into one `--health-cmd` string — functionally similar, but not character-identical.
- **Quoting can change.** When generating YAML or commands, quoting is applied only where needed; a pure number meant as a string appears as `"3"`, for example. Semantically identical, but it looks different from your hand-written original.

Bottom line: use the Composer as a **starting point** and scaffold, not as a bit-exact round trip. The generated result is correct and runnable, but give it a once-over before it goes to production.

## Small knacks

- **Break long commands with a backslash.** The tokenizer normalizes `\` line continuations, so you can paste a multi-line command copied from a tutorial unchanged.
- **`--flag=value` and `--flag value` both work.** Copy commands as you find them — the parser understands both spellings.
- **Privacy included.** Because everything runs **client-side** and nothing is sent anywhere, you can convert commands with passwords, tokens, or internal hostnames without worry. Still: in the real Compose file such values belong in a `.env` file or in `secrets`, not in plaintext in the repository.
- **A Compose snippet without the `services:` wrapper works too.** In the reverse direction the parser also accepts a bare services map, not just a complete file.

## Combining with other JPKCom tools

- **Building or understanding a run command?** The **[Docker cheat sheet](https://www.jpkc.com/db/en/cheatsheets/containers/docker/)** explains the container lifecycle and the key `docker` flags — a good reference before you throw a command into the Composer.
- **Working with the generated YAML?** The **[Docker Compose cheat sheet](https://www.jpkc.com/db/en/cheatsheets/containers/docker-compose/)** shows how to run the file with `docker compose up`, `down`, `logs`, and friends — and which fields (`depends_on`, `build` …) you can still add.
- **Moving to Podman?** The **[Podman cheat sheet](https://www.jpkc.com/db/en/cheatsheets/containers/podman/)** puts the `podman` commands the tool generates in podman mode into context.
- **Scheduling a container job?** With the **[cron generator](https://www.jpkc.com/db/en/tools/cron/)** you build the matching crontab line, for example for a recurring `docker run` maintenance job.

---

More context: the [overview](https://www.jpkc.com/db/en/tools/docker/) for the big picture, the [manual](https://www.jpkc.com/db/en/tools/docker/manual/) for every flag, and the [examples](https://www.jpkc.com/db/en/tools/docker/examples/) for the step-by-step walkthroughs. You can try everything directly in the [tool](https://www.jpkc.com/tools/docker/).