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. ...

The 3-2-1 backup guide on this site makes the case for an off-site copy without picking a specific home for it. That’s deliberate, because “off-site” covers everything from a hard drive at your parents’ house to a proper cloud object storage tier, and which one makes sense depends entirely on how you actually plan to use it. This article is the follow-up: assuming you’ve decided cloud is part of your off-site story, which service, and why. ...

Every hardware guide on this site so far has assumed the rack already exists. Buying used enterprise gear, sizing a UPS, picking a managed switch, all of it takes for granted that there’s somewhere to physically put the thing. That assumption falls apart fast for anyone starting from a mini PC on a shelf and a switch zip-tied to the underside of a desk. This is the article that comes before all of those: the cabinet itself, the rails that hold gear in it, the power distribution feeding it, and the cable management that decides whether adding a fourth device is a five-minute job or an afternoon of re-routing everything you already installed. ...

Sooner or later almost every Proxmox host grows a USB device that needs to talk to one specific guest. A Zigbee or Z-Wave radio for Home Assistant, a TV tuner for a media server, a serial adapter for a UPS, a security dongle for some old piece of software that still checks for one. Getting that device into the right VM or container is usually simple the first time and then mysteriously stops working after the next reboot, because the setup that worked was tied to something that wasn’t actually stable. Here’s how passthrough actually works for both VMs and LXCs, and where the stability problem comes from. ...

If you’re running any homelab automation at all, sooner or later you end up wanting a place to put your own code, Ansible playbooks, docker-compose files, a scheduled content pipeline, whatever you’ve cobbled together, that isn’t a public GitHub repo and isn’t subject to GitHub’s own uptime, rate limits, or terms of service. Self-hosting a git server used to mean a lot of manual setup. Now it means picking between a handful of mature, actively developed options that install in minutes. The three worth actually considering are Gitea, Forgejo, and GitLab Community Edition, and they are not equally good fits for the same job. ...

Every drive you own is going to fail eventually. The part that catches people off guard is when. Hard drive failure rates don’t sit flat over a drive’s life, they follow what’s usually called a bathtub curve: a spike of early failures right out of the gate, a long flat stretch of low failure rate through the drive’s useful life, and a rising tail of wear-related failures years later. Burn-in testing exists to deal with that first spike, on your terms, before the drive is holding data you care about. ...

Every homelab ends up with SSDs doing several different jobs at once: booting the hypervisor, holding VM disks, backing a ZFS special vdev or SLOG, maybe just serving as bulk fast storage for a database. Most buying advice treats this as one decision, “get an SSD, more capacity is better,” and stops there. That’s fine for a boot drive. It’s a real mistake for anything doing sustained writes, and it can quietly cost you data integrity on a ZFS log device. The differences between consumer and enterprise flash are specific and they map directly onto which job a drive should actually do. ...

Every Proxmox host ships with snapshots built in, and they’re so easy to take that it’s tempting to treat them as your backup strategy. Click “Snapshot” before a risky change, click “Rollback” if it goes wrong, done. That workflow is genuinely useful, and you should use it. It is also not a backup, and conflating the two is one of the more common ways homelab operators discover, at the worst possible moment, that they had less protection than they thought. ...

Every other self-hosted app on this site replaces a subscription with something you run yourself. AI is a little different, the frontier cloud models are genuinely ahead of anything you can run on homelab-grade hardware, and pretending otherwise sets you up for disappointment. What self-hosting AI actually buys you is privacy for anything you don’t want leaving your network, zero per-token cost for high-volume low-stakes tasks, and a model that keeps working when your internet doesn’t. Ollama and Open WebUI are the two pieces most homelabbers land on to get there, and they’re worth understanding separately before you stand up either one. ...

Every hoard past a certain size has duplicates in it, and not the kind you know about. It’s not usually the obvious “Copy of file (1).jpg” pattern. It’s the same movie sitting in three different folders because a download client, a manual import, and an old backup all landed a copy in a slightly different place. It’s a photo library synced from two phones that both uploaded the same shot. It’s a decade of “just copy it over to be safe” that never got cleaned up. None of this shows up until you actually go looking for it, and by then it can be a meaningful fraction of your total storage. ...