# Building a Self-Hosted Photo Library That Survives

A self-hosted photo library offers more control than a commercial cloud service, but storing files is only part of the job. A practical system also needs automatic uploads, metadata indexing, thumbnail generation, search, and reliable backups. I run the application on a small home server while keeping the original photos on mirrored storage.

## Deployment

The library runs as several containers: a web application, a PostgreSQL database, a Redis instance, and a background worker for machine-learning tasks. Pinning image versions makes upgrades predictable, while health checks prevent the application from starting before its dependencies are ready.

```yaml
services:
  photos:
    image: ghcr.io/example/photos:v1.12.3
    volumes:
      - /srv/photos/library:/data
    restart: unless-stopped
```

A reverse proxy provides HTTPS and limits the service to my local network and VPN. Mobile clients upload new images over Wi-Fi, and the server performs face detection and thumbnail generation asynchronously. This keeps uploads responsive, although the initial import can consume significant CPU and disk I/O.

## Storage and Backups

Original files live outside the container filesystem so that rebuilding the application cannot delete the library. The database is equally important because it contains albums, tags, sharing rules, and recognition data. Nightly backups copy both the originals and a database dump to encrypted off-site storage, with monthly restore tests to verify that the backups are usable.

## Maintenance

I monitor free disk space, database size, failed background jobs, and backup age. Before each upgrade, I read the release notes, create a fresh database snapshot, and update one version at a time. Self-hosting requires more maintenance than a managed service, but the result is a fast, private photo archive whose storage, retention, and access policies remain under my control.