Pocketdesk, self-healing homelabs, and running your own GitHub

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

[Audio embed placeholder]

The Lead: Pocketdesk: your Linux or Windows PC on your Android phone, with no account, no cloud service and no port forward

Pocketdesk v0.8.2 streams your Linux or Windows desktop to an Android phone over QUIC with hardware H.264/HEVC. Pair once with a QR code, no account or cloud server. Remote access via LAN, tailnet, or iroh hole-punching with optional self-hosted relay. Per-phone permissions, Home Assistant MQTT discovery, and an unusually honest SECURITY.md.

Why it matters: This is a genuinely self-hosted remote desktop with no middleman, no port forwarding, and transparent documentation of what the relay sees. For anyone who wants their desktop accessible from a phone without trusting a third-party service, this is a strong option.

Source: r/selfhosted

News Roundup

Cleaning up metadata in a large Audiobookshelf library, one night at a time

A nightly job matches tens of thousands of audiobooks and e-books against a national library catalogue and two store APIs, with per-night rollback and an honest account of mistakes made along the way.

Why it matters: Metadata cleanup at scale is a common pain point for homelab media libraries. The per-night rollback pattern is a practical safeguard worth stealing.

Source: Lemmy.World - selfhosted

Narratarr: A Self-Hosted Audiobook Manager With a Built-In Player

Narratarr is a new self-hosted audiobook manager in the *arr tradition, with discovery, downloads, and a built-in browser player in one Docker container. Connects to LibriVox and Old-Time Radio from the Internet Archive, plus Prowlarr and SABnzbd for Usenet.

Why it matters: Audiobook management has fewer options than video or music. Narratarr bundles discovery and playback in one lightweight service, though it’s very new and torrent support requires Real-Debrid.

Source: Noted

Tool & Software Highlight: Run your own GitHub with Forgejo

After GitHub outages, one self-hoster moved personal repos to Forgejo: a community-driven fork of Gitea with repositories, pull requests, issues, Actions, packages, and a container registry. Deployed in a k3s cluster with Flux, PostgreSQL, and a 5Gi volume. SSH and web access are split, and the Actions runner mounts the Docker socket for trusted repos only.

Why it matters: Forgejo offers a lightweight, GitHub-compatible self-hosted platform for personal projects. The writeup covers practical gotchas like missing cache services and split access patterns, making it a realistic guide for anyone considering a second Git home.

Source: dev.to

Community Highlight: My self-healing homelab saved 17 seconds. Here’s why I kept it

A power cut took down a reverse proxy and the alerting path that depended on it. The author built an auto-remediation chain: Prometheus → Alertmanager → n8n → a policy gate → an executor with a closed action list. The real work was teaching the bot when to refuse—nine verdicts, only one means act. Hard ceilings, cause hierarchies, and a canary that proves the chain is alive. The automated chain recovered in 33 seconds vs 50 for an alerted human, but the real value was the smoke detector.

Why it matters: This is a deeply practical, honest account of building automation that knows when not to act. The lessons about verifying recovery, handling planned maintenance, and avoiding confused deputy problems are directly applicable to any homelab.

Source: dev.to

Sources

Transcript

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

Host A: Let’s start with a project called Pocketdesk, now at version 0.8.2. The pitch is appealing: your Linux or Windows desktop, live on your Android phone, with no account, no cloud service, and no port forwarding. The developer has been building it since mid-2025 and posted it on the self-hosted subreddit this week. It’s a Rust server that runs on your own computer, supporting Linux on Wayland or Windows 10 and 11, with a desktop app to manage it and a native Android app as the companion. The phone gets the computer’s live screen streamed as hardware-encoded H.264 or HEVC over QUIC, plus touch, trackpad, keyboard and gamepad control, and the computer’s audio. That’s a lot of control options, but the core is the screen streaming.

Host B: The self-hosting details are the interesting part. Pairing happens once with a QR code on the local network, and each end pins the other’s key over TLS 1.3. There’s no Pocketdesk server in the middle at all. [curious] For remote access, it works over the LAN, a tailnet, or iroh hole-punching with no port forward, and when a direct path can’t be punched, traffic falls back to a relay: n0’s public relays by default, or a self-hosted one. One switch, reachable from the internet, turns the whole internet path off, leaving LAN or Tailscale only. Permissions are per phone, so one phone can get screen access only and another full control over files and clipboard. It also exposes itself to Home Assistant over MQTT discovery with no YAML, sending only metadata like server state and phone battery, never notification or file content.

Host A: [with emphasis] And the SECURITY.md deserves a mention. It’s honest about what a relay actually sees: both IP addresses, who talks to whom, and how much traffic. It also documents what the Mainline DHT record reveals and how to turn each of those things off. That’s the kind of transparency more projects could use.

Host B: Worth noting it’s beta. Hyprland, Sway and Windows are checked on real hardware, but GNOME and KDE Plasma aren’t yet, so reports from those setups are what the developer wants. Install side, there’s a Windows installer, a .deb, an install script, and the AUR, and the phone app comes as an APK or through Obtainium while an F-Droid submission is in review. One commenter asked about remotely revoking a paired phone if it’s lost or stolen, and that question didn’t get an answer in the thread, so how to handle a lost phone is still unclear. Even so, the foundation looks solid for a self-hosted remote desktop.

