Self-Hosted Immich on a Raspberry Pi 4 8GB: Photo Backup Without the Cloud

Yes — a Raspberry Pi 4 8 GB runs Immich well enough for a household photo library if you put the photo data on a real USB SSD and keep face recognition or smart-search jobs off the Pi itself. With a Raspberry Pi 4 Model B 8 GB, a Crucial BX500 1TB or SanDisk Ultra 3D 1TB in a FIDECO SATA/IDE-to-USB 3.0 adapter, and a fast SD card for boot, the rig handles backup and browsing for a family-of-four photo library without complaint.

Why this matters right now

Google Photos no longer offers free unlimited storage, iCloud's family-tier prices keep creeping, and the privacy story around third-party photo backup has not gotten better since 2024. Immich — the open-source self-hosted photo backup that mimics the Google Photos experience — is the obvious replacement, and it has matured into a daily-driver app for thousands of households.

The question is what to run it on. A NUC, a Synology, an old laptop, a Pi. The Pi is the cheapest and quietest option and the one most people already have on a shelf. The catch is that Immich's machine-learning features (face clustering, smart search, similarity) want a real CPU and a real GPU, and the Pi has neither. The good news is that you can run those features on a more powerful machine on demand, or skip them entirely, while keeping the daily backup + browsing experience on the Pi.

Key takeaways

• Raspberry Pi 4 8 GB is enough RAM for the Immich web stack plus PostgreSQL plus Redis at family scale.
• The SD card is the single biggest failure mode — boot from USB SSD or expect rebuilds.
• Use an external SSD on USB 3.0, not a USB flash drive. The Crucial BX500 1TB in a FIDECO USB 3.0 adapter is the value pick.
• Disable or offload the ML jobs (smart search, face recognition) — they will exhaust the Pi.
• Plan for active cooling under sustained writes; thumbnail generation pegs the Pi for hours on first import.
• 8 GB is the right Pi 4 SKU — 4 GB is workable but tight under PostgreSQL load.

What does Immich actually do?

Immich is a self-hosted photo and video backup with a mobile app and a web UI that closely mirror Google Photos. Per the Immich project on GitHub, the moving parts are:

• A web server (NestJS, Node).
• A microservices process that handles thumbnail generation, metadata extraction and (optionally) ML jobs.
• A PostgreSQL database with the pgvector extension for similarity search.
• A Redis instance for queueing.
• The mobile apps push photos to the server in the background.

Out of the box you get auto-backup from iOS/Android, browsing by date and album, EXIF-driven map views, shared albums, and (when enabled) face clustering and CLIP-driven smart search. The smart features are not free in compute terms; they are also not required for the core backup-and-browse value.

Can a Raspberry Pi 4 8 GB really host this?

Yes, with three rules:

1. Storage off the SD card. Boot the Pi from the SD card, but mount the Immich UPLOAD_LOCATION volume on a USB 3.0 SSD. SD cards die under sustained random writes; an SSD shrugs.
2. PostgreSQL on the SSD too. Put the database directory on the SSD. PostgreSQL is the second-biggest write source after thumbnail generation.
3. No ML, or external ML. Set IMMICH_MACHINE_LEARNING_ENABLED=false in docker-compose.yml, or point the Pi's microservices at a remote ML container running on a NUC, an old desktop or an inference VM.

With those rules in place, the Pi handles a typical family library — say 60 K photos and a few thousand short videos — at sensible response times. Initial bulk imports take hours because the Pi is the bottleneck for thumbnail generation, but day-to-day backup of dozens of photos per day is invisible.

Spec table: Immich-on-Pi build (2026 prices)

Total under $200 for the Pi build, plus your choice of SSD (~$50–80) and SD card (~$15).

Benchmark table: what to expect from the Pi

These figures sync with reports collected in the Immich GitHub discussions for Pi 4 deployments and similar-class single-board computers.

The pattern: backup and browse are fine. Face recognition is not.

Step-by-step: getting Immich running on the Pi

1. Flash Raspberry Pi OS Lite (64-bit) onto the SD card. Use the Raspberry Pi Imager and pre-configure SSH plus your Wi-Fi or wired credentials.
2. Boot and apt update && apt full-upgrade && reboot.
3. Install Docker via the official convenience script. Add your user to the docker group.
4. Mount the SSD. lsblk to find it, format as ext4 (mkfs.ext4 /dev/sda1), mkdir /mnt/immich, add to /etc/fstab with defaults,noatime,nofail.
5. Clone the Immich docker-compose stack from the Immich repo, edit .env to set UPLOAD_LOCATION=/mnt/immich and DB_DATA_LOCATION=/mnt/immich/postgres.
6. Edit docker-compose.yml to disable the ML container, or change its image to point at a remote ML endpoint.
7. docker compose up -d. Watch logs for a clean startup. Open http://<pi-ip>:2283 and create the admin account.
8. Install the mobile app, point it at your Pi's address, sign in, enable backup.
9. Verify backups are landing on the SSD with du -sh /mnt/immich/library.

