Self-host Immich: Google Photos without the subscription — real resource numbers

Published 2026-10-30 · tested on Ubuntu 24.04, Intel Core Ultra 7 255H, Docker 29

TESTED — we actually deployed this

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

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.

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