Let’s be honest: your homelab probably looks like a tangled cable monster with a dozen services running—but you have no idea which ones are actually talking to each other. You’ve got Pi-hole blocking ads, Home Assistant automating lights, a Nextcloud instance syncing family photos, and three different monitoring tools scraping metrics—but are they all online? Are any silently failing? Is that “mysterious” 100% CPU spike on raspberrypi4 actually your unifi-controller leaking memory or is it the jellyfin transcode process gone rogue? That’s where HomeLabInfo punches above its weight: it’s not another monitoring dashboard—it’s a living map of your lab’s network relationships, built by watching real traffic, not just pings or /health endpoints.

What Is HomeLabInfo? (And Why It’s Not Just Another Network Scanner)

HomeLabInfo is a self-hosted, TypeScript-based network discovery and visualization suite, built specifically for homelabbers—not enterprise network ops teams. Launched in early 2024 and already at 47 GitHub stars (as of June 2024), it’s lightweight, opinionated, and designed to answer one question: “What is actually connected, communicating, and where?”

Unlike nmap (a one-off scanner), Zabbix (a heavyweight monitoring suite), or even Netdata (great for metrics, terrible for topology), HomeLabInfo runs continuously, passively observes traffic via pcap (or uses active probes selectively), infers device roles (e.g., “this 192.168.1.42 is probably your Synology NAS because it’s serving SMB and responding to ssdp”), and renders an interactive, filterable graph in the browser.

It doesn’t require agents. It doesn’t need SNMP community strings. It doesn’t assume you’ve configured lldp on your Unifi switch (though it will use it if available). It just watches, classifies, and draws.

The kicker? It ships with built-in device fingerprinting for homelab staples: Raspberry Pi OS, Debian Bookworm dockerd, Synology DSM 7.2, TrueNAS SCALE, even your ESP32 microcontrollers (if they’re doing mDNS). I ran it for 3 days on my lab (10x active devices, 2 switches, 1 Pi 5, 1 x86_64 NUC) and it auto-labeled my pi-hole instance and picked up the esphome firmware version on my garage door sensor—no config required.

Installation: Docker-First, Zero System Dependencies

HomeLabInfo is Docker-native. There’s no npm install -g, no global Node.js version dance, no compiling libpcap bindings. The maintainer, Greg Luffy (@gregluffy), designed it to run cleanly on Raspberry Pi OS, Debian, or Ubuntu—and it does.

I deployed it on my Pi 5 (8GB RAM, Ubuntu 24.04 LTS, kernel 6.6) using Docker Compose. Here’s the minimal docker-compose.yml I’m actually running (v0.4.2, the latest stable as of this writing):

version: '3.8'
services:
  homelabinfo:
    image: ghcr.io/gregluffy/homelabinfo:0.4.2
    container_name: homelabinfo
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    volumes:
      - ./config:/app/config
      - ./data:/app/data
    environment:
      - TZ=America/Chicago
      - HLINFO_LOG_LEVEL=info
    # Optional: expose only if you want HTTPS reverse proxy later
    # ports:
    #   - "3000:3000"

Critical notes:

  • network_mode: host is required for pcap capture. You cannot use bridge networking.
  • cap_add: [NET_ADMIN, NET_RAW] is non-negotiable—this lets the container sniff traffic.
  • The ./config volume is where you drop config.yaml. More on that in a sec.
  • Don’t expose port 3000 directly to the internet. It has no auth layer (more on that later).

Once saved, run:

docker compose up -d
docker logs -f homelabinfo

You’ll see logs like pcap: listening on eth0, fingerprint: loaded 23 device signatures, graph: initialized with 7 nodes. Wait ~90 seconds—then hit http://<your-pi-ip>:3000. No login. No setup wizard. Just a clean, dark-themed topology graph.

Config Deep Dive: Taming Discovery Without Going Full Wireshark

The default config works—but you’ll want to tweak it. Drop this into ./config/config.yaml:

# ./config/config.yaml
server:
  port: 3000
  host: "0.0.0.0"
  cors_enabled: true

discovery:
  active:
    enabled: true
    interval_seconds: 300  # every 5 mins, ping known subnets
  passive:
    interface: "eth0"     # or "wlan0", "br0"—match your primary LAN iface
    promiscuous: true
    bpf_filter: "not port 22 and not port 23"  # skip noisy SSH/Telnet
  lldp:
    enabled: true
  mdns:
    enabled: true
    timeout_ms: 2000

fingerprinting:
  enabled: true
  user_agents:
    - "Home Assistant/*"
    - "Jellyfin/*"
    - "nextcloud/*"
  ports:
    - 80
    - 443
    - 8123  # HA
    - 8080  # often used for custom services

storage:
  retention_days: 30
  max_nodes: 100

Key things I learned the hard way:

  • If you’re on a Unifi network, lldp + mdns together give shockingly accurate device names—my unifi-usw-24p switch showed up as “USW-24P (1.12.13)”, not just 192.168.1.1.
  • The bpf_filter is your friend. Without it, HomeLabInfo tried to classify every ARP packet and spiked CPU to 65% on my Pi 5. With the filter? Steady 8–12%.
  • user_agents aren’t just for HTTP. It checks Server: headers and TLS SNI—so your caddy reverse proxy’s X-Forwarded-For chain doesn’t break device attribution.

