Topology#

Topology shows you how your infrastructure fits together — which VMs run on which hosts, which containers depend on which services, and what breaks when a single component goes down. Instead of holding a mental map of your homelab, you get a visual one.

What topology shows#

LabTether builds a dependency graph from your agents, connectors, and asset metadata. Every relationship has a direction and type:

• runs_on — a VM runs on a Proxmox host, a container runs on a Docker host
• depends_on — a service depends on a database, a monitoring stack depends on a metrics endpoint
• hosts — a physical machine hosts virtual infrastructure

These relationships are discovered automatically from connectors (Proxmox host-guest mappings, Docker host-container links) and can be supplemented or corrected manually through the mapping editor on node detail pages.

Select any asset in the graph to see its incoming and outgoing relationships in the inspector — what it depends on (upstream) and what depends on it (downstream).

View modes#

Graph view#

The default visual mode. Assets appear as cards organized into lanes, with edges showing relationships. Use lane controls to group related assets and adjust density so clusters stay readable instead of collapsing into a hairball.

Cross-lane relationships anchor to card edges, and lanes wrap rather than stretching into a single horizontal strip.

Tip: Hiding lanes in graph mode does not blank the tree or list views. Each view maintains its own rendering state, so you can hide noisy lanes in the graph without losing context when you switch.

List view#

A flat, filterable list of all assets with their dependency relationships shown as clickable rows. Dependency-linked children (containers under a Docker host, VMs under a Proxmox node) appear as expandable child rows rather than summary-only rollups.

Good for searching when you know what you are looking for but not where it sits in the graph.

Tree view#

A hierarchical view that groups assets by their parent-child relationships. Hosts at the top, guests and workloads nested below. Tree view preserves expected host/child grouping — including agent-managed type=host parents — and does not misclassify valid dependency trees as Unlinked.

Source-scoped investigations (e.g., filtering to Source=Docker) still retain host/container hierarchy links instead of collapsing to empty trees. Docker host/container links remain intact even when child assets are missing metadata.agent_id, by falling back to Docker asset ID conventions.

Using topology for troubleshooting#

Topology is most valuable when something breaks and you need to understand the blast radius.

Tracing upstream: A service is down. Open it in topology, follow the upstream edges. Does it depend on a database that is also unhealthy? Does that database run on a host with high CPU? The dependency chain often points to the root cause faster than checking each component in isolation.

Tracing downstream: A host is going down for maintenance. Open it in topology, follow the downstream edges. Which VMs will go offline? Which services depend on those VMs? This is your impact assessment before you hit the reboot button.

Verifying relationships: Before applying a fix, check the mapping editor in the node detail cluster topology graph. Verify that guest-to-host runs_on links are correct (auto-detected, manually set, or missing). Fixing a wrong dependency link first avoids chasing phantom issues.

Tip: Topology is a starting point for investigation, not a replacement for logs and metrics. Use it to narrow your search space — once you know which components are involved, pivot to their telemetry, logs, and alert history for the specifics.