Architecture
Designed trust zones, addressing standards, service placement, management paths, and production-versus-development boundaries.
01
Scope and ownership
This is not a collection of disconnected demos. It is a continuously operated environment with real users, dependencies, maintenance work, and failure modes.
The project began after a power outage exposed a circular dependency between virtualized routing and hypervisor management. Rather than restore the same flat design, I rebuilt the environment around segmentation, recoverability, observability, and controlled administration.
Implementation
Deployed OPNsense routing, Proxmox workloads, Docker Compose stacks, shared storage, DNS, DHCP, and remote access.
Operations
Monitor health, investigate failures, maintain services, validate storage, and perform bounded recovery actions through Ansible.
Documentation
Maintain architecture decisions, addressing standards, service inventories, troubleshooting notes, and recovery procedures.
02
Current architecture
The management path is deliberately narrower than the service network. Remote administration terminates at the control node, and corrective actions are explicit rather than unrestricted.
Decision 01
Docker Compose over Kubernetes
Compose provides repeatable deployment without introducing orchestration complexity that the environment does not need.
Decision 02
Production separated from experimentation
Household services run on the application host; development work runs on an isolated sandbox host.
Decision 03
Trust-based network segmentation
Management, trusted, server, IoT, camera, guest, DMZ, sandbox, test, and security workloads have distinct policy boundaries.
Decision 04
Bounded remote administration
Twingate reaches the Ansible control node; fleet actions pass through fixed playbook and action allowlists instead of broad root shells.
03
Operating model
The value of the project is not only that it was built. It is monitored, diagnosed, maintained, and recovered as an ongoing system.
Platform
Virtualization and storage
- Proxmox VM lifecycle and templates
- Dedicated control, production, development, and firewall roles
- ZFS pool health, scrub history, disk SMART checks
- NFS/SMB-backed application datasets
Network
Routing and core services
- OPNsense packet filtering and inter-VLAN policy
- Unbound DNS and Kea DHCP validation
- Managed switching and tagged VLAN trunks
- Isolated camera, IoT, guest, and test networks
Applications
Containerized services
- Multi-host Docker Compose deployment
- Frigate NVR, Pi-hole, Jellyfin, Traefik, Twingate, and AI workloads
- Production and sandbox workload separation
- Service-specific diagnostics and restart procedures
Observability
Monitoring and response
- Prometheus metrics and Grafana dashboards
- Alertmanager and ntfy alert routing
- Uptime Kuma and cAdvisor health visibility
- Low-noise scheduled checks and documented escalation
04
Skills demonstrated through implementation
Each capability is tied to something designed, deployed, or operated in the environment.
| Capability | Implementation evidence | Tools and platforms |
|---|---|---|
| Network architecture | Nine tagged VLANs organized around trust, service role, and blast-radius reduction | OPNsense, 802.1Q, managed switching |
| Firewall administration | Inter-VLAN policy, WAN routing, state-table validation, DNS and DHCP service checks | PF, Unbound, Kea DHCP |
| Systems administration | Virtual machine lifecycle, templates, host diagnostics, storage health, and capacity review | Proxmox VE, Linux, ZFS, SMART |
| Infrastructure automation | Repeatable diagnostics and bounded corrective actions executed from a dedicated control node | Ansible, OpenTofu, Git |
| Container operations | Production and development Compose stacks with service-level diagnostics and controlled restarts | Docker Compose, Traefik, Portainer |
| Observability | Metrics, dashboards, target health, alert routing, container telemetry, and uptime checks | Prometheus, Grafana, Alertmanager, cAdvisor |
| Security engineering | Scoped remote access, trust-zone isolation, action allowlists, and restricted management paths | Twingate, OPNsense, Ansible |
| Incident response | Runbook-driven diagnosis for firewall, NIC, container, GPU, storage, and camera failures | Logs, metrics, health checks, recovery playbooks |
05
Incident-driven improvement
A failure is most valuable when it changes the system instead of only being repaired.
Case: management-plane loss
Power recoverySituation
A virtualized router failed to restore normal connectivity after a power outage, making the hypervisor difficult to reach.
Analysis
The design coupled routing, management access, VM startup order, and NIC initialization into one failure path.
Changes
Preserved a dedicated management path, defined router startup priority, documented fallback access, and added restricted remote diagnostics.
Operational lesson
Management and recovery paths must remain usable when the production routing path is impaired.
06
Known risks and next improvements
A credible infrastructure case study should show what remains imperfect and how risk is being managed.
Single-disk application storage
The active ZFS pool is healthy and scrubbed, but it has no disk redundancy. Backup and disaster-recovery work remains a priority.
Network adapter failure mode
The hypervisor NIC has a known recurring hang pattern. Diagnostics, link-state checks, and recovery validation are documented.
Public versus operational records
Public diagrams are sanitized. Detailed addresses, identifiers, credentials, and recovery internals stay out of the portfolio.
Backup and recovery validation
The next maturity step is tested restore procedures, off-host copies, and evidence that critical services can be rebuilt from code and documentation.
Hands-on infrastructure ownership
Designing the system was the beginning.
Operating it is the experience.
The environment gives me practical experience planning changes, managing risk, troubleshooting failures, automating repeatable work, and maintaining services that other people rely on.