The Hardware

Why Proxmox Instead of Just Running Docker

The Media Stack

The VPN Kill Switch

Hardware Transcoding

The Hardlink Trick

Unprivileged LXC Bind Mounts

Monitoring Stack

The Phantom Alert Bug

Backup Strategy

Infrastructure as Code with Ansible

Public Access via Cloudflare Tunnel

What I Learned

The Stack at a Glance

What's Next I work helpdesk. I wanted to break into DevOps. So I did what any reasonable person would do, I spent three months building an increasingly complicated home server that nobody asked for. What started as "I'll just run Jellyfin on an old PC" turned into a full infrastructure project with containerized services, a monitoring stack, automated backups, infrastructure-as-code, and a CI/CD pipeline. This is a quick story of what I built, the decisions I made and the things that broke along the way. I picked up a Lenovo ThinkCentre M920q for around $200 on eBay. These small form factor machines are practically designed for homelabs. Low power draw, quiet with 8th/9th gen Intel CPUs that have QuickSync hardware transcoding which matters a lot for Jellyfin. For storage I added a Terramaster D4-320 DAS (Direct Attached Storage) enclosure with two 4TB HDDs, I had drives laying around that had ~12,700 hours on them, which I'll come back to. The two drives are combined into a single 7.3TB LVM volume. The first decision was the foundation. I could have just installed Ubuntu and run Docker Compose directly. Instead I went with Proxmox VE - a bare metal hypervisor that lets you run multiple isolated VMs and LXC containers. Isolation - each service gets its own container. If something breaks or gets compromised, it can't affect everything else. Sonarr crashing doesn't take down Prometheus. A misconfigured container doesn't expose your monitoring stack. LXC over VMs - Linux Containers are lighter than full VMs. An LXC for Prometheus uses 512MB RAM and starts in two seconds. A full VM for the same workload would use 2GB+ and take 30 seconds to boot. Unprivileged containers - I run everything in unprivileged LXCs. This means the container's root user maps to an unprivileged user on the host (UID 101000 instead of 0). Even if someone escapes the container, they land as an unprivileged user on the host with no meaningful access. The tradeoff is bind mount complexity - I'll get to this a bit later. The result is 15 LXCs each running a specific role, isolated from each other, with the Proxmox host managing them all. This was the original goal and it's where I spent the most time. The full pipeline looks like this: Everything runs as Docker containers inside a single Docker LXC. I use Docker Compose to manage the stack - a single docker-compose.yml defines all 20+ services, their networking and their volumes. Every torrent goes through a VPN. Most people configure qBittorrent to bind to the VPN interface. The problem is this relies on the application to enforce the kill switch — if the VPN drops, there's a window where traffic might leak before qBittorrent detects it. Instead I use Gluetun - a VPN container that creates a network namespace, and run qBittorrent inside that namespace: This is enforced at the kernel level. qBittorrent physically cannot route traffic outside the Gluetun network namespace. If Gluetun stops, qBittorrent loses all network access because the network interface practically disappears. The M920q's Intel QuickSync is passed through to the Docker LXC via the Proxmox container config: Jellyfin uses QSV to hardware decode/encode H.264, HEVC, VP9 and AV1. Transcoding a 4K stream uses about 15% CPU with hardware acceleration vs 100%+ without it on this hardware. Downloaded media and the Jellyfin library live on the same filesystem (/mnt/data). When Sonarr/Radarr import a file they create a hardlink rather than copying it - the file appears in both the downloads folder and the media library simultaneously while only consuming disk space once. A 30GB season pack is "moved" to the media library instantaneously with zero additional disk usage. This only works when both locations are on the same filesystem, which is why the folder structure matters. This tripped me up for an entire evening. When you bind mount a directory from the Proxmox host into an unprivileged LXC, the UID mapping means the LXC's root user (UID 0 inside) maps to UID 101000 on the host. So when you chown a directory on the host to give the LXC access, you don't do: Using 1000 means the LXC can't write to the directory even though it looks like it should work. I was confused by the error messages, the fix is a single number change. I wanted to know when things were going wrong before users (me) noticed. The stack is Prometheus + Grafana + Alertmanager, each in their own LXC: The SMART monitoring took two weeks to get right because of a subtle conflict I didn't know existed. When you install prometheus-node-exporter on Debian via apt, it ships with a built-in SMART monitoring service: prometheus-node-exporter-smartmon.service and its accompanying systemd timer. This service runs every 15 minutes and writes SMART metrics to the same textfile directory I was using. The problem: the built-in script couldn't read my USB-attached DAS drives. When it ran, it wrote 0 for all health metrics — overwriting my correct values. My cron job ran every minute and would fix it within 60 seconds. But Prometheus scrapes every 30 seconds. So there was a brief window every 15 minutes where Prometheus might scrape during the "bad" state. With my alert rule set to fire after 20 minutes of sustained failure, it took several consecutive bad scrapes to trigger — which happened a few times per night. The fix was renaming my metrics from smartmon_* to custom_smart_* and writing to a differently named file. The conflict disappeared immediately. I run three backup tiers: Daily local backups - Docker configs and LXC configuration files tarball to the DAS. If the OS SSD dies, the configs are on the DAS. Weekly Proxmox snapshots - VZDump snapshots of all LXCs to the DAS. Full restore from these takes about 15 minutes. Weekly offsite backups - rclone syncs config files to Cloudflare R2. The 10GB free tier is more than enough for text configs. This survives the house burning down scenario. The offsite backup is config files only. At 7.3TB, media isn't worth backing up remotely. The ARR stack can rebuild the library automatically from scratch. I monitor R2 bucket size in Grafana with custom Prometheus metrics and have alerts set at 8GB (warning) and 9GB (critical) so I never accidentally hit the free tier limit. Once the homelab was running I realized I had no reproducible way to rebuild it. Everything was manual commands I half-remembered. I wrote an Ansible project to fix this: Dynamic inventory - instead of maintaining a static list of hosts, Ansible queries the Proxmox API directly. Every LXC automatically appears in inventory. New LXC created? It's immediately manageable. LXC destroyed? Gone from inventory. Base role - applied to every LXC on creation: SSH hardening, standard packages, timezone, MOTD, unattended upgrades. One command hardens 15 machines simultaneously. Provisioning playbook - spins up a new LXC from scratch. Change six variables and run one command. The new LXC is created, started, SSH key injected, packages installed, and ready to use. Update playbook - runs apt upgrade across all 15 machines in parallel. What used to take 20 minutes of typing in commands now takes one command and 90 seconds. GitHub Actions CI - every push to the Ansible repo triggers yamllint and ansible-lint automatically. The pipeline fails if any playbook has syntax errors or style violations. The Ansible repo: github.com/NicolaiMatthew/homelab-ansible I wanted to access Jellyfin remotely without opening ports on my router or exposing my home IP. Cloudflare Tunnel creates an outbound-only encrypted connection from my server to Cloudflare's edge. Traffic flows: No ports open on my router (yay). Cloudflare handles DDoS protection, SSL certificates, and bot filtering for free. One gotcha that cost me an hour of debugging: Nginx Proxy Manager was set to Force SSL which caused an infinite redirect loop. Cloudflare already terminates SSL before the request reaches my network — NPM doesn't need to force it again. Disabling Force SSL in NPM fixed it immediately. Another gotcha: cloudflared runs inside the NPM LXC and needs to connect to NPM via localhost:80, not via the LXC's external IP. LXCs can't connect to their own external IP from within themselves, which is by design. Isolation is worth the complexity. Running 15 LXCs instead of one big Docker host adds overhead but has paid off repeatedly. Services can be restarted, updated, and debugged independently. Document as you go. My Obsidian vault syncs to GitHub automatically. Every service has a markdown doc covering the setup, decisions, and gotchas. When something breaks at 2am, future me is grateful. The bug is rarely where you're looking. The SMART monitoring conflict, the Docker iptables blocking NPM connections, the missing gateway on a newly created LXC - all of these were caused by something outside the thing I was debugging. Check your assumptions first. Automate the maintenance, not just the deployment. The update playbook gets used weekly. The provisioning playbook has been used a handful of times. Automation that saves you time on recurring tasks has more value than automation that saves time on one-time setups. The full documentation lives at github.com/NicolaiMatthew/homelab. If you're thinking about building something similar, the Lenovo ThinkCentre M series (M720q, M920q, M920x) are the go-to recommendation for budget homelabs. Low power, quiet, capable, and cheap on the used market. The community-scripts project for Proxmox makes spinning up new services trivial. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse