If you've ever set up a self-hosted Homelab or deployed a multi-tier production stack on a Linux VPS, you know the frustration:
bash
Error response from daemon: driver failed programming external connectivity on endpoint jellyfin:
Bind for 0.0.0.0:8096 failed: port is already allocated
You open your docker-compose.yml, manually cross-reference 5 different service definitions, search for port allocations, change 8080:80 to 8081:80, only to realize another service was already listening on 8081.
docker-compose.yml is fundamentally text-first. But infrastructure topology—dependencies, networks, volumes, and ports—is inherently a graph.
I'm Alperen, a 14-year-old high school student from Bursa, Turkey. Over the past several months, I set out to solve this developer friction by building XIVIZLEY
—an open-source visual web architecture suite for Docker and Homelab systems.
What XIVIZLEY Does
Instead of writing YAML from scratch or running heavy server-side agents, XIVIZLEY runs 100% in your browser:
Visual Drag & Drop Canvas: Connect 134 popular open-source modules (databases, reverse proxies, media servers, AI models like Ollama, monitoring stacks) or pick from 33 curated production templates.
Deterministic Port Conflict Detection: As you place containers on the canvas, an in-memory collision detection engine scans the host port matrix. If two containers require the same host port, it immediately flags the collision and suggests optimal, non-conflicting alternatives.
Clean Docker Compose & 1-Click SSH Export: Produces standardized, linted docker-compose.yml specs and single-command SSH scripts with verifiable SHA-256 integrity.
Zero Telemetry & Zero Server Daemon: Unlike server panels that require long-running root daemons, XIVIZLEY requires zero server agents. What happens in your browser stays in your browser.
Self-Hostable: You can self-host the entire platform locally with a single command:
bash
git clone https://github.com/Xivizley/xivizley.git
cd xivizley
docker compose up -d
How the Port Conflict Resolver Works
Under the hood, the engine treats port mapping as a bipartite graph constraint problem. Each module registers its default ingress/host ports:
typescript
export interface ModulePortConfig {
containerPort: number;
defaultHostPort: number;
protocol: 'tcp' | 'udp';
alternativeHostPorts: number[];
}
When an edge or node is added to the React Flow canvas:
The canvas state extracts all allocated hostPort:containerPort mappings across active nodes.
If two active nodes request port 80/tcp, the system flags a PORT_COLLISION event.
It iterates through the secondary alternativeHostPorts pool (e.g. 8080, 8088, 8000) and highlights the suggested resolution inline on the node card.
TÜBİTAK 2204-A & Open Source
This project was developed as part of the TÜBİTAK 2204-A High School Students Research Projects Competition in Turkey, exploring visual programming paradigms applied to systems engineering.
The entire core platform is released under the MIT License:
Live Platform: https://xivizley.com.tr
GitHub Repository: https://github.com/Xivizley/xivizley
Interactive Canvas: https://xivizley.com.tr/architect
I'd Love Your Feedback!
As a 14-year-old builder, feedback from seasoned DevOps and Homelab practitioners means the world to me:
What edge cases in port collision handling would you like to see covered?
Which Docker services or Homelab stacks should we add next?
Feel free to star the repo, test the live canvas, or drop a comment below!
