Stop Fighting YAML: I Built a Visual Docker Compose Architect to Fix It

#devops #productivity #docker #opensource

The Problem: YAML vs. Reality

If Docker Compose keeps tripping you up, it is rarely because you do not understand containers. It is because Compose makes you juggle two things at once: YAML rules and Docker's schema.

If you hve ever tried to visualize a Docker Compose file, you know the drill: most tools work great on hello-world examples but choke the moment you throw a real-world file at them.

Why? because "Real World" Docker Compose is messy. It has environment variables (${PORT:-8080}), it uses service inheritance (extends), and it relies on complex overrides.

Why Compoviz is different, and why it can finally handle your "cursed" Docker files.

1. Solved: The "Missing Port" Bug (Inheritance)
Service inheritance (extends) is where most parsers fail.

If you have a base service with port 80 and an extended service adds port 443, many tools mistakenly replace the list—meaning port 80 disappears.

Compoviz knows when to merge lists (like ports and volumes) and when to override them (like image tags). You see the final, actual configuration, not just the last layer.

2. Support for YAML Anchors & Aliases
Do not repeat yourself (DRY) is great for code, but hard for parsers. If you use YAML anchors (&) to share logging configs or healthchecks across services, simple visualizers often ignore them or show raw references like *default-logging.

Compoviz fully resolves YAML aliases before building the graph. This means if you alias a volume or a network configuration, the visualizer sees the resolved properties and draws the connections correctly.

3. Profiles: Dev vs. Prod Views
We often shove everything into one huge compose.yml and use profiles (profiles: ["dev", "monitoring"]) to control what runs.

Compoviz now includes a Profile Selector. You can toggle profiles on and off to see exactly how your architecture changes between environments. It filters the graph in real-time, removing the noise of disabled services.

Without any profile selected"

Dev profile selected:

Dev & Prod profiles selected:

4. Visual Conflict Detection (Compare Mode)
We rarely run just one Docker stack. You have your main app, a legacy backend, and maybe a side project, all fighting for localhost:5432 or port 80.

Multi-Project Loading: You can load up to three different compose files simultaneously into the same workspace.
Collision Highlighting: The engine cross-references every exposed port, container name, and volume mount. If Project A claims port 5432 and Project B tries to grab it too, Compoviz instantly highlights the collision in red.
The Benefit: You spot the conflict visually before you run docker compose up and get that cryptic "address already in use" error.

5. Still 100% Client-Side (Privacy First)
Despite the new power, the architecture remains unchanged in one critical way: Privacy. There is no backend. Your .env files (which likely contain API keys and passwords) never leave your browser memory. The parsing happens locally on your machine.

Try It Out
If you have a complex Docker Compose file that breaks other tools, I want you to try breaking this one.