# Building a Self-Hosted Photo Library That Survives Real Life

A self-hosted photo library sounds simple until it has to handle ten years of phone uploads, duplicate files, burst shots, RAW images, and family members who expect search to work instantly. My goal was not to build a perfect archival system, but a dependable home service: automatic mobile backup, fast browsing, face and object search, and storage that could be restored without relying on a SaaS account.

## Storage Layout

The most important decision was separating the application from the photo archive. The app, database, thumbnails, and machine-learning cache can be rebuilt; the original photos cannot. I keep originals on redundant storage, mount them read-write only where ingestion happens, and back them up separately with versioned snapshots.

```yaml
services:
  photos:
    image: ghcr.io/example/photo-library:stable
    volumes:
      - /srv/photos/originals:/library/originals
      - /srv/photos/cache:/library/cache
    environment:
      DATABASE_URL: postgres://photos:${DB_PASSWORD}@db:5432/photos
```

## Ingestion and Metadata

A good import pipeline should be boring. Phones upload into an intake folder, the library indexes the files, and metadata extraction happens in the background. I preserve EXIF data, avoid rewriting originals, and normalize only derived assets such as thumbnails and web previews. That makes it possible to migrate later without losing camera timestamps, GPS coordinates, or lens information.

## Search and Performance

The main performance trap is assuming the image files are the bottleneck. In practice, the database, thumbnail cache, and machine-learning jobs matter more for day-to-day use. Keeping thumbnails on SSD storage made browsing feel immediate, while originals could stay on larger, slower disks. Scheduled indexing also kept CPU-heavy recognition tasks from competing with evening uploads.

## Backup Strategy

Backups need to cover three things: originals, the database, and enough configuration to recreate the service. I snapshot originals hourly, export the database nightly, and keep the compose file plus environment template in a private repository. Restores are tested by bringing up the stack on a spare machine and verifying that albums, favorites, and metadata still match the originals.

## Tradeoffs

Self-hosting is not free storage with a nicer interface. It means owning updates, monitoring disk health, planning migrations, and explaining to users why remote access may occasionally be slower than a commercial cloud. For me, the tradeoff is worth it: the photos live on hardware I control, the archive is portable, and the system can keep working even if a vendor changes pricing or shuts down a feature.