Host B: Quick tour of the rest of the feed. One self-hoster wrote up a nightly job that cleans up metadata across tens of thousands of audiobooks and e-books in an Audiobookshelf library, matching them against a national library catalogue and two store APIs. The detail worth stealing is per-night rollback, so a bad matching run can be undone the next morning instead of poisoning the whole library. The writeup also includes an honest account of the mistakes made along the way, including the regex work that got the matching behaving.

Host A: On the audiobook front, there’s also Narratarr, a new self-hosted audiobook manager in the Sonarr and Radarr tradition, with discovery, downloads, and a built-in browser player all in one Docker container. It connects to LibriVox and Old-Time Radio collections from the Internet Archive, so thousands of public-domain recordings are browsable without any paid service. Downloads from those collections come straight over HTTPS. Torrent downloads currently require a paid Real-Debrid account since there’s no qBittorrent or Transmission integration yet, though Prowlarr and SABnzbd are supported for Usenet. It’s a very new project, so expect rough edges and little long-term feedback. The built-in player handles multi-file MP3s and M4B books as one continuous listen, remembers the stopping point, and has a sleep timer with a stop-at-chapter option. Finished books land in author and title folders, and it can save into a library Audiobookshelf recognizes and trigger a scan.

Host B: For today’s tool highlight, a writeup on running Forgejo at home, prompted by a rough stretch of GitHub outages. The author’s framing is useful: not replacing GitHub, but asking how much personal work should depend on one provider. Forgejo is the community-driven fork of Gitea, bundling repositories, pull requests, issues, Actions, packages, and a container registry. The author moved over because Gitea’s CI runners were still early, and pipelines matter. GitLab could do the same job, but it’s heavier and brings more than a homelab needs. The setup is small: one Forgejo pod in a k3s cluster deployed by Flux from the same GitOps repository, plus PostgreSQL and a five-gigabyte persistent volume for repository data. Yes, using GitOps to deploy a Git server has a chicken-and-egg smell to it.

Host A: [lighter] Right now GitHub stays the source of truth with everything mirrored into Forgejo, and the plan is to eventually flip that so Forgejo is primary. Two practical wrinkles stand out. First, access is split: the web interface rides a Cloudflare Tunnel, while SSH goes directly through Traefik on the LAN and tailnet using a separate internal hostname. SSH doesn’t carry a hostname that a router can use for traffic splitting, so it gets its own dedicated entrypoint and internal address. Second, the Actions runner mounts the Docker socket from its node, and the author is blunt that this gives jobs effective root access to the machine, so only trusted repositories run there.

Host B: The GitHub-compatible workflows mostly carried over, though the Actions cache service doesn’t exist on a self-hosted runner, so gha-style caching fails, and build attestations could hang on manifest pushes. There’s also a built-in container registry the author is still testing, using the same build actions GitHub workflows already use. Advice for anyone starting: one repository, skip the runner at first, get cloning and mirroring working, then add Actions once the access question is answered.

Host A: For the community highlight, a story from a self-hoster who built an auto-remediation chain for the homelab and timed it against a human. The origin is relatable: a power cut rebooted the servers and the reverse proxy didn’t come back. The alert fired on time, but it reached the phone through a public URL that went through the proxy that was down, so the outage lasted until evening. [thoughtful] That’s the kind of failure that makes automation tempting. The chain now runs Prometheus to Alertmanager to n8n, which asks a policy gate what to do, and an executor that can only run actions from a closed list. The real work was teaching the bot when to refuse. The gate answers with one of nine verdicts, and only one means act; the other eight are refusals, like frozen by a deeper cause or undecidable because Prometheus itself is unreachable. There’s a cause hierarchy so a dead NAS freezes the services that depend on it instead of triggering thirty pointless restarts. Hard ceilings everywhere: three actions per service per hour, ten across the fleet, and the counters live in SQLite on disk so a crash can’t wipe them. The breaker tripped itself on day one after four attempts in the same hour, which the author calls a better test than anything written by hand.

Host B: The subtler lessons are the best part. Recovery is verified through Prometheus probes, not exit codes, and every proof sample must postdate the action, because early versions closed on stale samples. Maintenance mode exists too, so a planned upgrade doesn’t get restarted mid-migration, and if the maintenance file becomes unreadable it’s treated as active, for at most twenty-four hours. [conversational] The Vaultwarden deployment taught the most. An older tool was already restarting unhealthy containers before the new chain could act, and a precondition reading the container’s internal healthcheck disagreed with the external probe. So the precondition became the same HTTP request as the proof. An endpoint that looked like a good health proof responds identically for nonexistent addresses by design, so the real proof became a full end-to-end login. Building that revealed nothing had been watching logins at all, which the author calls the biggest win.

Host A: There’s even a canary: a metric holding the timestamp of the last successful end-to-end run, and if it goes stale past twenty hours, an alert goes into the chain itself, which clears it by running a harmless action. The automated chain went from alert to recovery in thirty-three seconds against fifty for an alerted human standing right there. The honest read is better than the number: it’s one run on each side, and most of the gain arrived the day the probe and alert existed. The value was in the smoke detector, not the fire truck. About twenty services are armed now, each through a full acceptance run with an induced failure first. The frozen-proxy test that used to mean an evening outage came in under three minutes, almost all of it the alert’s confirmation delay. The author closes by asking where others draw the line on automation restarting things, which sounds like a genuinely fun thread.

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