A homelab as a design practice

Homelabs, am I right?

I love finding deals on refurbished and frankensteining a chassis together from parts until it posts.

With a like , I can spin up a server to test an idea. If I break it, I can blow it away and start over.

I self-host audiobooks so I can listen on my commute to titles I own, , on infrastructure I control. I run Plex so I can tell my kids “go check the server” when they want a movie, and they have some idea that their dad made that possible. My father is a long-distance truck driver, and he calls me every time the server goes down. The books give us something to talk about on his long hauls.

I have a and custom and because I like having control of my network. I keep off my services . I block ads and trackers at the DNS level. I have not seen an ad on my phone in years.

This website runs on the lab, too.

The DNS story

I was running as my recursive resolver. One morning, DNS across the entire home network failed. I suspect a configuration change I had made the night before looked syntactically valid but broke upstream forwarding; cached entries kept working until their expired, and then resolution stopped.

This happened to land on the day of an interview with a company.

I spent a few hours diagnosing the failure, tracing the resolution path, restarting the service, validating upstream connectivity, and getting the household back online. I made the interview on time. The interviewer asked how my day was going. I said “DNS issues. It is always DNS issues.” The interviewer laughed, and the rest of the hour turned into a walkthrough of the incident: what broke, how I triaged it, what I fixed, and what I would do differently. Not a single prepared question.

I got that job. It was a platform engineering role, and I spent a couple of years getting paid to troubleshoot computers, scripts, automation frameworks, cloud tenants, and at a depth that often led to conversations with the team or an because I had found a legitimate bug. Kernel-level troubleshooting, sometimes. I loved it.

What the lab does

The lab has a few jobs:

Run household services that fade into the background.
Host experiments in a place where experiments stay contained.
Publish selected services through a controlled edge.
Keep a management path alive when the routed network changes.
Produce diagrams, tables, and that another engineer could follow.

Trust zones and management access

I start the network diagram with and the management path. That gives me a basis for choosing and writing rules.

Trust boundaries and data flows

flowchart TD
repair([Repair actor · management plane])

subgraph internet ["Internet (untrusted)"]
  recon[Reconnaissance<br/>DNS enumeration, Shodan]
  dns[Public DNS<br/>CT logs, HTTPS]
  recon -.->|enumerates| dns
end

subgraph edge ["Public Edge (semi-trusted)"]
  proxy{Reverse proxy<br/>route decision}
  deny[Refuse + log<br/>unknown host or path]
  proxy -->|refused| deny
end

subgraph services ["Internal Services (trusted)"]
  app[Published service<br/>app-layer auth]
  infra[Hypervisor · DNS<br/>storage · backups]
  logs[(Centralized logs)]
  app -->|log event| logs
end

subgraph household ["Household + IoT (constrained)"]
  devices[Household and<br/>IoT devices]
end

dns -->|HTTPS| proxy
proxy -->|approved| app
devices -->|media pinhole| app
repair -.->|out-of-band| infra
repair -.->|policy| proxy
repair -.->|reviews| logs

style internet fill:#e8efe8,stroke:#1f3d2c,stroke-width:2px,stroke-dasharray:6 4,color:#1f1d1a
style edge fill:#faf6ef,stroke:#1f3d2c,stroke-width:2px,stroke-dasharray:6 4,color:#1f1d1a
style services fill:#f3ede0,stroke:#948069,stroke-width:2px,stroke-dasharray:6 4,color:#1f1d1a
style household fill:#fff8ed,stroke:#b8783c,stroke-width:2px,stroke-dasharray:6 4,color:#1f1d1a

classDef process fill:#e8efe8,stroke:#1f3d2c,color:#1f1d1a
classDef decision fill:#faf6ef,stroke:#1f3d2c,color:#1f1d1a
classDef reject fill:#fff8ed,stroke:#b8783c,color:#1f1d1a
classDef record fill:#f3ede0,stroke:#948069,color:#1f1d1a
classDef threat fill:#e8efe8,stroke:#b8783c,color:#1f1d1a,stroke-dasharray:4 3
classDef mgmt fill:#fff8ed,stroke:#b8783c,color:#1f1d1a,stroke-dasharray:4 3

class dns,app,devices process
class proxy decision
class deny reject
class logs record
class infra record
class recon threat
class repair mgmt

Dashed borders are trust boundaries. Each zone carries a different trust level. The repair actor operates out-of-band, outside all routed zones.

The dashed borders show trust boundaries. Traffic crossing them needs an explicit rule. and records can reveal public service names, which is why reconnaissance appears outside the edge. The repair actor is outside the routed zones because recovery access must survive a routing failure.

Routing through Proxmox

The lab did not start here. The first routing design was a dedicated box with a dual-port 10 Gbps NIC, one side for and the other for . It worked well, and I liked how it separated routing from the rest of the infrastructure. Then one of the two ports failed.

It did not fail all at once. Over the course of a few months, the connection would intermittently drop in an almost imperceptible way. I chased the problem through cables, switch ports, and driver settings before discovering the NIC itself was dying. Replacing the fancy dual-port, autonegotiating NIC would not have been cheap, and I had decided that was the end of the experiment. I regretfully retired the pfSense box and switched back to my regular old Google Nest WiFi router for a while. I noodled with the idea of building a new router, or buying a “real” one.

