Homelab

My homelab is where I try things before I trust them at work. It’s a single Proxmox VE node that runs my own services the same way I’d run production: isolated, backed by the right storage, reachable through one front door, and patched on a schedule.

The hardware

• One Proxmox VE node: 8 CPU cores and 16 GB of RAM.
• Tiered storage:
  • NVMe for the host and templates.
  • A second NVMe as the default pool for service containers, because they need fast disk.
  • A 1.8 TB HDD for bulk data and media.
• Thin-provisioned LVM pools, so containers only use the space they actually fill.

What runs on it

Each service lives in its own LXC container, so a problem in one can’t spill into the others.

Service	What it’s for
Zoraxy	Reverse proxy and TLS termination: the single front door for every web service
Vaultwarden	Self-hosted password and secrets manager
WireGuard	VPN tunnel into the lab
Jellyfin	Media server
YouTrack	Helpdesk and issue tracking, running in Docker inside its container
Obsidian (in the browser)	My notes, available from any device
Zipline	Private file and screenshot sharing

New services are built from the Proxmox community scripts, driven non-interactively, with storage and telemetry defaults set once for the whole host.

Proxmox Updater

Patching a dozen containers by hand gets skipped, so I wrote Proxmox Updater:

• Scans the Proxmox host and every LXC container for available updates, and understands apt, apk and dnf/yum.
• Linux VMs are opt-in through the guest agent. Windows VMs and Docker containers are detected and skipped, since they have their own updaters.
• Stopped containers get started, updated and stopped again.
• Emails a report over SMTP. By default it only reports; --apply installs the updates.
• Never reboots on its own. It emails “reboot needed” instead.
• Includes a small dashboard, and every change to the lab is recorded in a changelog with a rollback note.

What it’s taught me

• SSL/TLS and HTTPS: issuing, renewing and serving certificates so services are reached over HTTPS.
• Reverse proxying: one front door for every service with TLS terminated at the proxy, which is simpler and safer than exposing ports one by one.
• Resource allocation: sizing CPU, RAM and disk per container on a node with fixed capacity, and placing each service on the storage tier that fits it (NVMe for services, HDD for bulk data).
• Backup planning: deciding what needs backing up, how often, where it lives and how to get it back, before something breaks.
• Reusability: repeatable, scripted installs and shared defaults, so a new service is a known procedure, not an experiment.
• Security: one service per container to keep the blast radius small, secrets in a password manager, remote access over a VPN tunnel, and patching that runs on a schedule.
• Automation and documentation: updates that report themselves actually happen, and every change gets a changelog entry and a way back.

The same habits show up in my day job running Vaultwarden, Snipe-IT and WireGuard for a whole company.