The Homelab

How It Started

When I bought my house I plugged in a voice assistant and started with the basics: turning lights on by voice. What started as a convenience quickly turned into curiosity. I wanted to know what else was possible, and that question drove everything that followed.

The Evolution

A Key Turning Point

When I wanted the house to react to signals from my phone and the stock voice-assistant app didn't support it, I found a third-party automation bridge that could connect the two. Setting up that integration was a turning point: it was the first time I had to research a problem, find a non-obvious solution, and wire two separate platforms together. That experience of finding a workaround is what started shifting my thinking from user to builder.

Device Categories

• Smart plugs, light switches, and bulbs throughout the house
• Voice assistants in most rooms
• Smart appliances: washer, dryer, dishwasher, TV
• Robotic vacuums
• Home security and monitoring hardware, deliberately not itemized here

Why It Matters

This project is where everything started. It's the reason I got curious about servers, networking, and software. Every subsequent project (the Linux server, the self-hosted backend, the application platform) traces back to the habit of asking "what else is possible?" that started with a single voice assistant.

Background

Rather than letting an old laptop collect dust, I wiped the original operating system and installed Linux, turning aging consumer hardware into a capable home server. This became my primary backend infrastructure and a deep education in Linux system administration.

What It Ran

• Self-hosted database and auth backend for personal web apps
• Reverse proxy with SSL termination
• Container management and orchestration
• Home automation platform
• Secure public ingress with no open router ports, retired in July 2026

Skills Developed

• Linux system administration from scratch: networking, users, services, security
• Container orchestration for multi-service deployments
• SSH hardening, firewall configuration, and server security fundamentals
• Self-hosted database setup and management
• Secure public-facing access without exposing a home IP

What It Became

The laptop's aging hardware eventually prompted an upgrade to purpose-built equipment. Rather than wiping it, it was retained as a secondary development server, a safe sandbox for testing new configurations before touching production.

The Hardware Choice

Chose a small-form-factor, low-power machine sized for always-on use: enough CPU and memory to comfortably run the full stack of services and applications, with idle power draw measured in watts rather than tens of watts. The right hardware for a home server is the smallest hardware that handles peak load. Anything bigger is wasted electricity.

Services Running

• Self-hosted database and auth backend
• Reverse proxy with SSL termination
• Container management and orchestration
• Home automation platform
• Self-hosted version control and CI/CD
• Uptime monitoring with alerting

Security Posture

SSH locked to key-based authentication. Firewall with default-deny rules and brute-force protection. All remote access runs through an encrypted VPN mesh, with no ports exposed on the home router. A secure tunnel used to route public traffic in without opening the router; I retired it in July 2026, and nothing has been reachable from the public internet since.

Migration Strategy

The core principle: keep the old server fully live until the new one was verified. Running both in parallel meant no service disruption at any point. Each service was migrated individually and verified before cutting over: database schemas migrated with integrity checks, configuration files archived and restored, and tunnel credentials transferred without recreation.

Key Lessons

• Parallel running is the only safe way to migrate a live server
• Migrating database schemas individually is more reliable than a full dump
• Configuration drift between machines is real, so verify versions everywhere
• A VPN mesh made the entire multi-machine transition invisible from a networking standpoint

What's on the Platform

The applications span several categories: personal finance, home management, productivity, and AI tools. Highlights include:

• A personal finance tracker that imports and categorizes transactions and tracks net worth
• A vehicle-maintenance log shared with family
• A home-improvement project ledger
• A personal AI assistant
• Internal tools for managing servers, secrets, and documentation

How an App Gets Built

Why a Platform, Not Just Apps

Treating apps as one-offs would mean reinventing deployment, auth, backups, and monitoring for every project. A shared platform means new apps inherit all of that automatically, and the boring infrastructure stays consistent across thirty applications instead of drifting in thirty different directions.

Why Self-Host

