A single-binary analytics stack, resurrected Decos, and a lab redrawn in six diagrams

Homelab Highlights for 2026-10-19: self-hosting and homelab notes worth knowing.

[Audio embed placeholder]

The Lead: pug.sh: self-hosted web and product analytics with a single-binary Go backend

pug.sh is an open-source web and product analytics tool built over the past year. The entire backend is a single Go binary that runs the API server and all workers in one process, with migrations and scheduled jobs as subcommands. It requires Postgres, ClickHouse, NATS, and Redis or Dragonfly alongside it. Features include trends, funnels, retention, user flows, per-user profiles, and a live visitor map, with SDKs for web, Node, Flutter, and Ruby. The web SDK is cookieless by default and visitor IPs are never stored. Unlike Plausible, pug links anonymous visits to signed-in users to track individuals across sessions and devices.

Why it matters: Most self-hosted analytics stop at anonymous visit counts. pug fills the gap for retention and funnel analysis by tying behavior to identities, making it a serious option for homelabbers who need product-level analytics without sending data to a third party.

Source: r/selfhosted

News Roundup

Promtail is end of life: ship your homelab’s logs to Loki with Grafana Alloy instead

Promtail reached end of life on March 2, 2026. Grafana’s documentation states it receives no further updates and future development happens in Grafana Alloy. The article walks through migrating to Alloy: it runs as a native service, tails the systemd journal and Docker logs, attaches labels, and pushes to the same Loki. A key gotcha is that the alloy user must be in the adm and systemd-journal groups, or the journal source starts silently and collects nothing.

Why it matters: If your homelab still uses Promtail for log shipping, it’s time to migrate. Alloy is the actively maintained replacement, and the migration is a config rewrite, not a rebuild.

Source: DEV Community

A homelabber reverse-engineered TP-Link Deco firmware to add proper 802.1Q VLAN tagging for IoT devices. They found that the IoT VLAN toggle in the app is a no-op in AP mode, and that TCP port 20001 still exposes full root file read and write — two years after researchers demonstrated the vulnerability at Black Hat 2024. TP-Link only bumped an SSH key size in the latest firmware. The poster published both a security advisory and a repo that enables true VLAN 30 tagging across mesh units to OPNsense.

Why it matters: Every Deco owner should restrict port 20001 and ensure their TP-Link ID password is unique. The vulnerability is still unpatched, and the constructive workaround keeps working hardware out of the landfill.

Source: r/homelab

GoveeToMQTT Bridge not working

A Home Assistant user could not get the govee2mqtt bridge working with H601E recessed lights. The bridge successfully queried Govee’s platform API but then hit an undocumented account API and received HTTP status 454. The bridge refused to continue, printing a clear explanation that repeated intermittent failures could make entity names inconsistent. The workaround is to remove Govee API credentials, switching to LAN-only mode, which loses control of devices without LAN API support and reduces entity name descriptiveness.

Why it matters: This bridge relies on an undocumented API that can change or throttle without notice. Knowing the LAN-only fallback is essential for reliable smart home operation.

Source: r/homelab

Tool & Software Highlight: New $30 plan versus the legacy Cursor $20?

A Cursor user is confused by the plan page comparing a new $30 plan to an $8 plan they don’t recognize, while they are on a legacy $20 plan. They valued the generous Grok Bot usage on the old plan and find the new structure less attractive, even though they like Composer. The thread has no resolution, and the post reflects one user’s interpretation.

Why it matters: When a central tool changes its plan structure, it’s worth auditing what your legacy plan actually provides and comparing against real usage, not marketing emphasis.

Source: r/cursor

Community Highlight: My October homelab update: Proxmox, Talos Kubernetes, HAProxy/BGP and TrueNAS, mapped across six diagrams

A homelabber redrew their network diagrams into six focused views after moving applications from Docker Swarm to Talos Kubernetes and retiring a NetScaler SDX for an HAProxy pair. The setup includes three Proxmox hosts with 39 VMs, seven Talos nodes, Cilium, MetalLB, GitLab/Flux, and two TrueNAS systems. The write-up addresses trade-offs like keeping MetalLB when Cilium can handle load balancing, and whether separate control-plane and worker VMs buy anything across only three physical hosts.

Why it matters: This is a reference architecture for anyone planning a similar build. The six-diagram approach is a practical way to document a complex homelab, and the honest discussion of trade-offs is valuable for decision-making.

