Docker Compose Merge Visualizer

What this does

Paste a base docker-compose.yml plus one or more override files — the same set you'd pass as -f base.yml -f prod.yml — and see two things: the fully merged configuration as YAML, and a field-by-field breakdown of which file actually determined each value. That second part is the part a plain docker compose config can't show you: it prints the merged result, not which file won each field.

The merge follows how Docker Compose overrides actually work: mappings like environment: and labels: merge key by key, sequences like ports: concatenate, command: and entrypoint: replace wholesale even in array form, and volumes:/devices: merge by mount or device target instead of blindly appending. The !override and !reset YAML tags are supported too, forcing a real replace or clearing a field entirely on whichever file uses them.

Reading the provenance badges

• added — the first file (in order) to define this field or service.
• changed — a later file redefined a scalar or mapping field that an earlier file already set.
• appended — a list field (ports:, expose:, env_file:, and similar) that more than one file contributed entries to; Compose concatenates these rather than replacing them.
• reset / forced replace — the field used the !reset or !override tag in that file.

Badges are colored per file, matching the legend above the output. A field's badge names whichever file most recently specified it — for a list field that accumulates across files, that's the last file to add anything to it, not necessarily the only contributor.

What it doesn't do

This models the documented merge rules, not every edge case of every Compose version — service-level networks: entries with per-network config (aliases, ipv4_address) merge one level deep rather than recursively, and a handful of rarely-used fields fall back to the generic mapping/sequence/scalar default rather than a field-specific rule. For a definitive answer on a specific file, run docker compose -f base.yml -f override.yml config directly. This tool doesn't validate the result either — for that, run the merged YAML through Docker Compose Validator or lay it out with Docker Compose Visualizer.

FAQ

Which file should go first?

The base file, then overrides in the order Compose would apply them — the same order as your -f flags. Order matters: the last file listed wins any direct conflict, so listing overrides in the wrong order silently produces the opposite of the intended result.

Does this support the auto-loaded docker-compose.override.yml?

Yes, functionally — just paste docker-compose.yml as the first file and docker-compose.override.yml as the second. That's exactly the pair Compose auto-loads when no -f flags are given at all.

Why does a list field show entries I didn't expect?

Almost always because a list field like ports: concatenates instead of replacing — an override's entry gets added alongside the base file's, not swapped in for it. Check the "appended" badge on that field; if the intent was a real replacement, the fix is the !override tag, not restating the field.

Is anything uploaded anywhere?

No — parsing and merging both run entirely in your browser.

Try it yourself

Docker Compose Validator catches undefined services, bad ports, and undeclared volumes/networks in the merged result, and Docker Compose Visualizer turns it into a diagram of start order, networks, and volumes. Both run entirely in your browser.