The platform underneath: a homelab run like production

Every other project on this site runs on one always-on Dell OptiPlex. There's no Kubernetes and no cloud bill, and the interesting part isn't scale; it's operational discipline on a machine nobody is paid to maintain. The difference between a homelab and a science project is whether it's still working six months after you stopped thinking about it.

The service fleet

A single version-controlled Docker Compose file manages the core stack: PostgreSQL (shared by n8n and the trading system), n8n for workflow automation, Open WebUI for LLM chat against local and hosted models, CouchDB syncing my Obsidian vault across devices, a media stack, and the RoomTag inference server. Alongside Docker, a KVM/libvirt VM runs Cisco Modeling Labs for CCNA lab topologies.

Conventions, applied uniformly:

• One directory per service; compose definition and data live together.
• Credentials in .env files only, never in compose files, never in git.
• restart: unless-stopped on everything that should survive a power cut, and deliberately not on things that shouldn't (the Minecraft server doesn't need to outlive a reboot).
• Nothing exposed to the public internet: remote access is a Tailscale mesh spanning the OptiPlex, MacBook, iPhone, and the GPU desktop.

Backups that are actually checked

restic snapshots the compose tree, service data, and the Obsidian vault to NAS storage nightly, with a keep-daily/weekly/monthly retention policy. The part most homelabs skip: JARVIS runs a daily watchdog that compares the newest snapshot's age against a 25-hour threshold and pings my phone only if backups have stopped. Backup systems fail silently; monitoring is what makes them real.

Written operating rules

After enough self-inflicted outages, I wrote down operating rules and keep them in the same knowledge base as the infrastructure docs:

• Audit first, act second: verify actual state before changing anything; never trust memory of how a service was configured.
• Propose before executing: write out what will change before it happens, even when working alone. It catches bad plans while they're still cheap.
• No unconfirmed restarts: a restart hides evidence. Understand why a service is misbehaving before bouncing it.
• Flag surprises: anything that deviates from documented state gets recorded, not quietly fixed.

The same discipline extends to supply chain: I dropped one popular LLM-gateway dependency from the stack entirely after it shipped a compromised release: self-hosted doesn't mean exempt from vendor diligence.

Documentation as infrastructure

The stack is documented in an Obsidian vault that lives on the stack it describes (and is backed up off it): a verified service map, per-project notes with session logs, decision records with the reasoning attached, and runbooks. When something breaks at 11pm, the answer to "how was this configured and why" is a grep away.

Why it matters for the job I want

Solutions engineering is explaining systems you understand deeply to people who need to trust you quickly. This box is where that understanding comes from: networking, containers, databases, backups, VPNs, LLM tooling, not as course material but as things I've deployed, broken, monitored, and fixed.