KnowledgebaseSelf-Hosting › Immich on a LYLIX VPS — self-hosted photo backup (Google Photos alternative)

Immich on a LYLIX VPS — self-hosted photo backup (Google Photos alternative)

Immich is the leading self-hostable alternative to Google Photos / iCloud Photos — auto-backup from iOS and Android, face detection, search, shared albums, machine-learning tagging. Heavier than most self-hosting projects (Postgres, Redis, ML model for tagging), but the result is genuinely competitive with the hyperscaler offerings.

Sizing — read first

Photos take real storage. Average phone photo: 3-5 MB; phone video: 50-200 MB per minute of 4K. A family of four shooting a typical year: 100-300 GB. Plan storage accordingly.

RAM: ML model loading needs ~2 GB even at idle. The full stack on a 4 GB VPS is comfortable; 2 GB works but you'll see swap activity during heavy ingest.

CPU: ML processing (face detection, smart search) is CPU-intensive. Initial library ingest of thousands of photos takes hours of CPU time on a 2-vCPU VPS. Steady-state is light.

Install (Docker Compose)

Immich publishes an official compose file at https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml. Download, drop into /opt/immich/, customize the .env file:

# /opt/immich/.env
UPLOAD_LOCATION=/opt/immich/library
DB_PASSWORD=STRONG_PW
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
TZ=America/New_York
REDIS_HOSTNAME=redis
cd /opt/immich
docker compose up -d

Reverse proxy with WebSocket support (Caddy handles it transparently; nginx needs the WebSocket-aware config from the reverse-proxy-ssl-patterns article).

Initial setup

  1. Visit https://photos.example.com. Create admin account.
  2. Settings → Server → External library — set up the directory layout you want (if migrating from existing photo storage).
  3. Settings → ML Configuration — confirm models are loaded; ML jobs run in the background after each upload.

Mobile auto-backup

Install Immich mobile app (iOS / Android). Configure with your server URL + account. Enable auto-backup. The app uploads new photos as you take them, on WiFi by default (configurable).

Battery impact: minimal once initial backlog is done. Most users see no impact past the first sync.

Library structure

Default storage path: /opt/immich/library/upload/<userid>/<year>/<month>/. You can change the templating in Settings → Storage Template if you want a different on-disk layout.

For storage capacity beyond what the VPS disk holds, mount external storage:

  • rclone mount a Backblaze B2 or S3 bucket and point UPLOAD_LOCATION there. Slower than local storage; works.
  • Mount NFS/SSHFS from a NAS.

Backups

Three parts:

  • PostgreSQL database — pg_dump nightly. Contains user accounts, album/face/tag metadata.
  • Upload library — the actual photos. If this lives on cloud storage (rclone mount), it's already off-host. If local, restic / borg to off-host.
  • Optional: the machine-learning model cache (slow to rebuild but recoverable from network on demand; don't bother backing up).

The photos are immensely more important than the metadata — losing the database means re-importing; losing the photos means losing the photos.

Upgrade discipline

Immich is moving fast (weekly releases through major-version reorgs). Read release notes before EVERY upgrade — breaking changes happen. Pin to a specific tag (:v1.118.0) rather than :latest if you want to update on your schedule.

# Upgrade
docker compose pull
docker compose up -d

Privacy considerations

  • Photos contain metadata: GPS coordinates, device model, timestamps. Immich preserves all of it.
  • Backups to cloud storage need encryption — never put raw photos in a third-party bucket without encryption at rest (restic / borg encrypt everything; rclone has crypt overlay for raw storage).
  • Sharing albums via public URL exposes those photos publicly. Convenient; obvious caveat.

Also Read

« « Back

Powered by WHMCompleteSolution