What this does
This is the single-file half of what docker compose config actually does: resolve every ${VAR} placeholder in a docker-compose.yml against a project .env file and shell overrides, then expand every shorthand field — ports:, volumes:, environment:, build:, and more — into the canonical long form Compose actually runs against. Both steps happen silently in real Compose; this makes them visible.
Merging multiple compose files (a base plus -f overrides) is a separate concern with its own tool: Docker Compose Merge Visualizer. This tool works on one resolved file at a time — pass it the output of a merge if you're doing both.
The interpolation syntax
Matches how Compose environment variables actually work: a shell override wins over the same key in the .env file, which wins over an inline default.
| Syntax | Behavior |
|---|---|
${VAR} | Plain substitution — empty string if unset |
${VAR:-default} | Use the default if VAR is unset or empty |
${VAR-default} | Use the default only if VAR is completely unset |
${VAR:?message} | Fail if VAR is unset or empty |
${VAR?message} | Fail only if VAR is completely unset |
$$ | Escaped to a literal $ — for values like bcrypt hashes that contain a real dollar sign |
A :?/? failure is treated as a hard stop, the same way real Compose refuses to run rather than producing a config with a missing required value.
What gets normalized
environment:, labels:, depends_on:, and extra_hosts: written in list form expand to their mapping form. ports: short strings ("8080:3000", "9000:9000/udp") expand to target/published/protocol objects. volumes: short strings expand to type/source/target objects — a source that looks like a path becomes a bind mount, anything else a named volume. A string build: shorthand becomes { context: ... }. Anything already in long form, or not covered above, passes through unchanged.
What it doesn't do
No multi-file merging (see Docker Compose Merge Visualizer for that), and no structural validation — a service referencing an undefined depends_on target or an undeclared volume still resolves cleanly here, since that's Docker Compose Validator's job, not this tool's.
FAQ
Is this the same as running docker compose config?
It models the same two mechanisms — interpolation and shorthand expansion — for a single file, entirely in your browser. For a definitive answer on a real project, including multi-file merges, run docker compose config directly.
Why does my ${VAR:?message} fail here but work when I actually run Compose?
Almost always because the variable is set in your real shell environment but wasn't pasted into the shell overrides box above — this tool only knows about variables you explicitly give it, not your actual terminal session.
Is anything uploaded anywhere?
No — interpolation, parsing, and normalization all run entirely in your browser.
Try it yourself
.env Validator catches dotenv parsing gotchas in the project .env file itself, and Docker Compose Validator checks the resolved structure for undefined services, bad ports, and undeclared volumes/networks. Both run entirely in your browser.