The operating requirement
A homelab can be a perpetual experiment. Family infrastructure cannot. Media, photos, home automation, documents, credentials, and remote access have users who reasonably expect them to work without caring which container, host, or identity protocol makes that happen.
The architecture therefore favors a boring control path, explicit ownership, portable data, and recoverable configuration. New tools are useful only when they reduce a real operating burden or create a capability worth maintaining.
Current architecture
- Stable consolidation host Unraid provides storage and the primary container runtime. A separate firewall and an auxiliary Ubuntu host remain part of the environment, but they are monitored as distinct systems rather than allowed to become invisible dependencies.
- Containerized home automation Home Assistant, Zigbee, Z-Wave, and MQTT run as separable services. Radio state, controller backups, security keys, and application configuration are treated as distinct recovery concerns.
- Private access boundary pfSense provides the network boundary and HAProxy provides reverse proxying. Services are not deliberately exposed to the public internet; Tailscale supplies authenticated remote access.
- Identity and credentials Bitwarden holds human credentials. Centralized application identity is deliberately deferred: the added operating and recovery burden currently outweighs the benefit for this private-access environment.
- Observable services Grafana dashboards cover host and container utilization, network throughput, storage, temperatures, and household power flows. Uptime Kuma provides service-level availability checks, while the wider metrics and logging stack supports diagnosis across hosts.
- Version-controlled configuration A nightly, allowlisted sync mirrors live configuration into private Gitea for readable change history and disaster recovery. Secret-bearing values are encrypted with SOPS and age, and a gitleaks scan blocks commits when it detects plaintext secrets. Databases, media, photos, logs, caches, and runtime state remain outside this configuration mirror.
- Layered recovery Kopia sends multiversion backups to Backblaze B2 for long-term off-site retention and major disaster recovery. Backrest keeps a smaller, short-retention local copy for a faster nearby recovery path. Small sets of files have been restored manually from both systems.
What it currently supports
The environment runs dozens of containerized services across several practical domains: media and photo management, home automation, network services, local development, file synchronization, local AI, monitoring, backup, and solar-and-energy integration. The point is not the size of the application list. It is that these services share infrastructure while retaining observable responsibilities and recoverable state boundaries.
Design principles
- Portable roots Data, recovery material, and configuration should outlive a particular application or provider.
- Controlled exposure Remote access does not require turning every internal service into a public web application.
- Replaceable services Containers and hosts should be reconstructable wherever practical; durable state receives different treatment.
- Operational honesty A dashboard is not a backup, a scheduled job is not a verified restore, and “self-hosted” does not automatically mean resilient.
Configuration is not a backup
The configuration repository is intentionally a one-way mirror from the live system. It preserves reviewable service definitions, selected Home Assistant state, device and automation configuration, container templates, and the scripts that perform the sync. It does not try to turn databases or user data into Git content.
That boundary keeps three recovery tools distinct: Git explains how services were configured, the local backup provides a short and convenient recovery path, and the off-site archive protects durable data across more serious failures. Encryption and secret scanning make useful diffs possible without treating a private repository as permission to store credentials in plaintext.
Lessons from consolidation
The most important architectural change was not adopting a new platform. It was recognizing that a quiet, headless mini PC could fail in ways that were easy to miss. It remains useful as auxiliary compute, but should not be the sole scheduler or control point for backups and family-critical services.
The Home Assistant migration reinforced a related lesson: a service is not fully described by its container. Z-Wave network identity, controller nonvolatile memory, security keys, device mappings, broker state, and application configuration each have different recovery requirements. A successful architecture makes those boundaries explicit before the failure.
What is not finished
This is a working architecture, not a claim of completed operational maturity. File-level restores from both backup paths have been exercised, but broader restore drills and reconstruction timing still need to be documented. Configuration coverage can expand where it provides useful recovery value, and secret handling still needs periodic review as new services are added. Existing dashboards make system state visible, and ntfy carries remote alerts over Tailscale without exposing an alerting service to the public internet. Remaining maturity work includes broader recovery exercises, reconstruction timing, and testing alert coverage end to end.