HOMELAB / SYSTEMS IN PRACTICE
My home lab is where infrastructure gets practical: identity, automation, local AI, and services my household actually uses.
Built at home. Maintained after work.
THE SHORT VERSION
↘01 / DELIVERY
Public delivery
Reliable routes to published content
↓
02 / ACCESS
Identity & access
Sign-in and application permissions
↓
03 / SERVICES
Applications
Useful tools for real people
03 / OPERATIONS
Operations
Monitoring, automation & recovery
An illustration of engineering responsibilities, not a map of the live infrastructure.
01 / Identity before access
02 / Automation with boundaries
03 / Recovery over guesswork
01 / SELECTED WORK
Installing an app is the beginning. Connecting it cleanly, keeping it useful, and knowing how to recover it is the work.
01
IDENTITY & ACCESS
I work with centralized identity, application permissions, and reverse-proxy routing to make self-hosted tools easier to use and manage. The engineering is in joining those pieces cleanly while keeping access decisions explicit.
02
LOCAL AI & KNOWLEDGE
I build documentation-grounded assistants that help turn useful reference material into useful answers. The work includes keeping source material current, screening what gets included, and giving each integration only the access it needs.
03
BACKUP & RECOVERY
I use application-aware backup workflows that account for database state as well as files. Representative file and database restores have been verified in isolation, with recovery procedures documented alongside the work.
02 / THE EVERYDAY PLATFORM
The lab earns its space by doing useful things. Photos, documents, media, and shared tools give the infrastructure a reason to exist.
A
Self-hosted photos and files, with browser-based document editing.
Photo management / File sync / Document collaboration
B
A household library spanning films, music, books, and audiobooks.
Media libraries / Audiobooks / E-books
C
Running social and messaging services means working with queues, databases, and federation.
Federation / Message queues / Databases
D
Container stacks, logs, host monitoring, runbooks, and scoped agent experiments.
Docker Compose / Monitoring / Runbooks / Automation
03 / HOW I WORK
There is always another project. The trick is leaving the last one in a state I can explain.
Decide what is public, what needs identity, and what an automation is allowed to change.
Keep configuration, backups, and rollback steps close to the change. Verify the result before calling it done.
Clear names and useful runbooks beat remembering how something worked three months ago.