• Zero ongoing database costs: runs on existing home server hardware
• Full ownership of data: nothing stored on third-party infrastructure
• Complete control over schemas, roles, permissions, and configuration
• Hands-on experience with PostgreSQL and production database management

Architecture

The full backend stack runs as interconnected containers. An API gateway sits in front of all services and handles routing and authentication. A secure tunnel used to expose the API endpoint publicly without opening any ports on the home router; I retired that tunnel in July 2026, and the API is now reachable only over my private network. Each application gets its own isolated PostgreSQL schema within the single instance.

Security

• Row-level security policies on all application tables
• Service tokens for application-to-API authentication
• All secrets stored in a password manager, never committed to version control

Backup

A nightly automated backup script runs against the live database and stores compressed dumps with rolling retention. A push monitor verifies the backup completed successfully each night and sends an alert on failure.

What I Learned

• PostgreSQL internals: roles, schemas, permissions, connection pooling
• How API authentication and token-based access control work in practice
• Container orchestration for a complex multi-service application
• How to migrate a live database instance between servers without data loss

The Problem

Keeping track of maintenance across multiple vehicles and equipment (oil changes, tire rotations, repairs) is easy to let slip. I wanted a custom tool tailored to how we actually use these vehicles, rather than relying on a generic app.

Architecture

Pegasus runs entirely on the home server: the same machine serves the app and its database, reachable only over my private network. All data is protected by row-level security policies inside the database.

What I Learned

This was my first real "shipped to production" app for someone besides me. It reinforced the value of schema isolation in a shared database and gave me hands-on experience with row-level security in a real production app.

Why a Routing Layer

By default, every application that talks to an AI model talks to it directly, which means no shared view of cost, usage, or latency across the homelab. Routing everything through one gateway gives a single source of truth: which apps are calling which models, how much each request costs, and where the slow paths are.

What It Powers

• A personal AI assistant integrated into the homelab
• Inline AI features inside other applications on the platform
• Experiments with local models for tasks where privacy matters more than capability
• Cloud models for tasks that need the strongest available reasoning

What I Learned

• The practical tradeoffs between local and cloud models: speed, privacy, capability, cost
• How a gateway pattern enables observability across an otherwise sprawling set of integrations
• Designing for graceful degradation when a model or provider is unavailable

Goals

The site serves a few purposes: a public home for my technical work, a place to document what I've built and learned, and a foundation I can expand as projects grow. It's also itself a project: a chance to practice frontend development, design, and deployment in a real context.

Design Approach

Clean, minimal, and developer-focused. Built to load fast, work well on any screen size, and let the projects speak for themselves. No frameworks or build tooling, just well-structured HTML and CSS that's easy to iterate on quickly.

What Makes It a Technical Project

Building a portfolio site sounds simple, but doing it well requires real decisions: how to structure content for both quick scanning and deep reading, how to connect a static frontend to a self-hosted backend securely, how to manage a custom domain across multiple services, and how to keep the site maintainable as more projects are added.

The Problem

A personal domain is only half the picture. Without a proper email setup, any contact forms, automated emails, or professional outreach still route through a generic free-mail address. Setting up email on a custom domain meant understanding how email infrastructure actually works at the DNS level.

Alias Structure

Rather than a single inbox, a structured alias system routes different types of communication to the right context: website contact, project inquiries, app support, automated outbound emails, and general use. All aliases forward to a single primary inbox.

What the DNS Configuration Involved

Getting email working correctly requires more than just pointing MX records at a mail provider. SPF and DKIM records are critical for deliverability. SPF defines which servers are authorized to send email for the domain. DKIM adds a cryptographic signature to outgoing messages that receiving servers verify against a public key published in DNS. Configuring both correctly ensures email from the domain is trusted by major providers.

What I Learned

• How email routing works at the DNS level, from MX record lookup through to inbox delivery
• The role of SPF and DKIM in email authentication and spam prevention
• How to structure a professional alias system for different communication channels
• Managing DNS records for a production domain

Why Native

