Projects & home lab

Things I’ve built to learn

My home lab is a working test bed for ideas I want to understand properly. These write-ups cover the goals, the approach and what I learned, kept general on purpose.

01

Building a virtualization lab with Proxmox and VMware

Stack Proxmox VE · VMware ESXi · ZFS · cloud-init

I wanted a lab that felt like a real environment rather than a pile of one-off VMs, so I built it around a few rules: every guest comes from a template, every host is configured the same way, and nothing is precious enough that I can’t rebuild it.

Proxmox VE runs most of the day-to-day workloads. ZFS gives me checksumming, snapshots and replication without extra licensing, and LXC containers handle lightweight services where a full VM would be overkill. I keep a separate VMware environment for comparing behavior and practicing the workflows that show up in enterprise shops, such as templates, resource pools and vMotion-style migrations.

  • Golden images built with cloud-init so a new Linux VM is ready in about a minute.
  • Consistent naming and tagging so it’s obvious what a guest does and who “owns” it.
  • Separate storage pools for fast VM disks and bulk data.

Lesson learned: the hypervisor is rarely the hard part. Storage layout and networking decisions made on day one are the ones you live with.

02

Segmenting a home network with VLANs and a firewall

Stack pfSense · managed switches · 802.1Q VLANs · Wi-Fi SSIDs per zone

A flat home network puts laptops, smart TVs, cameras and lab servers on the same broadcast domain. I split mine into zones by trust level: personal devices, servers, management interfaces, IoT, and guests. Each zone gets its own VLAN and subnet, and the firewall decides what can talk to what.

  • Default-deny between zones, with narrow allow rules for the traffic that’s actually needed.
  • IoT devices can reach the internet but nothing else on the network.
  • Management interfaces live in their own segment, reachable only from trusted devices.
  • Local DNS and NTP served from inside, with outbound DNS from other resolvers blocked.

Lesson learned: write the rules down in plain English before touching the firewall. “Cameras may reach the recorder and nothing else” is easy to implement and easy to audit.

03

Zero-trust remote access with Cloudflare Tunnel and Access

Stack Cloudflare Tunnel · Cloudflare Access · SSO with MFA · WireGuard as a fallback

I wanted to reach a few self-hosted web apps from anywhere without opening inbound ports on my router. Cloudflare Tunnel makes an outbound-only connection from inside the network, and Cloudflare Access sits in front of each app and requires an identity check before any request reaches it.

  • No port forwarding and no publicly exposed origin.
  • Per-application policies, so access to one app doesn’t imply access to another.
  • MFA enforced by the identity provider, with short session lifetimes for admin tools.
  • A separate WireGuard VPN for the rare times I need full network access.

Lesson learned: the tunnel is the easy part; the policies are the security boundary. Review them like firewall rules. I wrote more about this in a separate note.

04

Self-hosted Git and media

Stack Gitea · Jellyfin · Podman · nginx reverse proxy

I keep my scripts, configuration and documentation in a self-hosted Git service. It’s the source of truth for the lab: if a config file isn’t in Git, it’s considered temporary. A media server handles the family’s movies and music, which turned out to be an excellent lesson in uptime expectations, because nobody is more demanding than a household on movie night.

  • Services run as containers with their data on dedicated, backed-up volumes.
  • A reverse proxy handles TLS and routing so each app stays simple.
  • Updates are scheduled and staged, never “latest” on a whim.

Lesson learned: separate the app from its data. When an upgrade goes wrong, you want to throw away the container and keep everything else.

05

Monitoring with Grafana and Prometheus

Stack Prometheus · node_exporter · Grafana · Uptime checks · alerting

Monitoring started as a few pretty dashboards and grew into the thing that tells me about problems before anyone else notices. Prometheus scrapes metrics from hosts and services, Grafana visualizes them, and a small set of alerts covers the failures that actually matter.

  • Host basics: CPU, memory, disk space, disk health and temperatures.
  • Service checks from outside the network, so “up” means up for real users.
  • Backup job results and certificate expiry tracked as first-class metrics.
  • Alerts tuned aggressively. If an alert fires and I ignore it, it gets fixed or deleted.

Lesson learned: fewer, better alerts. Dashboards are for investigating; alerts are for things that need a human now.

06

A backup strategy with daily snapshots and short retention

Stack Proxmox Backup Server · ZFS snapshots · offsite copy · restore tests

My backup plan follows the familiar 3-2-1 idea: multiple copies, on different media, with one off-site. VMs and containers are backed up nightly with deduplication, filesystems get frequent local snapshots for quick “oops” recovery, and a copy of the important data leaves the house.

  • Daily backups with a short, predictable retention window plus weekly and monthly keepers.
  • Automatic pruning and garbage collection so storage never fills up silently.
  • Scheduled verification jobs and a quarterly restore drill.

Lesson learned: retention is a policy decision, not a storage setting. Decide how far back you really need to go, then make the system enforce it. More in my note on retention.