DEV Community

karthik
karthik

Posted on Originally published at freetierwatch-eax.pages.dev

Self-host Immich: I measured what Google Photos replacement actually costs in RAM

#selfhosted #docker #photos #opensource

Originally published on FreeTierWatch, where we actually deploy and measure what we write about.

Immich is the self-hosted Google Photos replacement — 115,000+ GitHub stars, mobile apps with automatic backup, face recognition, and ML-powered search ("sunset over water" actually finds your sunset photos). It's the app that convinced a generation of self-hosters that leaving Google Photos was possible.

It's also the heaviest thing we've deployed in this series. Where Vaultwarden runs in 14 MB and Uptime Kuma in ~150 MB, Immich is a four-container stack that wants gigabytes. We deployed it, uploaded photos, ran the ML search, and measured what it really costs.

What you need (honestly)

  • 4 GB+ free RAM — our measured working set was ~2.4 GB across the stack, with spikes during ML processing
  • ~5 GB disk before any photos — the images alone total 4.7 GB
  • Docker + Compose, 20 minutes
  • Not a 1 GB VPS. This is the app the free Oracle ARM VM (12 GB RAM) was made for

Step 1: the official Compose stack

Immich ships its own Compose file — use it rather than hand-rolling:

mkdir immich && cd immich
curl -LO https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
curl -L -o .env https://github.com/immich-app/immich/releases/latest/download/example.env
Enter fullscreen mode Exit fullscreen mode

Edit .env before starting — two changes are non-optional:

# generate a real DB password (alphanumeric only — special chars break it)
DB_PASSWORD=$(openssl rand -hex 16)

# set your timezone or every photo's date will be UTC
TZ=Asia/Kolkata
Enter fullscreen mode Exit fullscreen mode

Also note UPLOAD_LOCATION=./library — point this at your biggest disk; it's where every photo lives.

docker compose up -d
Enter fullscreen mode Exit fullscreen mode

First start pulled 4.7 GB of images (server 2.44 GB, machine-learning 1.1 GB, Postgres-with-vector-extensions 989 MB, Valkey 180 MB) and took ~2.5 minutes on our connection. Then open http://localhost:2283, create the admin account, and click through onboarding.

What it costs to run (measured)

Container RAM (settled, 5 photos processed) Notes
immich_server 962 MB Peaked at 1.3 GB during initial processing
immich_machine_learning 928 MB ~200 MB idle; balloons when generating embeddings
immich_postgres 465 MB Vector-enabled Postgres (pgvecto.rs/VectorChord)
immich_redis (Valkey) 14 MB
Total working set ~2.4 GB
Other metrics Measured
Images on disk 4.7 GB
Database size (5 photos) 330 MB (ML models + vector indexes dominate)
Upload speed 5 photos (470 KB avg) in 235 ms via API
ML smart search "sunset over water" → correct photo ranked #1, 2.2 s on CPU
Server restart to ready 5 s

The headline: the machine-learning magic is real and runs fine on CPU — but it's why this stack needs several GB of RAM where a plain photo gallery would need 200 MB. That's the trade: Google-Photos-grade search, Google-Photos-grade resource bill (except you pay in RAM, not rupees).

Immich timeline showing uploaded photos

Gotchas we hit or verified

  • DB password charset: special characters in DB_PASSWORD break the connection string — the env file warns you; believe it. Alphanumeric only.
  • The compose file changes between releases. Immich moves fast (it only recently left "breaking changes any week" beta culture). Always re-download the compose file from the release you're upgrading to — don't just docker compose pull.
  • ML is optional but on by default. On a weak machine you can remove the immich-machine-learning service entirely — uploads and browsing work; you lose smart search and face recognition.
  • Mobile backup needs HTTPS or same-network HTTP. For remote access, put it behind a reverse proxy with TLS, or better: Tailscale — don't expose a photo library to the open internet.
  • The database is not disposable. Unlike our other guides where the data volume was a convenience, here Postgres holds all metadata, albums, faces, and edits. Back up BOTH the library folder AND a pg_dump — the official docs have a backup guide; follow it before you load 20,000 photos, not after.

When NOT to self-host Immich

  • Under 4 GB of spare RAM — it will run badly or not at all. This is the one app in our series where the free-tier PaaS options are all non-starters; it needs a real machine.
  • Your photos currently live only on your phone. Until your Immich server itself is backed up (3-2-1: the library folder + DB dump, off-site), it's not a backup — it's a second copy on hardware you administer. Google Photos' value was never the gallery; it was the durability.
  • Intermittent homelab. A backup target that's offline when your phone wants to sync defeats the purpose. Our test box is a workstation; a real deployment wants always-on — the Oracle free VM's 2 OCPU/12 GB fits Immich better than anything else free.

What we actually ran this on

  • Machine: Intel Core Ultra 7 255H (16 cores), 30 GB RAM, NVMe
  • OS: Ubuntu 24.04.5 LTS · Docker: 29.8.1, Compose v5.1.3
  • Immich: v3 (release tag), official compose: server + ML + VectorChord Postgres + Valkey
  • Verified: admin setup, API upload (5 photos), thumbnail + embedding generation, smart search ranking, restart persistence
  • Date: 2026-10-30

Top comments (0)