The Actual Homelab Boundaries

Why the stack is split across an MKG server, HomeLab server, Raspberry Pi, and isolated Digital server.

The diagram has to match the system

The clean version of a homelab diagram is usually wrong. My stack is not a symmetrical cluster where everything can float anywhere. It is a set of bounded systems with different jobs.

The real design is split by ownership and operational risk:

MKG server: personal, operator, deployment, media, creative, and AI/runtime services like Coolify, Jellyfin, Immich, Vaultwarden, Paperless, draw.io, ComfyUI, Pascal, Blender, and automation surfaces.
HomeLab server: home services that are tied to the house and devices: Home Assistant, HomeBridge, Frigate, TrueNAS SMB for family storage, and DNS backup.
Raspberry Pi: lightweight edge duties where low power and resilience matter more than raw compute.
Digital server: David's photography-business infrastructure. I help operate it, but it is isolated and is not a landing zone for my workloads.

Why the split matters

Home automation should stay close to the physical home. Camera workloads should stay close to the NVR hardware. Family shares should stay close to the storage layer. Deployment, creative media, AI/runtime, and personal services should stay on the MKG side. Personal services should not drift into a client-owned or family-critical system just because there is spare RAM.

That makes the architecture less pretty, but more honest. It also gives better failure boundaries: a media service issue should not imply anything about Frigate, TrueNAS, or David's photography workflows.

Public ingress

Only selected services get public routes. Public traffic reaches the ingress layer, Nginx Proxy Manager routes it internally, and the portfolio currently lands on Coolify on the MKG server. The goal is not to expose the homelab. The goal is controlled access to the small number of services that need it.

What I want the map to prove

The topology should show real constraints:

which services are home-bound
which services are personal/operator-bound
which systems are isolated
which paths cross the public edge
which workloads should not migrate casually

That is the useful story. Not a fantasy cluster diagram.

Key lessons

Boundaries beat symmetry. A technically literate reader trusts a messy but accurate map more than a perfect one that hides constraints.

Device-bound workloads stay pinned. Frigate, Home Assistant, HomeBridge, and TrueNAS are not generic containers in a pool. They depend on local devices, storage, and household reliability.

Client infrastructure stays isolated. The Digital server can be managed by me without becoming part of my personal compute pool.

Public routes are promises. If a service is exposed, it needs ownership, monitoring, and a reason to exist publicly.