A responsive website goes a long way, but a native app reaches things the browser cannot: home-screen widgets, health data, notifications, and an interface that feels at home on the phone. Building the companions natively meant learning a second platform end to end rather than settling for a wrapped web page.

One Shared Backend

The companion apps authenticate against the same self-hosted backend as the web apps, with the same row-level security and per-app data isolation. There is one source of truth, not a separate mobile database to keep in sync.

Stryde

My standalone app is a private strength-and-recovery trainer. It pulls a recovery score from Apple Health, runs an AI nightly analysis, guides a 13-week progressive program, and surfaces the day's plan in a home-screen widget. Workout and health data stays on the device; only a short text summary ever leaves the phone, and only for the nightly analysis.

What I Learned

• SwiftUI and SwiftData for native app structure and on-device storage
• Connecting a native app to a self-hosted Postgres backend with proper authentication
• Working with HealthKit, home-screen widgets, and the iOS app lifecycle
• Designing around a shared backend so web and mobile stay in lockstep

How It Works

• Scheduled agent jobs run in a fixed early-morning window, so anything disruptive happens while nobody is using the lab
• Routine reports flow into a silent mailbox; a single daily brief (the only email that notifies my phone) summarizes them at breakfast time
• Real problems skip the digest entirely and alert immediately

Guardrails First

Automation with real access needs real limits. The agents operate under a tiered permission model: routine operations run autonomously, while anything touching production or changing the shape of the fleet requires my explicit approval. Untrusted experiments run on a separate machine inside a sandboxed network segment that cannot reach anything else.

What I Learned

• Designing an approval model for autonomous systems: what they may do alone, and what needs a human
• Turning noisy machine output into one readable human briefing
• Sandboxing untrusted workloads so experimentation can't endanger the rest of the lab

The Layers

• Uptime monitoring on every service, with email alerts the moment something goes down
• Hardware and resource monitoring across all machines from one dashboard
• Automated nightly backups of databases, application data, and system configuration to network storage

Restore Drills

A backup you've never restored is a hope, not a plan. Each quarter I run a drill: pick a real database and a real set of files, restore them from backup onto a scratch environment, and verify the result is complete and intact. The drill has a written procedure and its results are logged, so "the backups work" is a tested claim, not an assumption.

What I Learned

• Monitoring is only useful if alerts are trustworthy: tuning out noise matters as much as coverage
• Backup design: what to capture, how often, and how long to keep it
• The difference between having backups and having tested recovery

What's Inside

• A registry of every machine, application, port, and credential location
• Numbered step-by-step procedures for deploying, promoting, and retiring apps
• A session log of every working session and a running backlog of planned work
• A troubleshooting log, so a solved problem never has to be solved twice

Kept Honest

Documentation rots when nothing checks it. Here it's searchable by an AI assistant that answers questions from its contents, and it gets a periodic consistency audit that re-derives facts from the live systems and flags anywhere the docs have drifted from reality. If the whole lab burned down, this system is detailed enough to rebuild any machine from scratch.

What I Learned

• Documentation-as-discipline: writing things down as the work happens, not after
• Making docs searchable and auditable so they stay trustworthy over time
• How good documentation turns one-person infrastructure into something maintainable

The Layers

• An encrypted mesh network connects the machines; there is no VPN server to attack because there is no exposed entry point at all
• Per-machine secrets vaults hold each app's credentials: no keys in code, no keys in the repositories
• Databases enforce per-user access rules at the data layer, so even a compromised app can't read another app's data
• Machines are tiered by trust: production requires explicit approval for every change, and experimental machines hold no keys to anything else

Assume It Will Be Public

Every app is built to a simple standard: it should survive its code being published tomorrow. Secrets stay out of the code entirely, security rules live in the database rather than the interface, and each app gets a security audit against that standard before it handles real data. The private network is a safety net, never the actual lock.

What I Learned

• Defense in depth: network, secrets, database, and process layers that each hold on their own
• Why "private network" and "secure" are different claims
• Building a security posture that survives growth instead of depending on nothing changing