I moved routing into the hypervisor instead of buying another card. runs as a on , and the physical network reduces to a single over another 10 Gbps link on the main server. All ride that trunk, and the firewall VM handles inter-VLAN routing. One fewer box in the closet.

Routing now depends on the hypervisor. If Proxmox is down, the network is down. The recovery plan needs a that does not depend on the routing VM.

Documenting firewall rules

A (PPSM) matrix records the reason for each allowed network path.

This example uses roles and service categories:

Source role	Destination role	Protocol	Port	Purpose	Review trigger
Internet	Public edge	TCP	80, 443	Publish selected web services and renew certificates	Any new public DNS name
Public edge	Service app	TCP	App port	Send approved requests to the service	New app, new service path, or changed authentication model
Admin workstation	Management plane	TCP	, admin UI	Maintain hypervisor, firewall, and switch	New admin user or new management host
Service zone	DNS resolver	UDP/TCP	53	Resolve internal and external names	Resolver change or new zone
Service zone	Internet	TCP	443	Package updates, APIs, and outbound integrations	New vendor dependency
Household devices	Media service	TCP	Media app port	Local playback and casting support	New media platform or new device class
IoT devices	Management controller	TCP	Controller ports	Device adoption and status checks	New controller or wireless redesign

In an operational matrix, replace those roles with the actual interfaces and addresses, and include the firewall rule IDs.

The review trigger says when to revisit a rule. A new service, for example, may change which paths it needs.

A blank row for your own lab or facility:

Source role	Destination role	Protocol	Port	Purpose	Review trigger
(your zone)	(target zone)	TCP/UDP	(port)	(why this traffic exists)	(what change would make you revisit this rule)

Use the blank row to document a firewall rule. Flag any rule whose purpose you cannot explain.

For HTTPS services, web applications can share the proxy’s public listener on port 443. Adding a new then means adding a proxy route without opening a separate firewall port for each web app.

The proxy and the applications behind it still need updates. A Minecraft server or a file share needs an access method suited to its protocol. Management interfaces should stay on private access paths.

Publishing web services

The proxy terminates using Let’s Encrypt certificates, then routes HTTP requests according to its configured hostnames and paths. The certificate’s field tells clients which hostnames the certificate covers. The routing configuration chooses the destination service.

Unlike a basic rule, the HTTP proxy can route requests by hostname and path. Its access logs record requests at the edge.

Public request through the edge

flowchart LR
public[Public DNS name] --> proxy{Reverse proxy<br/>route decision}
proxy -->|approved| app[Service app<br/>with auth]
proxy -->|unknown host<br/>or path| refuse[Refuse]
app --> logs[Edge logs<br/>source, route, status]
refuse --> logs
logs --> review[PPSM review<br/>DNS, auth, logging]

classDef path fill:#e8efe8,stroke:#1f3d2c,color:#1f1d1a
classDef decision fill:#faf6ef,stroke:#1f3d2c,color:#1f1d1a
classDef reject fill:#fff8ed,stroke:#b8783c,color:#1f1d1a
classDef record fill:#f3ede0,stroke:#948069,color:#1f1d1a
class public,app path
class proxy decision
class refuse reject
class logs,review record

The edge proxy routes requests to configured services and records them in its access log. Unknown hosts or paths are refused.

During a routine audit of my own lab, I found that the reverse proxy was routing public traffic to management interfaces, including the login page. The certificates exposed those hostnames in logs, and could reveal other public records. I had set up the proxy for convenience, and convenience is what the internet got too.

That audit changed the design:

Management interfaces moved to internal-only access paths.
Public services carry their own authentication and logging.
The proxy routes a narrow set of named service paths.
Edge logs show what crossed the boundary.
The PPSM gained a review trigger for every new public DNS name.

Storage and backups

I use the 3-2-1 backup rule for irreplaceable data: three copies, two media types, one offsite. The media collection has a different recovery plan.

The media array in this lab is a striped multi-disk pool with no redundancy or separate backup. A drive failure takes the pool with it. I chose that layout because hard drives are expensive and the only thing on that array is audiobooks and movies for my family. Paw Patrol is important to my six-year-old daughter, but it is not critical data. Every title can be re-ripped or re-downloaded.

I chose the knowing I would have to rebuild the media collection after a drive failure.

Configurations, service data, databases, keys, diagrams, and live on a separate pool with redundancy, automated , and offsite backups. The decision record covers both pools:

Media pool: striped, no redundancy, re-downloadable content. Accepted risk.
System pool: redundant, snapshotted, backed up. Recovery path documented.
Monitor disk health and capacity on both.
Revisit the design when the hardware budget or workload changes.

A should include the recovery plan for each storage option.

What I write down

I keep the diagrams and PPSM alongside the recovery procedures. When I change the design, I write down the reason so I can revisit it later.

The next piece will cover how I build and run this site alongside the household services.

← All writing