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

A developer at FreeTierWatch deployed the self-hosted Google Photos alternative Immich as a four-container Docker Compose stack and measured its resource footprint, finding a settled working set of roughly 2.4 GB of RAM across the server (962 MB), machine-learning (928 MB), vector-enabled Postgres (465 MB) and Valkey (14 MB) containers. The stack pulled 4.7 GB of images and took about 2.5 minutes to start, while CPU-based ML smart search returned the correct photo for "sunset over water" in 2.2 seconds. The measurements show the ML search and face recognition features, not the gallery itself, drive the multi-gigabyte memory cost.

Originally published on FreeTierWatch https://freetierwatch-eax.pages.dev/apps/immich-docker , 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 https://freetierwatch-eax.pages.dev/apps/vaultwarden-docker and Uptime Kuma in ~150 MB https://freetierwatch-eax.pages.dev/apps/uptime-kuma-docker , Immich is a four-container stack that wants gigabytes . We deployed it, uploaded photos, ran the ML search, and measured what it really costs. 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 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 Also note UPLOAD LOCATION=./library — point this at your biggest disk; it's where every photo lives. docker compose up -d 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. | 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 . DB PASSWORD break the connection string — the env file warns you; believe it. Alphanumeric only. docker compose pull . immich-machine-learning service entirely — uploads and browsing work; you lose smart search and face recognition. library folder AND a pg dump — the official docs have a