Source: r/homelab

Sources

Transcript

Host A: Welcome to Homelab Highlights, the show that surfaces practical homelab wins and useful self-hosted tools.

Host A: Top story today comes out of r/selfhosted, and it is a project called pug.sh — open-source web and product analytics built by two developers over the past year. First commit landed back in October of 2025, it went public in June, and the pitch is that self-hosting unlocks every feature. The part the comments immediately fixated on: the whole backend is a single Go binary. One command starts the API server and every worker in one process, and even the migrations and scheduled jobs are subcommands of that same binary. Host B: Now, single Go binary is a phrase that gets thrown around a lot, but here is the honest caveat: that one binary does not run alone. The docs call for Postgres, ClickHouse, NATS, and Redis or Dragonfly next to it. So it is one process sitting on top of four backing services — a real chunk of resources on a homelab, though anyone who has run ClickHouse knows that is the price of fast analytics queries. Host A: What is inside is where it gets interesting, because this is not just page counters. It does trends, funnels, retention, user flows, per-user profiles, and a live visitor map. SDKs cover web, Node, Flutter, and Ruby. The web SDK is cookieless by default, and visitor IPs are never stored. And the differentiation came out in the comments: someone compared it to Plausible, and one of the developers replied directly — Plausible deliberately avoids tracking individual users, while pug links anonymous visits to signed-in users and keeps a profile per person, so funnels and retention follow the same human across sessions and devices. Asked what a switcher gets coming from Umami, the same answer applied: if only site stats are needed, Umami is the lighter, mature fit. Pug is for the people side. Host B: That per-person model is genuinely the gap it fills — most self-hosted analytics stops at anonymous visit counts, and the moment a retention question comes up, the answer is a shrug. Worth being honest that tying visits to identities puts this in a different privacy category than a cookieless counter, even with IPs discarded. One practical note from the thread: a commenter reported the public demo was erroring out, so check it before committing an afternoon. There is a Discord linked in the post, the repo is on GitHub under pug-sh, and the self-hosting docs walk through the stack. If the four-service footprint fits the hardware, this looks like a serious self-hosted answer to the product-analytics question.

Host B: Quick stop first: Promtail, the log shipper half of every old Loki tutorial, reached end of life on March 2 of this year. Grafana’s documentation is explicit that it gets no further updates and future development happens in Grafana Alloy, so new setups should start there. The write-up over on DEV walks the migration: Alloy runs as a native service on each host, tails the systemd journal and Docker logs, attaches labels, and pushes to the same Loki. One gotcha the author flags is easy to miss — the alloy user needs to be in the adm and systemd-journal groups, and without that the journal source starts up silently and collects nothing. Host A: Which is the kind of failure mode that costs someone a whole evening. Same Loki destination, same LogQL queries afterward — it is a config rewrite, not a rebuild. Speaking of digging into things, here is the heavyweight of the feed: a post on r/homelab titled, more or less, e-waste three TP-Link Deco XE75 Pros or reverse-engineer the firmware. The post describes a setup with Decos in access-point mode in front of a firewall like OPNsense, and the Deco app has an IoT Network toggle that dumps everything untagged onto the LAN — no VLAN ID, and the guest-network VLAN trick silently fails in AP mode. Host B: So they decrypted and unpacked the 1.5.0 firmware, and found the IoT VLAN knob exists in the config but is a no-op — the code is there, commented out, and the helper script that would apply it was omitted from the image entirely. To make changes stick they needed root, and got it through TCP port 20001 — a debug service researchers demonstrated at Black Hat and CCS back in 2024. Two years later, on current firmware, the file-read and file-write handlers on that port are still wide open. According to the post, the only change TP-Link made was bumping an SSH key size. Host A: That is the part that should worry every Deco owner regardless of VLAN ambitions. The poster’s takeaway: make sure the TP-Link ID password is unique, and restrict port 20001, because it still exposes full root file read and write. The constructive side is they published everything — an advisory with the proof of concept, and a repo called deco-iot-vlan that got true 802.1Q tagging working, VLAN 30 bridged across all three mesh units straight to OPNsense. Keeping working hardware out of the landfill by doing the vendor’s job for them. Host B: Last feed item, and it is a troubleshooting story from the Govee side of the smart home. Someone new to Home Assistant could not get the govee2mqtt bridge working with their recessed H601E lights — the lights were fine in the Govee app, but the bridge kept failing at startup. The log shows the bridge querying Govee’s platform API successfully, then hitting an undocumented account API for the device and room list and getting back HTTP status 454, which is not a standard code. The poster was confident the credentials were right, because the login itself returned okay. Host A: What makes the thread worth a read is how the tool handles it. Instead of crash-looping, govee2mqtt printed a clear explanation and stopped: repeated intermittent failures could make entity names inconsistent, so it refuses to continue on a bad discovery. The workaround it offers is removing the Govee API credentials entirely, which switches the bridge to the local LAN API only — with two stated consequences: devices without LAN API support become uncontrollable, and surviving devices get less descriptive entity IDs because the cloud metadata is gone. The one reply in the thread suggested 454 is usually a rate limit or login block on Govee’s side, and to give it twenty-four hours before retrying. Either wait it out and keep the cloud features, or cut over to LAN mode and accept the tradeoffs. The broader lesson: this bridge leans on an undocumented API that can change or throttle without notice, so knowing where the LAN-only fallback lives is worth ten minutes of reading.