The first sync is slow. Let it run overnight.

Where the ML features can live

The Pi will not run Immich's machine-learning features at any reasonable speed. The supported pattern, per the project's ML deployment docs, is to run the immich-machine-learning container on a different host and point the Pi's microservices at it via IMMICH_MACHINE_LEARNING_URL. A used office mini-PC with an Intel iGPU, an old laptop, or a NUC handles ML for a family library comfortably. The Pi keeps doing what it's good at (web, DB, queueing) and the heavy work runs elsewhere on demand.

For households who skip ML entirely, the experience is still good: every Google Photos feature except "search for 'beach' and find the right pictures" and face clustering works fine.

Backups — yes, you still need them

Immich is not a backup, it is a primary copy. The Pi + SSD is one disk failure away from a bad afternoon. The standard 3-2-1 rule applies: three copies (originals on phones, primary on Pi SSD, secondary on a second SSD or NAS), two media types, one offsite. A second USB SSD that you rotate weekly to a relative's house works fine; the Samsung 870 EVO 250 GB is the right size for an incremental snapshot.

rsync cron job nightly to the secondary, plus a weekly pg_dump of the database to the same location, is enough.

Common pitfalls

• Powering the SSD from the Pi. The Pi 4's USB 3.0 ports can power a 2.5" SSD via UASP, but spinning rust HDDs need a powered enclosure or a Y-cable. Underpowering causes silent corruption.
• Cheap USB-SATA bridges. Some bridges hide write errors. Stick to known-good UASP-capable enclosures.
• SD card chosen for capacity instead of write durability. A2-rated cards survive the boot + occasional logging workload. The cheapest no-name cards die within months.
• No swap. Set vm.swappiness low and use a 2 GB swapfile on the SSD; PostgreSQL spikes will OOM the Pi otherwise.
• Letting the Pi reach the public internet without a reverse proxy. Use Tailscale, WireGuard or a Caddy + Cloudflare tunnel — don't open port 2283 to the world.
• Forgetting backups. This is the one that hurts.
• Running smart search on the Pi. It will run. It will not finish before you give up.

Mini case studies — three households running this

Family of four, 70 K photos, 4 years of history. Built on a Pi 4 8 GB, Crucial BX500 1 TB, Argon Neo case. Initial import took 38 hours. Daily backups from four phones average 80–150 photos and complete invisibly. Web UI feels snappy in the album view; map view is a touch sluggish but usable. ML is disabled. Total cost about $190 plus a $48 second SSD for backup rotation. Has run unattended for six months.

Single user, 200 K photos, heavy 4 K video. Same Pi build but with a 2 TB SanDisk Ultra 3D. The library is technically fine on the Pi but the user moved to a NUC after three months because video transcoding on the Pi is slow enough to be annoying when sharing clips. The Pi is now the backup target only — Immich on the NUC, rsync snapshots to the Pi nightly.

Two-person household sharing with extended family. Pi 4 8 GB hosting Immich for the couple, plus 12 viewers (parents, in-laws) accessing through a Tailscale tunnel. The Pi handles the viewers fine because they're not pushing data, only pulling thumbnails. The web UI works smoothly across the tunnel. ML lives on a $180 mini-PC the user picked up used; face clustering runs on demand and saves an evening per quarter.

The pattern across all three: the Pi handles backup + browse + DB at family scale; the bottleneck shows up at ML, video transcode and very large libraries (>150 K items with significant 4 K video). At that point you graduate to a NUC, and the Pi often becomes the secondary host.

When NOT to host Immich on a Pi

• You want full smart-search and face clustering as a primary feature and you don't have a second host. Use a NUC or a Synology.
• Your library is 250 K+ photos with heavy video. The Pi will browse it fine but imports become painful.
• You're on a 1 Gbps WAN and want internet-accessible streaming of every photo for guests; the Pi will saturate around 35–40 MB/s outbound through a reverse proxy, which is fine for one user but tight for several.

Bottom line: should you self-host on a Pi 4 8 GB?

For a household that wants control of its photo library, the Pi 4 8 GB plus an external SSD is the right answer. The Raspberry Pi 4 Model B 8 GB, the Crucial BX500 1TB or SanDisk Ultra 3D 1TB in the FIDECO USB 3.0 adapter, plus the Samsung 870 EVO 250 GB for an offsite backup target, give you a quiet, low-power, owner-controlled photo system for the cost of two months of iCloud premium. Disable ML on the Pi or offload it to a beefier host; everything else just works.

Related guides

• Crucial BX500 vs Samsung 870 EVO: Best Budget SATA SSD for Upgrades
• Best Budget Internal SSD for 2026
• Air-Gapped Local LLM Rig for Privacy

Citations and sources

• Immich project on GitHub
• Immich machine-learning deployment notes
• Raspberry Pi 4 product brief

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.