Live from my home rack. Zero inbound ports for this site.

Brock Harries

Eight years running a multi-million dollar restaurant and every piece of technology it depends on. Now taking that into technology as a career. Salt Lake City, usually on the ground.

This page is the demoYou are reading it through the exact architecture the write-ups describe.
No open portsThe server dials out to the edge and holds the connection open. There is no port forward on my connection. Requests reach this site only through that tunnel.
Certificates handledTLS issued and renewed automatically at the edge, so there is no renewal for me to forget.

The write-ups

I have run a restaurant for eight years. Not just the P&L and the health inspections, but the website, the online ordering, the DNS, the email, the backups. When something technical broke, there was no IT department behind me. I was the IT department.

The homelab is where I take that further than the business ever needed: a four-node cluster in a full rack, a network segmented into VLANs the way an enterprise would do it, single sign-on with hardware keys, monitoring that pages my phone, backups I have actually restored from, and private services reachable from anywhere without a single open inbound port.

I build most of the automation around it with AI coding tools, and I check their work against the live system before I trust it. The write-ups above walk the designs end to end, trade-offs and failures included.

I could tell you it works. It felt better to show you: the page you are reading right now is served from that rack, through that exact pattern.

How I work

I want to know why before I touch anything. I read the docs first, then I check the actual system, because the two disagree more often than anyone admits, and when they do, the system wins.

I don't trust "it said OK." I go look at the thing that was supposed to change. I once had an alert system look healthy for weeks while every page it sent went nowhere.

When I fix something, I write down what happened and what I'd check next time, so the next person isn't starting from zero. Usually the next person is me in six months.

And I test the things nobody tests, like whether the alert really reaches my phone, or whether the backup login still works when the main one is down. Those only fail on the day you need them.

Brock gathering his parachute lines after landing, pink canopy in the grass
Brock in freefall, grinning at the camera with the horizon tilted behind him

Off the clock: more than 500 skydives, twenty-odd BASE jumps, and an instructor rating that lets me teach first-time students in freefall. Turns out I like risk management as a hobby too. Different altitude, same discipline: know your gear, check it twice, respect the things that can go wrong, and stay calm enough to talk someone else through it.

A 42U server rack with network switches, a patch panel, a Raspberry Pi shelf, several servers, a 15-bay storage server and two UPS units

The rack. Everything on this page runs here: the network at the top, a shelf of Raspberry Pis, the virtualization nodes including a Dell PowerEdge R730xd, a 15-bay storage server, and two UPS units at the bottom so a power blip is a log line and not an outage.

It sits next to the bench where I take things apart. Most of what I know about infrastructure I learned by building this, breaking it, and fixing it.