home-dc-kubernetes, Part 5: The App Catalog — What Actually Runs

The workloads #

We’ve spent the last four parts building the "engine" — the nodes, the OS, the GitOps brain, and the platform plumbing. Now we get to the part everyone actually cares about: the workloads.

My approach to the app catalog is based on Categorical Isolation. I don’t just dump apps into the cluster; I organize them by their operational profile and resource needs into dedicated namespaces. This keeps the blast radius small and the management clean.

1. The Media Powerhouse #

This is the most resource-intensive part of the lab. It’s a fully automated media pipeline designed to be invisible until you want to watch something.

• The Core: Jellyfin as the frontend, backed by a shared CephFS library.
• The Automation: The "Arr" stack (Sonarr, Radarr, Prowlarr) handles discovery and organization.
• The Pipeline: Sabnzbd for downloads, Tdarr for automated transcoding, and qBittorrent for torrents.
• The Discovery: Jellyseerr provides a request portal for users, which feeds directly into the Arr stack.
• The New Addition: HomeTube — a focused frontend for a specific content niche.

Everything here is backed by the replicated Ceph storage we built in Part 4, so a node failure doesn’t mean losing your library metadata.

2. The Productivity Toolkit #

These are tools that don’t need 24/7 heavy resources but are critical for day-to-day operations:

• n8n: The glue. Used for automating everything from GitOps notifications to home-dc health checks.
• Linkwarden: A self-hosted bookmark manager for the countless technical docs I refer back to.
• Stirling-PDF: A Swiss army knife for PDF manipulation, kept entirely on-prem for privacy.
• Code-Server: A full VS Code instance in the browser, allowing me to tweak manifests and scripts from any machine without local setup.

3. Monitoring (The Watchtower) #

You can’t manage what you can’t measure. The monitoring stack is designed to be proactive, not reactive:

• The Stack: kube-prometheus-stack (Prometheus + Grafana + Alertmanager).
• The Visibility: Everything is exported as metrics and visualized in Grafana dashboards.
• The Alerts: Integrated with Slack — if a node goes down or a PVC hits 90%, I get a notification before I notice the lag.

The "One Pane of Glass" Strategy #

I use Homepage and Glance as the frontend. Instead of remembering 20 different URLs, I have a single dashboard that integrates with the Kubernetes API to show the real-time status of my apps, the health of the clusters, and the current load on the nodes.

The takeaway #

The app catalog isn’t just a list of software; it’s a reflection of how I use my lab. By isolating Media, Productivity, and Monitoring, I can scale them independently and ensure that a runaway Tdarr transcode doesn’t crash the Monitoring stack and leave me blind.

Next up in Part 6: the operating model — Taskfile, CI, Renovate, and the recovery drills that prove this whole thing actually works.