Home infrastructure tends to grow one useful service at a time. Without an operating model, the result works until a change fails—or until six months have passed and I no longer remember why it works.
Homelabbuilding
Home-Ops: treating my house like a tiny production environment
A growing operational layer for the homelab: versioned configuration, recoverable change, monitoring and documentation that survives my memory.
Treat the environment with a proportionate version of production discipline. Put reviewed configuration and documentation in Git, take backups before automation, separate operations tooling from the systems it manages, and make important state observable.
The foundations are running and the operating model is still evolving. More of the environment can now be understood and changed through a documented workflow, but reproducibility and recovery testing remain active work.
Abstract architecture / sensitive detail removed
01 Infrastructure and services
02 Read-only observation
03 Operations VM
04 Versioned change
05 Backup and verification
Why make a house operationally serious?
Not because a home needs enterprise bureaucracy. It does not. But once heating, lighting, storage, backups, cameras and useful local services depend on the same infrastructure, undocumented changes become surprisingly expensive.
Home-Ops is an experiment in keeping the helpful parts of production engineering—source control, clear boundaries, monitoring and recoverability—without turning the house into a change-advisory meeting.
The working model
Configuration and public-safe documentation live in Git. A separate Debian operations VM runs approved tooling and scheduled checks. Proxmox provides the compute layer; Home Assistant remains the centre of physical automation; NAS storage supports local data and recovery workflows.
The public diagram deliberately shows responsibilities rather than real hosts, addresses or management paths.
What is deliberately unfinished
Reproducibility is a direction, not a completed claim. Some services are well documented; others still contain manual history. Backup jobs exist, but confidence comes from repeated restore evidence rather than a green job status. The next work is to keep closing those gaps.
Publication boundary
This write-up omits credentials, internal names and addresses, device identifiers, external access methods and a complete security topology. The interesting part is the operating pattern, not a map of the house.
Notes to future me
What this project is teaching me.
- A backup should exist before an automation gains write access.
- Documentation is most useful when it changes with the system.
- Observability has to precede useful autonomy.
This page explains design intent and lessons without publishing credentials, private addressing, access paths, device identifiers or a complete security topology.