How It Compares: Why Not Just Use NetBox or Observium?

Let’s cut the marketing fluff. If you’re already running NetBox, don’t replace it with HomeLabInfo. NetBox is your source of truth for IPAM, rack layouts, and change control. HomeLabInfo is the living reflection of what’s actually happening right now. I run both side-by-side: NetBox has my “planned” VLANs; HomeLabInfo shows me that 192.168.2.100 (which NetBox thinks is my “backup NAS”) is actually a misconfigured Docker container leaking traffic on VLAN 3.

Compared to Observium? Observium is a beast—great for Cisco gear, but overkill for a Pi + 2x Unifi APs. Observium needs MySQL, PHP, SNMP, and 2GB RAM minimum. HomeLabInfo runs fine on a Pi 4 with 4GB, uses SQLite by default, and needs no SNMP config. I fired up Observium in a VM for 10 minutes before killing it—too much friction.

What about Nmap + Graphviz scripts? Yes, you could cron nmap -sn 192.168.1.0/24 and pipe to dot. But that’s static, blind to service interdependencies, and gives zero insight into why 192.168.1.21 is suddenly talking to 192.168.1.10 every 17 seconds (it’s your shelly device polling HA, but you’d never know without HTTP-level inspection—HomeLabInfo does that).

And versus Wireshark + custom tshark filters? Wireshark is a forensic tool. HomeLabInfo is operational. You don’t debug with it—you observe. It’s the difference between reading a car’s OBD2 logs and watching the live dashboard while driving.

Why Self-Host This? (Spoiler: It’s Not for Everyone)

HomeLabInfo is built by homelabbers for homelabbers—but it’s not universal. Here’s who it’s ideal for:

  • You run 5–50 devices, mix of Linux, IoT, and containers, and you’re tired of ping-ing random IPs to see if they’re “up”.
  • You care about network topology, not just metrics—e.g., “Is my Home Assistant instance really only talking to my Z-Wave stick and MQTT broker, or is something else sneaking in?”
  • You’re comfortable with docker compose, cap_add, and reading tcpdump-style docs—but you don’t want to write Python scrapers.
  • You don’t need RBAC, SSO, or enterprise audit logs. (It has zero auth. None.)

It’s not for you if:

  • You need multi-tenant support (e.g., “My kid’s Minecraft server should be isolated from my banking VMs” — it doesn’t do segmentation enforcement).
  • You run a production Kubernetes cluster with 200+ pods (the graph gets cluttered fast; it’s optimized for devices, not ephemeral pods).
  • You demand 99.99% uptime SLAs. It’s a v0.4.x project—no high-availability clustering, no failover.

Resource-wise, on my Pi 5, it averages:

  • RAM: 280–340 MB (SQLite cache + Node.js event loop)
  • CPU: 8–15% sustained (peaks to 40% during active scan bursts)
  • Disk: 1.2 GB after 10 days (mostly .pcap fragments and graph history)

No GPU. No special drivers. Just libpcap and a working network interface.

The Verdict: Is It Worth Deploying? (My Honest, Unfiltered Take)

Yes—but with caveats.

I’ve had HomeLabInfo running 24/7 for 17 days. It found two things I didn’t know were on my network: a forgotten Docker container (portainer backup) that was still responding to HTTP requests (and leaking a /api/status endpoint), and a misconfigured syncthing instance on my laptop that was broadcasting to the entire subnet instead of just its relay group. I fixed both in <5 minutes—because HomeLabInfo showed me the connection, not just “port 22 open”.

The good:

  • It works out-of-the-box—seriously. docker compose up, wait 90 sec, done.
  • The graph is fast and intuitive. Click a node → see all its connections, ports, observed protocols (HTTP/2, mDNS, SSDP), even TLS versions.
  • It’s actively developed. Greg merged my PR for Raspberry Pi OS 64-bit detection last week. The repo has 21 commits in the last 30 days—not abandoned.
  • It’s tiny. The 0.4.2 image is only 142MB (docker images | grep homelabinfo).

The rough edges (as of v0.4.2):

  • No authentication. If your lab is exposed, do not put this on the internet. Use a reverse proxy with basic auth or Cloudflare Access.
  • No alerting. It won’t email you when a device disappears—but it will show it as “offline” in the graph with a red border. You have to notice.
  • Limited historical analysis. You can scroll back 30 days, but there’s no “compare traffic delta between Tuesday and Thursday” widget. It’s observational, not forensic.
  • No Windows agent support (and no plans—per the README). It sees Windows devices fine via nbstat/ssdp, but won’t fingerprint winver or wmic output.

So—should you deploy it? If you’re reading this, you already have 3 or more services running and a nagging feeling that “something’s off but I can’t put my finger on it”, then yes, deploy it tonight. It took me 11 minutes to get from git clone (well, docker pull) to a live graph. And once it’s running? You’ll find yourself glancing at it daily, like checking the weather. Not because you need to—but because it answers the question you didn’t know you were asking: “What’s really going on in my lab right now?”

That’s rare. And honestly? Worth every star on GitHub.

View on GitHub →