Chat-driven operations path
The weakest boundary is still AI/agent → MCP → hserver → other nodes. The work is around reliable access, authorization, auditability, safe execution and recovery when one machine disappears.
Home Server / living infrastructure notebook
An old Mac mini became my private infrastructure platform.
What started as Ubuntu, Docker and SSH gradually became the control plane behind observability, networking, storage continuity, embedded-device work, sensing, environmental data and telephony R&D.
This page is intentionally not a finished case study. It is the canonical public place for the architecture, current state, active technical discussions and the decisions that keep changing the system.
Why this page exists
Every useful layer was added because the previous layer eventually became insufficient.
I did not start by designing a “homelab architecture.” Wi-Fi failed, so I needed recovery. Remote access mattered, so I needed a private network. Too many services appeared, so I needed observability. Too many dashboards appeared, so I needed a control surface. Devices started producing data, so the server became a data backend. Firmware and telephony work needed infrastructure, so they joined the same platform.
The page therefore doubles as a living engineering notebook: when a homeserver discussion changes the architecture, creates a new operational rule, or closes an open problem, the durable result belongs here.
Evolution
Problems became architecture.
01Ubuntu + Docker
An always-on Mac mini for containers, files, SSH access and experiments.
02Network recovery
Broadcom Wi-Fi, routing and availability problems forced watchdog logic, NetworkManager recovery and a more explicit failure model.
03Private + public access
Tailscale made the host a persistent private node. Cloudflare and Caddy separated controlled web ingress from private management paths.
04Multi-machine compute
Desktop, laptop and hserver became nodes with different capabilities and availability. Workload placement and Nomad experiments followed.
05Observability
Prometheus and Grafana grew from host metrics into service state, network relationships, failure validation and operational evidence.
06Control plane
Homarr, ingress, authentication, service-group controls and recovery views turned many independent tools into one operational surface.
Architecture now
Stable center, replaceable edges.
AccessInternet + private network
Cloudflare for selected public services; Tailscale for private management and node-to-node reachability.
Corehserver
Ubuntu, Docker, ingress, service coordination, operational dashboards, collectors and continuity services.
ComputeDesktop + laptop
More capable machines can take heavier workloads while the home server remains the persistent coordination point.
ObserveMetrics + flows
Prometheus, Grafana, service state, logs and experiments around network-path visibility.
DevicesESP32 + Android collectors
Embedded firmware, OTA experiments, Wi-Fi CSI, GNSS/GSM and other physical-world telemetry.
LabsVoice + environment + sensing
SIP/RTP infrastructure, environmental observatories, presence experiments and data services share the same underlying platform patterns.
Current discussion threads
What is still moving.
Master operations surface
Homarr and Grafana are being consolidated so infrastructure, environmental data, presence/RF, telephony, storage and recovery remain discoverable from one place.
Network observability
Moving beyond container lists toward service groups, traffic relationships, timeline views, path tracing and better visibility into the whole LAN.
Service lifecycle control
Heavy stacks should not run forever. Service-group toggles, maintenance windows and resource-aware operation are replacing permanent-on assumptions.
Sensor + CSI platform
Wi-Fi CSI, Android radio/GNSS data and calibration workflows are turning the server into a backend for physical-world sensing experiments.
Device + telephony infrastructure
OTA fleet ideas, ESP32 development, SIP/RTP testing and PBX work continue to use the same server as a shared engineering lab.
What runs through it
One platform, several engineering domains.
Infrastructure
Linux hosts, Docker services, ingress, identity, service state and recovery.
Observability
System metrics, dashboards, alert validation, service health and network behavior.
Device infrastructure
Firmware lifecycle, provisioning, release states and embedded-device experiments.
Sensing
Wi-Fi CSI, Android GNSS/GSM collection, calibration and time-series analysis.
Environment
Weather, river, flood, satellite and other public-data integrations.
Telephony
SIP signaling, RTP media, PBX integration, call-flow debugging and embedded voice.
The same pattern keeps repeating: source → collector → storage → query → visualization → alert or action.
Change log
Recent evolution.
Consolidated operations around a master dashboard, Grafana hub, Caddy ingress and authentication instead of treating every dashboard as an isolated destination.
Expanded the server into an environmental and sensing backend: river/weather observatories, satellite integrations, Wi-Fi CSI and Android radio/GNSS collectors.
Started treating expensive stacks as service groups with explicit on/off and maintenance behavior after resource and log-pressure problems exposed the cost of leaving everything running.
Made OTA/device lifecycle and telephony labs part of the same infrastructure rather than separate one-off development environments.
Moved from local-only SSH toward Tailscale, watchdog recovery and remote operational access, changing the Mac mini from a nearby computer into a persistent infrastructure node.
Next engineering questions
- 01How should machine selection and failover work when desktop, laptop or hserver disappears?
- 02How much authority should a conversational operations layer have, and how should every action be auditable?
- 03Which data belongs in long-term storage versus short-lived experimental telemetry?
- 04How do I keep the control plane understandable as more projects attach to it?