ea63347cd6
- replace CRA scaffold with Next.js static export config - add app router pages: home, homelab, archive - add components: Nav, Footer, Hero, Skills, ProjectCard, ThemeScript - add ThemeContext for dark mode with FOUC prevention - add data layer: projects.ts, services.ts - update .gitignore for Next.js (ignore .next/, out/, next-env.d.ts) - add docs: handoff plan, homelab decisions, style reference
3.1 KiB
DECISIONS
decisions
Short notes on why things are configured the way they are.\nYou'll forget this in 6 months. Future-you will thank present-you.\nFormat: title, date, context, decision, alternatives considered.
AT&T Gateway kept in-line (not bypassed)
Date: [date]
Context: AT&T Fiber requires 802.1X certificate authentication locked to their gateway hardware. No way to replace it with a standard modem.
Decision: Keep BGW320 in-line with IP Passthrough mode (DHCPS-fixed to pfSense WAN MAC). pfSense gets the public IP directly. Gateway WiFi disabled.
Alternatives considered:
- EAP proxy bypass — more complex, breaks on AT&T firmware updates, only saves 1-2ms latency. Not worth it.
- True bridge mode — AT&T gateways don't support it.
Caddy as reverse proxy with Cloudflare DNS challenge
Date: [date]
Context: Needed valid SSL certs for all homelab services without exposing port 80/443 to the internet for HTTP challenge validation.
Decision: Caddy with caddy-dns/cloudflare plugin. DNS-01 challenge via Cloudflare API. All subdomains on lerkolabs.com point to Caddy (10.2.0.20) in Pi-hole. Caddy terminates SSL and proxies to backends.
Alternatives considered:
- Self-signed certs — browser warnings, annoying on mobile/VPN clients.
- Nginx Proxy Manager — more UI overhead, same result.
- Traefik — more complex config for the same outcome here.
WireGuard over OpenVPN
Date: [date]
Context: Needed remote access to homelab services.
Decision: WireGuard on pfSense, UDP 51820, VPN subnet 10.200.0.0/24. Clients get same access as LAN for Homelab and MGMT, blocked from Guest/IoT/WFH.
Alternatives considered:
- OpenVPN — slower, more complex config, worse battery on mobile. No advantage here.
- Tailscale — adds external dependency and relay for what can be direct.
Pi-hole in Homelab VLAN, not MGMT
Date: [date]
Context: Pi-hole serves DNS to all VLANs. Needed to decide where to host it.
Decision: VLAN 1020 (Homelab) at 10.2.0.11. Firewall rules allow port 53 inbound from all VLANs. MGMT VLAN uses pfSense as primary DNS (more reliable for network equipment).
Alternatives considered:
- MGMT VLAN — cleaner separation, but creates firewall complexity allowing all VLANs to reach MGMT.
- DMZ — no reason to put a DNS server public-facing.
WFH VLAN uses pfSense DNS only (not Pi-hole)
Date: [date]
Context: Work laptop on WFH VLAN should be maximally isolated from personal infrastructure.
Decision: WFH DHCP hands out pfSense (10.5.0.1) as the only DNS server. Work device can't reach Pi-hole at 10.2.0.11 and doesn't need to.
N100 for pfSense
Date: [date]
Context: Needed hardware that handles 1Gbps routing + WireGuard VPN without bottlenecking.
Decision: Intel N100 mini PC. 4-core 3.4GHz, ~6W idle. Handles 2-3Gbps routing, 600-900Mbps WireGuard. Adequate for 1Gbps AT&T fiber with room to grow.
Alternatives considered:
- Raspberry Pi — insufficient for 1Gbps + VPN.
- Full rack server — overkill power draw for this role.