02 // SELECTED WORK // CASE STUDY 03
Infrastructure
Lab.
The best way to understand a system is to operate one.
My homelab is a working environment for building, connecting, monitoring, maintaining, and recovering real services. It gives me a place to explore infrastructure decisions from the hypervisor to the application, including what happens when something goes wrong.
Public documentation is deliberately sanitized. The lab itself is not a public demonstration environment.
From knowing the concepts to owning the consequences.
Reading about virtualization, networking, and system administration helps. Maintaining services that I actually depend on adds another dimension: changes need a plan, outages need investigation, and state needs a way back.
What started as a place to experiment has grown into a collection of infrastructure services with distinct responsibilities, dependencies, access boundaries, monitoring, and recovery requirements.
The objective isn't to assemble the biggest rack or run every possible service. It's to understand how the parts interact and practice making better engineering decisions over time.
Not just machines. Connected services.
The environment is organized around infrastructure functions, from core virtualization to private application delivery and operational resilience.
Virtualization & compute
Proxmox VE hosts Linux containers and virtual machines for infrastructure, home automation, private applications, and development.
Proxmox VE · Linux · Docker ComposeNetworking & access
Pi-hole and split DNS support internal service names; Nginx centralizes HTTPS; Tailscale provides private remote access.
Pi-hole · Nginx · TLS · TailscaleObservability
Checkmk tracks service state and operational alerts, while Prometheus and Grafana handle metrics and visualization.
Checkmk · Prometheus · GrafanaRecovery & operations
Guest backups, temporary snapshots, database exports, restore validation, and repeatable maintenance procedures protect state.
Backups · PostgreSQL · Change controlsRemote administrative access takes a separate authenticated path through Tailscale. Not every workload is exposed through the reverse proxy.
Building it is fun. Keeping it healthy is the work.
I treat the lab as infrastructure with maintenance, monitoring, change records, and recovery obligations, not as a collection of machines that simply need to stay powered on.
Observability
Checkmk monitors hosts, services, network reachability, and alert delivery. Prometheus collects time-series metrics from exporters, and Grafana turns them into a visual view of the environment.
Access boundaries
DNS, reverse proxying, and encrypted remote access serve separate purposes. Backend-only and LAN-only services remain private, with deny-by-default remote access.
Backup & recovery
Scheduled guest backups, temporary rollback snapshots, logical database exports, and independent recovery copies address different failures. Restore tests are a separate validation step.
Repeatable changes
Maintenance procedures and change records cover prerequisites, execution, validation, rollback, and lessons. The aim is to make operational work safer and easier to repeat.
One change can touch every layer.
A working system doesn't guarantee a working service. Name resolution, TLS, routes, permissions, process health, and application state can fail independently.
The most valuable part of the lab is being able to trace those failures myself, test hypotheses, improve the design, and document why something changed.
Dependencies are the architecture
A service may be healthy while the DNS, proxy, authentication, or remote-access path required to reach it is broken. Troubleshooting has to follow the whole route.
Measure different kinds of health
Checkmk is responsible for infrastructure and service-state monitoring. Prometheus and Grafana provide historical metrics rather than duplicating the same alerts.
Privacy is a design constraint
Private applications, management interfaces, and backend metrics stay off the public internet. Remote administration and application ingress use separate paths.
A backup is not a restore
Snapshots, guest backups, database exports, and application backups solve different problems. Controlled restore testing verifies the recovery path.
Built to be understood, not just operated.
The public repository contains sanitized architecture, monitoring, networking, backup, automation, and maintenance documentation. Future improvements are treated as a roadmap, not completed installations.