$ cat ~/guide/README

A working manual for a useful homelab.

Start with one outcome. Build the smallest system that serves it. Keep the records that prove it can recover. Add automation only after the operations make sense to a person.

open the architecture plates build a starting sequence

$ ls ~/guide/plates

Five drawings carry the whole design.

Each sheet names a decision, a boundary, or a record you can verify.

01The question sheet

A homelab follows from three answers. Everything downstream is a consequence of them.

inspect plate →02One useful host

One box, one service, one owner. One backup on another failure domain. One restore that has worked. One alert path that reaches you.

inspect plate →03Trust boundaries

Trust boundaries are physical, not conceptual. A boundary is a wall with named doors. Deny cross-zone by default. Allow only documented flows.

inspect plate →04Recovery chain

A backup is a claim. A restore is evidence. Each stage crosses a failure boundary, keeps its own credentials, and leaves a dated record.

inspect plate →05The loop, field note

The agent came last. It uses the same typed operations a person already trusts. Policy decides. Live verification closes the record.

inspect plate →

$ tree ~/guide/chapters

Every chapter ends with evidence.

Read in order for a first build. Return to one chapter when the lab gives you a reason.

01IntentPlan before you buyWhat outcome justifies this lab?Leave withA first workload, constraints, and a recovery target.02FoundationChoose hardware by roleWhat role can existing hardware not fill?Leave withA role-based hardware plan and an idle-power budget.03FoundationChoose the platformLinux with Compose, Proxmox, or K3s?Leave withA short platform decision record.04BoundariesDesign networking and accessWho may talk to what?Leave withSemantic zones and a map of allowed flows.05TrustProtect storage and prove recoveryHow does valuable data survive each failure domain?Leave withA recovery chain and a dated restore-test record.06TrustBuild security into the designWhat needs protection, and how is access recovered?Leave withA threat model, identity plan, and break-glass path.07ValueChoose services that create valueWhat improves life outside the dashboard?Leave withOne service contract covering users, data, exposure, backup, and ownership.08OperationsOperate what you installHow will failure be detected and handled?Leave withMinimum monitoring, maintenance, alerting, and power plans.09AutomationBuild a control planeWhich repeated work deserves automation?Leave withInventory, desired state, preview, execution, and evidence.10AutomationAdd local AI and bounded automationWhich operations should an agent assist?Leave withA tool risk policy and one safe agent workflow.11StewardshipGrow and share responsiblyHas expansion earned its cost?Leave withAn expansion gate and a public-sharing redaction check.

$ cat ~/guide/field-notes/agentic-operations

The agent came last.

I did not start by giving a model shell access. I made the lab legible first: inventory, structured commands, dry runs, health gates, and recovery paths. Routine work got faster. Failures got easier to explain. The agent could use the same guarded operations I already trusted.

read the agentic operations guide →

$ git status --short

The tools will change. The questions hold up.

The registry tracks project health and review dates. The notes explain the evidence behind each default.

browse recommendations →read the research notes →