Homelab

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

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

Proxmox ships with a real, iptables-backed firewall built into the platform, and most homelabs never turn it on. It’s not enabled by default at any level, so unless you’ve gone looking for it in the UI, there’s a good chance your VMs and containers are sitting behind nothing but whatever VLAN segmentation you’ve set up, if any. That’s often fine. It stops being fine the moment you’re running something internet-facing, or you want one VM to be reachable only from your management network and nowhere else, or a compromised guest shouldn’t be able to freely talk to everything else on its VLAN just because they share a broadcast domain. This is what the built-in firewall is actually for, and it’s worth understanding the shape of it before you flip it on. ...

Ditching Google Drive or Dropbox is one of the most common reasons people start self-hosting in the first place, and it’s also one of the easiest to get wrong by picking the wrong tool for the job. Nextcloud and Syncthing both get your files off someone else’s server, but they’re built on completely different models, and picking the one that doesn’t match how you actually work is how people end up frustrated and quietly back on Dropbox six months later. Here’s what each one actually is, where they overlap, and how to pick. ...

The Proxmox-vs-ESXi comparison on this site already covers why so many homelabbers are moving off VMware since the Broadcom licensing changes gutted the free ESXi tier. This one skips the “should I switch” question and gets into the part that actually trips people up: what breaks when you move a real VM from ESXi to Proxmox, and how to get ahead of it instead of debugging a guest that won’t boot at 11pm. ...

Every homelab operator hits the same wall eventually: you need a fifth Ubuntu VM for some new service, and the thought of walking through another OS installer, setting the hostname, adding your SSH key, and running updates makes you want to just leave the last one running forever instead. Cloud-init templates fix this. Build the template once, and every new VM after that is a clone plus a few lines of config, done in under a minute instead of fifteen. This is the same workflow cloud providers use to spin up instances on demand, and Proxmox supports it natively, no extra tooling required to get the basics working. ...