--- title: "My cloud architect habits at home" description: "I hold my homelab to the same production standards I practice as a cloud architect, on a strict budget of money and time." url: "https://michael.zazon.us/notes/a-cloud-architects-habits-applied-at-home" published: "2026-10-10T12:00:00-04:00" kind: "take" subject: "homelab" tags: ["cloud"] --- So I run my homelab like I would a production customer environment, based on my years of experience as a cloud architect, software developer, and a sysadmin professionally. The habits I forged in these roles over years and years have stuck, even though I'm working with a much smaller budget, of course (both in terms of money and time). [Always be building](https://michael.zazon.us/notes/always-be-curious). That's my motto. I'm a lifelong learner, and the way I learn is by doing: reading, writing, experimenting, and trying new techniques in software development, agentic development, DevOps, system administration and architecture. Writing about it is part of the process, because researching a post pushes me deeper and makes the lessons stick. And when I tinker at home, I hold myself to the same standards I use in my day to day line of work. That consistency is the point.. the habits only become second nature if I practice them everywhere. I'm not always able to replicate the best practices of enterprises in terms of scale, but I strive to do a lot with a little, and I have a blast doing it. ## DevOps at home The code side is where I spend most of my "work" time. All of my repositories use [Conventional Commits](https://www.conventionalcommits.org/), and [semantic-release](https://semantic-release.gitbook.io/) looks at my commit messages to determine the next version number and create the release. I don't pick version numbers manually. Every repo has the same four-job CI pipeline: lint, check PR title, run tests, and a release job. I use pre-commit, but with a single global hook dispatcher instead of copying it into every repo. The pre-commit runs [gitleaks](https://github.com/gitleaks/gitleaks), trufflehog, and other checks, but again, nothing is copied into my repos. Hosting is handled by a self-hosted [Forgejo](https://forgejo.org/) instance, which is deployed with Ansible and then hardened. Forgejo is the only remote for all my repos except `home-infra`, which also pushes to GitHub as a second remote. Every repo has a rule that it must build from a clean clone, because one repo once failed to do so. My infrastructure and data follow the same pattern. All host and service configuration is in Ansible. Applications deploy via Dockhand webhooks, so a git commit updates the running service. Secrets come from 1Password via its CLI and 1Password Connect.. never in environment files. For data, ZFS snapshots are managed by sanoid, and an offsite copy lands on Backblaze B2. The key insight: that copy is append-only.. even a compromised machine can't delete backups. But I don't just trust the green checkmark. A weekly job restores from the offsite copy to prove the data actually comes back. **Operations**: The lab looks the most like a small production system. I use Loki for logs, VictoriaMetrics for metrics, and Tempo for traces. All alerts are routed through a single relay, apprise, so that I can change my notification settings in just one place. Healthchecks monitor whether a service is actually doing its job, not just whether the process is running. Deep health checks wherever possible. The UPS is honestly tested by unplugging it on purpose. Big decisions are documented with architecture decision records.. it's a daily habit at work, and I wrote about it in [Architecture decision records deserve a release cycle](https://michael.zazon.us/notes/architecture-decision-records-deserve-a-release-cycle). ## Scaled down on purpose I run the homelab on a strict monetary and time budget (having two kids, they get priority and my time!) but that being said I maintain best practices in as much as I can do. With the money limit, I can't have a cluster of servers. I have one main server, so I need to implement redundancy only where it counts. ZFS snapshots replace having a staging copy of each service, so I can roll back instead of testing on a duplicate. I use consumer hardware wherever it's adequate. With the time limit, I can't have a change board (it would be me, anyway). Being the only one on-call means I only get alerts for things that matter; I tune out the noise. Automation and agents take care of repetitive work (a write up on sentinel agent coming soon), so I spend my hours with my kids instead of toiling. The dividing line for me is cost. There are practices that are cheap to keep up (conventional commits, pre-commit hooks, infrastructure as code, append-only backups) that I don't negotiate on at home. But practices that cost money or evenings (a cluster, a formal change process) I scale down intentionally, and I know exactly which ones I'm giving up. [Diagram: Homelab practices kept in full and practices scaled down for budget and time](https://michael.zazon.us/notes/a-cloud-architects-habits-applied-at-home) ## Agents and the guardrails These habits matter more now that AI agents are committing to my repos all day. A CLAUDE.md (or AGENTS.md) in every repo defines conventions like house rules.. the agent reads them before touching anything. Global pre-commit hooks catch secrets before the agent pushes. Conventional commits mean its changes are easy to review and semantic-release can cut a versioned release without rewriting history. ADRs give agents context about past decisions so they don't accidentally reverse choices they don't understand. And irreversible actions still need my click of approval. The guardrails are what make the budget work. They let agents do the toil without going rogue, which is how I can maintain a lab this size on the hours I have available. Without the hooks and commit conventions, I'd have to review every line of every agent change individually, and that review time would eat into the same evenings the budget protects. It's a fun, lighthearted hobby, and I get to build really cool stuff ([home automation via Home Assistant](https://michael.zazon.us/notes/nine-mitsubishi-mini-splits-in-home-assistant-for-15-per-head), and [Aviary](https://aviary.zazon.us), for example) but I take it seriously.