Docker/Podman Composer — Tips & Tricks

Back to the overview: Docker/Podman Composer · Open the tool live: www.jpkc.com/tools/docker/

The manual lists every flag, the 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 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 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 puts the podman commands the tool generates in podman mode into context.
Scheduling a container job? With the cron generator you build the matching crontab line, for example for a recurring docker run maintenance job.

More context: the overview for the big picture, the manual for every flag, and the examples for the step-by-step walkthroughs. You can try everything directly in the tool.