Homelab & Infrastructure

A small host treated like real infrastructure.

The Raspberry Pi is not a novelty box. It runs public portfolio and business applications beside private field tools, with each workload isolated, observable, backed up, and exposed only as far as its purpose requires.

PUBLIC EDGECloudflareTLS · DNS · Tunnel
RASPBERRY PI · ARM64Application host
PUBLICchrisdarden.devLoopback-bound web port
PUBLICHandyHoundsIndependent deployment
PRIVATE LANHVAC Field ManualEquipment records + photos
PRIVATE LANNFC StorageHousehold inventory + tags
TRUSTED DEVICESPhone · iPad · workstationPrivate services stay local

Operating principles

The architecture follows the consequence of failure.

A public portfolio and a private equipment database do not need the same exposure. Each application receives its own Compose project, database boundary, persistent storage, port, and deployment path so one release does not take another service down.

01

Isolate

Separate containers, networks, volumes, ports, environment files, and project names limit the blast radius.

02

Expose deliberately

Public sites use a managed tunnel. Sensitive tools remain reachable only from trusted local devices.

03

Persist intentionally

Database volumes and uploaded files survive container replacement and are included in backup planning.

04

Recover predictably

Known-good branches, migrations, health checks, backups, and rollback instructions make deployment repeatable.

Inside an application stack

Every service has a job and a health signal.

WEBNginxHTTP boundary and static assets
APPPHP-FPM + LaravelRequests, validation, and domain logic
DATAMariaDB / SQLiteWorkload-appropriate persistence
Queue workerSchedulerHealth checksPersistent uploadsProduction envARM64 builds
deploy / production
  1. 01fetch known-good branch
  2. 02build application images
  3. 03start database and app
  4. 04run migrations and optimize
  5. 05verify health + local HTTP
  6. 06confirm neighboring services

Deployment discipline

A release is not finished when one page returns 200.

Deployment verifies the application, database, worker, scheduler, local web boundary, public edge, and neighboring services. That last check matters: chrisdarden.dev should never earn uptime by breaking HandyHounds or a private tool sharing the host.

  • Deploy only reviewed main or a known-good release
  • Run migrations before traffic verification
  • Check disk capacity, container health, and recent logs
  • Re-test every existing public service after a host change

Security boundary

Show the architecture without publishing the keys to it.

This page documents patterns and responsibilities. It intentionally omits credentials, private addresses, internal hostnames, tunnel identifiers, customer records, equipment data, and household inventory.

See what runs here →