Core takeaway: Homelab AI helps a hiring conversation when it reads like operable systems work. Git-defined desired state, validation probes that emit evidence bundles, and upgrade tracks that include previous_known_good with rollback runbooks are the story. A demo stack with no recovery path is not evidence I would defend in an interview.
Homelab AI is open source (FOSS) Ansible configuration-as-code for a personal self-hosted inference lab. I am the only operator. The commissioned profile is a Dell Precision 5820 with dual Intel Arc GPUs.
A second node profile remains uncommissioned. That gap is deliberate scar tissue: desired-state documentation is cheap; commissioning, evidence, and rollback discipline are the expensive parts.
What operable means when you are the whole team
Enterprise operations trained me to treat production change as a risk decision with a recovery story. A solo homelab removes the incident bridge and the change advisory board. It keeps the same sharp question: if this upgrade fails at 23:00, what state do you return to, and what proof says you are there?
Homelab AI answers with patterns I would expect before trusting any vendor pitch on self-hosted inference:
- Git as desired state, expressed as Ansible roles and playbooks for bootstrap, convergence, patching, and upgrades
- two independent containerized llama.cpp SYCL workers, one per GPU, behind an authenticated gateway
- HashiCorp Vault as the secret authority, not ad hoc env files on the host
- scheduled reconciliation so drift is visible before it becomes folklore
- validation probes that produce schema-validated evidence bundles
- upgrade tracks for current, candidate, and previous_known_good with documented rollback paths
None of that replaces a multi-team production service. It does show how I pressure-test my own changes when nobody else will catch a bad cutover.
Validation bundles before narrative
Validation is not a green checkbox on a dashboard. Probes produce evidence bundles that can be inspected later, including during an upgrade window when memory is already compressed.
Judgment call: I treat schema-validated bundles as the minimum bar for claiming an inference lab is operable. Without them, "it works on my machine" is the only artifact, and that is not hiring evidence for operations leadership.
The authenticated gateway and Vault-managed secrets sit in the same frame. Exposure control and secret authority are part of recovery, not security theatre bolted on after the GPUs are busy.
Rollback as a first-class upgrade track
Upgrades that only document "forward" are how improvisational rollbacks appear under pressure. Homelab AI documents current, candidate, and previous_known_good as explicit tracks, with rollback runbooks written before upgrade appetite makes skipping them feel rational.
That mirrors how I think about production change evidence at work: implementation proof and a known-good fallback are what make coordination defensible when something misbehaves. Here the stake is personal downtime and credibility, not post-trade continuity, but the habit is the same.
For hiring managers: ask whether a candidate can name previous_known_good without searching Slack. This project is one verifiable place to inspect that habit in repository docs and automation, not in invented incident metrics.
Claim boundary
Use this project in a role conversation when you want to see desired state, validation, and recovery discipline applied to a small inference lab. Do not use it to infer revenue, client outcomes, or a second production node you cannot verify in the repository.
Primary objective remains senior technology operations or service delivery leadership in Canada. The public project page and GitHub repository linked from Projects carry the implementation detail this note summarizes.