Immich: Managing Photos Without Handing Them to the Cloud

Family photos pile up on phones, then move to a cloud gallery: the free tier shrinks, the subscription grows, and every picture with its metadata ends up on a third-party server. Immich answers both problems — the library stays on your machine with a feature set close to modern cloud galleries. This is an honest evaluation note.

Why Leave the Cloud Gallery

The core problem is not just cost, it is where the data ends up. Immich is open source under AGPL-3.0, actively developed, and officially described as a high performance self-hosted photo and video management solution:

AI search & facial recognition: Photos are grouped automatically by face and object keywords, processed on your local server.
Mobile background backup: iOS and Android apps upload photos from selected albums automatically in the background.
High performance: A microservice architecture built to handle tens of thousands of media files without lag.
No subscription: The cost moves to your own storage; no monthly quota that keeps shrinking.

Four-Container Architecture

Immich runs as four coordinated containers:

immich-server: Core API server and web interface (port 2283).
immich-machine-learning: Python service for AI feature extraction, vector search, and facial recognition; models persist in the model-cache volume.
immich_postgres: PostgreSQL with the pgvector and VectorChord extensions for metadata and CLIP-based contextual search.
immich_redis: Valkey/Redis job queue and cache for media processing.

Uploads land in the library directory, jobs go through the Redis queue, then extraction results are stored in PostgreSQL. Immich does not rescan the library folder, so database metadata is the source of truth.

Deployment with Docker Compose

The file below is enough to start; the official database image bundles PostgreSQL 14 with VectorChord and pgvector. The official template uses .env for UPLOAD_LOCATION, DB_DATA_LOCATION, and DB_PASSWORD; this compact version inlines them:

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:release
    volumes:
      - ./library:/data
    ports:
      - "2283:2283"
    depends_on:
      - redis
      - database
    restart: always

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:release
    volumes:
      - model-cache:/cache
    restart: always

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:8-bookworm
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0
    environment:
      POSTGRES_PASSWORD: change_db_password
      POSTGRES_USER: postgres
      POSTGRES_DB: immich
    volumes:
      - ./postgres:/var/lib/postgresql/data
    restart: always

volumes:
  model-cache:

Save the compose file, replace the password placeholder, run docker compose up -d, open port 2283, and create the first admin account. Releases are frequent, so pin the version via IMMICH_VERSION in .env.

Security and Privacy

Facial recognition, AI search, and location metadata processing happen locally on your server; no photos are sent to third-party APIs.
Port 2283 should not be exposed directly to the internet; use an HTTPS reverse proxy or Tailscale from outside.
Replace the PostgreSQL password placeholder and do not reuse credentials from other services.

What Stands Out in Daily Use

Convenient phone backup: New photos from selected albums upload automatically when the app opens and periodically in the background.
Smart search without manual tags: CLIP-based search accepts free-form queries such as “beach at sunset” without metadata.
Faces grouped into people: Faces are grouped, named, searchable per person; wrongly split clusters can be merged.
Open source: Full code control and no vendor lock-in.

Cons and Limitations

AI processing costs resources: Embedding and face detection run in the background; on a small machine, initial indexing of thousands of photos is noticeable. GPU acceleration needs dedicated image tags (cuda, rocm, openvino, etc.) and extra setup.
The database is a single point of failure: Immich does not scan the library folder; metadata and file paths live in PostgreSQL. Losing the database means rebuilding the gallery, so database backups are mandatory, not optional.
Storage grows beyond the originals: Inside UPLOAD_LOCATION, Immich creates thumbnails, transcoded videos, and profile files alongside the library.
Fast release cadence: New features arrive quickly, but upgrades need attention; pin the version and read release notes.
One machine equals one failure domain: A copy on the same machine protects against file loss, not against losing the whole machine.

Backup and Disaster Recovery

Two assets must be backed up together: the media folder (UPLOAD_LOCATION) and the PostgreSQL database — the store of album metadata, file paths, and face clusters. Without it, the files remain but the gallery structure is gone.

Immich ships automatic database backups: .sql.gz dumps land in UPLOAD_LOCATION/backups, schedule and retention are managed in the UI (daily by default, keeping the last dozen), and restore runs from the web interface under Maintenance or during onboarding. Dumps contain metadata only, not photos or videos — a copy of the media files still has to be made separately. Ideally both copies live off-host following a 3-2-1 strategy.

Conclusion

Immich closes the two main gaps of cloud galleries: data control and subscription cost. On a single machine with limited storage, budget for the AI processing footprint and backup discipline; tooling is provided, but off-host copies remain the owner’s responsibility. If you are ready for that commitment, Immich comes close to modern cloud galleries without handing photos to a third party.