Host A: Tool highlight this time is a pricing-and-workflow story rather than a self-hosted binary: Cursor, the AI code editor, and a thread on r/cursor about the plan lineup. The poster is trying to compare a new thirty-dollar plan against the legacy twenty-dollar plan they were on, and the plan page is making that genuinely confusing — the thirty-dollar tier is described as four times some eight-dollar plan, which is not a plan the poster recognizes from their own billing history. Host B: That confusion is the relatable part. Anyone who has been on a legacy plan knows the feeling of a pricing page that no longer maps to what is actually being paid. What the poster says they valued under the old twenty-dollar plan was what they describe as a generous amount of Grok Bot usage, and they find Grok Bot more attractive than the current plan structure — even though they generally like Composer and credit it with getting a lot of work done in the past. Host A: There is no resolution in the thread, and it is worth being careful here: this is one user’s read of the plans as of the post, not a verified breakdown of what each tier includes now. The useful takeaway for operators is more general — when a tool this central to the daily workflow changes its plan structure, it is worth checking what the legacy plan actually still provides before letting a renewal decide, and comparing against what is actually being used rather than what the marketing page emphasizes. For homelab folks who use AI editors alongside the self-hosted stack, that habit of auditing the bill against real usage applies well beyond Cursor.

Host B: Community highlight goes to an October update post on r/homelab where the author admitted the network diagrams had fallen badly behind reality, so everything got redrawn and written up — and it is a good reference architecture for anyone planning a similar build. The headline changes: applications moved off Docker Swarm onto Talos Kubernetes, and a NetScaler SDX got retired in favor of an HAProxy pair. The current shape is three Proxmox hosts with thirty-nine VMs, seven Talos nodes split between three control planes and four workers, Cilium for cluster networking, MetalLB for load-balancer addresses, and GitLab with Flux handling GitOps. Storage is two TrueNAS systems doing NFS and ZFS replication, plus Proxmox Backup Server running as a VM on the second NAS. Host A: The presentation is the part worth stealing: instead of one enormous diagram, six focused views — rack and compute, storage and backups, networking, website access, Kubernetes services, and standalone stuff. The write-up follows a request from the internet all the way to a pod, and all addresses in the public versions are anonymized. DNS, some databases, and local AI workloads deliberately stay outside Kubernetes. The comments made it better: someone asked why keep MetalLB when Cilium now does load-balancer IPAM and BGP itself, and the author answered honestly that nothing forces MetalLB to stay — consolidating would be a reasonable simplification. Host B: Another commenter pushed on whether separate control-plane and worker VMs across only three physical hosts buys anything, since the failure domain is the same physical box. The author’s reply is the useful part: the separation is real for operations — workers can be drained, rebuilt, and upgraded independently — but placement is what actually matters for surviving a node failure, and migration alone does not guarantee one etcd member per physical host. Anti-affinity has to be enforced deliberately. And the author closed by asking the room a question worth thinking about: the backup server shares a physical failure domain with the second NAS — run PBS on separate hardware, or virtualize it on secondary storage? No universal answer offered, which is exactly the right way to leave it.

Host A: That’s Homelab Highlights for Monday. Until next time, happy hosting!