rHomelab

Every fresh Proxmox install nags you about a missing subscription the first time you log into the web UI, and most homelab operators click past it, point apt at the no-subscription repo, and never think about the update process again until something breaks. That’s fine for routine point releases. It stops being fine the day you need to jump across a major version (7 to 8, 8 to 9, whatever the next one is), because that’s the one update that can genuinely strand VMs, break a cluster’s quorum, or leave a ZFS pool on a format the old kernel can’t mount if you do it carelessly. The repo choice and the upgrade sequence are two separate things worth understanding on their own. ...

Metrics tell you a service is dying. Logs tell you why. If you’ve ever SSH’d into three different containers in a row trying to figure out which one actually threw the error that broke your reverse proxy, you already know the gap that centralized logging fills. Uptime checks and Grafana dashboards (covered in the monitoring stack guide) tell you something is wrong and roughly when. Logs tell you what the service was actually doing in the seconds before it went wrong, and without them you’re stuck doing docker logs on one container at a time, hoping you guessed right on the first try. ...

Burn-in testing catches a bad drive before it ever holds data. Bit rot scrubbing catches silent corruption on drives that are otherwise working fine. Neither one watches a healthy drive for the slow, specific warning signs that show up months or years into its working life, the gradually climbing error counts that mean a drive is dying, not corrupted or defective out of the box. That’s a separate job: ongoing SMART monitoring with an actual alert attached to it, not a dashboard you remember to check every few months. ...

Every data hoard eventually outgrows its case. The main server is full, the HBA’s ports are full, and the next logical move looks like building a second NAS from scratch, a second motherboard, a second CPU, a second OS to patch and monitor. Before doing that, it’s worth asking whether the actual problem is “I need more compute” or just “I need more drive bays,” because those are different problems with different, much cheaper answers. A DAS enclosure is the second answer: a box of drive bays with no brain of its own, attached to a host system that already exists. ...

Most single-operator homelabs run everything as root@pam. You log in as root, every VM shows up, every setting is reachable, and that’s fine right up until you want someone else to have access too, a roommate who wants to spin up their own VM, a family member who needs to restart one container, or a script that needs to talk to the API without holding the keys to the entire cluster. At that point “just use my login” stops being a reasonable answer, and Proxmox’s actual permission system, which almost nobody touches because the default single-user setup never forces you to, becomes worth understanding. ...

If you’re running any kind of self-hosted site, a blog, a Lemmy instance, a Nextcloud share page, you eventually want to know who’s showing up and what they’re looking at. The default answer most people reach for is Google Analytics, which is free, well-documented, and also means routing every visitor’s browsing behavior through Google’s ad infrastructure, adding a consent-banner requirement under GDPR/CCPA in a lot of jurisdictions, and accepting a tracking script bloated enough that privacy-focused browser extensions block it outright, quietly undercounting your own numbers. For a homelab operator who’s already self-hosting everything else, self-hosting analytics too is a natural next step. Plausible, Umami, and Matomo are the three real options, and they are not interchangeable. ...

Most data hoarding advice is about keeping data alive: redundancy, checksums, off-site copies. Almost none of it is about keeping that data private if a drive leaves your control. And drives leave your control more often than people think - a failed disk goes back to the manufacturer under warranty, a drive gets sold or handed off once you upgrade capacity, a laptop or external drive gets lost or stolen. If none of that data was encrypted, every one of those events is a potential data breach, not just an inconvenience. ...

Anyone who’s bought a used enterprise server for a homelab has had the same moment: it powers on, the fans spin up to full speed for the POST sequence, and for about fifteen seconds it sounds like the room is about to take off. Most of the time it settles down after boot. Sometimes it doesn’t, and that’s when the real work starts. Noise and heat are two sides of the same problem in a home environment, and neither one is solved by just wanting it to be quieter. ...

Clicking through the Proxmox web UI to build a VM is fine the first few times. It stops being fine once you’re rebuilding the same handful of VMs for the fifth time after a test, or trying to remember exactly which CPU type, disk size, and network bridge you used for a box six months ago. Terraform (or its open-source fork OpenTofu, which this article treats as interchangeable since the Proxmox providers work with either) fixes that by making the VM’s configuration a text file instead of a memory. This is not about replacing Proxmox’s own tooling, it’s about not having to rebuild a guest from memory ever again. ...

Somewhere between your third and tenth self-hosted app, running everything by SSHing in and typing docker compose up -d stops being charming and starts being a chore. You forget which directory a stack lives in, you lose track of which containers have image updates waiting, and checking logs means remembering the right docker logs -f incantation for each one. A web UI on top of Docker doesn’t replace knowing the CLI, you still need it for anything that goes wrong, but it turns routine maintenance into a few clicks instead of a few minutes of typing. The three worth actually considering for a homelab are Portainer, Dockge, and Yacht, and they solve different-sized versions of this problem. ...