Self-Host Immich Photo Backup on a Raspberry Pi 4 8GB in 2026

Yes — a Raspberry Pi 4 Model B 8 GB self-hosts Immich capably for a single-household photo library, as long as you replace the SD card with a real SSD and accept that machine-learning jobs (face recognition, smart search) run slower than on x86. Pair the Pi with a WD Blue SN550 1 TB NVMe in a USB 3.0 enclosure for the photo library and a Samsung 870 EVO 250 GB SATA SSD for archive backups, and you have a $200 Google Photos replacement that pulls 6-8 W idle.

This is the install most readers should do. Below is the why, the how, and the honest envelope.

Key takeaways

• A Pi 4 8GB is the minimum recommended board for Immich. The 4 GB model works but swaps under ML load and gets sluggish.
• Per the official Immich docs, the Postgres database + Redis + ML containers want headroom; 8 GB of RAM is the comfort zone.
• Run the photo library off an SSD, not a microSD card. NVMe-over-USB on the WD Blue SN550 is the right pick; SATA on the Samsung 870 EVO works for archive/cold storage.
• Initial library import + ML scan is slow on the Pi — budget 12-36 hours for a 50,000-photo backlog. Ongoing incremental scans are fast.
• A Pi-hosted Immich draws 6-8 W idle and 12-15 W under load — about $8-12/year in electricity.
• Keep an off-device backup (rclone to B2/S3, or a second SSD that you rotate). One Pi is not a backup strategy.

What you'll need

Total parts cost lands around $170-220 if you already own the SDcard. The Pi 4 8GB is the dominant cost; everything else is reusable.

Can the Pi 4 8GB handle Immich's machine-learning features?

Yes, but with patience.

Per the Immich documentation, the project includes face detection, face clustering, smart search via CLIP-like embedding, and object detection. All three run inside the immich-machine-learning container. On a Pi 4, the inference path is ARM CPU-only — there is no CUDA, no NPU acceleration via the standard distribution, no GPU offload. That means a face-detection job that takes 80-120 ms on a desktop with a discrete GPU takes 2-3 seconds on the Pi 4. Multiply by every photo in your library and the initial scan is measured in hours to days.

What the Pi delivers comfortably:

• Upload + storage. Drag-and-drop a folder; the web client and mobile app upload at full USB 3.0 SSD write throughput (~280 MB/s sustained, capped by your network if it is below that).
• Browsing. Thumbnail generation is fast enough that a 50,000-photo library is responsive once the thumbnail backlog is processed.
• Search by date / album / location. Pure SQL queries; the Pi runs them in milliseconds.
• Sharing links. Generated instantly.

What is slow:

• Initial face recognition scan. 50,000 photos at ~2-3 s/photo lands at 30-40 hours. Run it overnight for a week.
• Smart search via embedding. First scan is the slow part; queries after the embeddings exist are fast.
• Object detection. Similar to face recognition; slow upfront, manageable thereafter.

If your library is < 10,000 photos, the initial ML pass completes in a day and you never notice the slowness again. If your library is 100,000+, plan for a long-running background scan or skip the ML features.

Pi 4 8 GB performance envelope on Immich

Reported community measurements for Immich on a Pi 4 8 GB with NVMe-over-USB:

The shape of the table: I/O and UI are fast, ML is slow. That is the Pi 4's value proposition for Immich. If your priority is "back up phone photos automatically and browse them on every device," the Pi delivers. If your priority is "find every photo of my dog using natural language search," you are signing up for a slow initial pass.

Storage choice matters

The single most consequential decision is "do not run Immich off the microSD card." A microSD card has ~80-100 MB/s sustained read, ~30-60 MB/s sustained write, and a write endurance measured in tens of TB total writes. The Postgres database and Redis cache do constant small writes; an SD card running Immich will wear out in 6-18 months and corrupt halfway through.

The right storage choices:

NVMe over USB 3.0 (recommended primary). A 1 TB WD Blue SN550 in a USB 3.0 UASP enclosure delivers ~380-400 MB/s sustained (Pi 4 USB 3.0 ceiling), 600 TB write endurance, and a 5-year warranty. This is the right buy. Performance:

SATA SSD over USB 3.0 (acceptable, lower endurance). The Samsung 870 EVO 250 GB in a USB 3.0 enclosure delivers comparable throughput at lower endurance. Fine for archive / cold-tier; less ideal for the primary because endurance is lower.

The smartest configuration: NVMe for hot (the active database + recently-uploaded photos), SATA SSD for cold-archive / backup target. Immich's storage path is configurable to put older months on a slower drive.

Step-by-step install outline

1. Flash Raspberry Pi OS 64-bit Lite to a 32 GB microSD card using Raspberry Pi Imager. The 64-bit Lite image is the right base; do not pick the GUI variant.
2. Pre-configure Wi-Fi, SSH, and user account in the Imager's advanced settings before flashing.
3. Boot the Pi, connect via SSH, run sudo apt update && sudo apt upgrade.
4. Install Docker via the official Docker convenience script (curl -fsSL https://get.docker.com | sh) and add your user to the docker group.
5. Mount the NVMe SSD at /mnt/immich with an entry in /etc/fstab.
6. Create /mnt/immich/docker-compose.yml from the Immich docs' Docker template and edit UPLOAD_LOCATION to point at the SSD mount.
7. Set a strong DB_PASSWORD in .env. Do not skip this step.
8. docker compose up -d and wait 60-90 seconds for the stack to come up.
9. Open http://<pi-ip>:2283, create the admin user, and log in.
10. Install the Immich mobile app, configure server URL, sign in, and turn on backup of camera roll.

First-import gotchas:

• OOM on the ML container if immich-machine-learning runs concurrently with a large camera roll backup. Schedule heavy ML jobs overnight when uploads are quiet.
• Postgres "could not write to file" errors if your SSD enclosure briefly disconnects. Use a UASP-mode enclosure with stable power.
• Reverse-proxy timeouts if you front Immich with nginx and use the default 60-second timeout; Immich uploads of large originals can take longer. Raise to 600 s.

Power and reliability

A Pi 4 8 GB + NVMe SSD over USB 3.0 + GbE pulls about 6-8 W idle and 12-15 W under load. At US average electricity rates that is roughly $8-12/year. Compare to a small x86 mini-PC running the same workload: a Beelink / Mini Forum N100-class box pulls 8-15 W idle and 25-40 W under load. The Pi wins on power; the x86 wins on ML throughput.

For reliability, the things that kill 24/7 Pi servers in order of frequency:

1. Cheap power adapter delivering 4.9 V instead of 5.1 V → undervoltage → corruption. Use the official Pi 4 PSU or a known-good third-party 5 V / 3 A USB-C PSU.
2. SD card corruption from constant writes. Solved by running off SSD.
3. Thermal throttling at 80 °C+. Solved by passive aluminum case or Argon ONE.
4. USB enclosure UASP timeouts on cheap enclosures. Buy from known brands; avoid unbranded $10 enclosures.
5. Network drop-outs on Wi-Fi. Use wired GbE for the server.

Address those five and a Pi 4 server happily runs for years.

Perf-per-watt: Pi vs always-on PC

The Pi wins for "back up a household's photos and browse them." The x86 wins for "process a 200,000-photo library with full ML in under a week."

Verdict matrix

The Pi 4 8 GB is right if:

• Your library is < 50,000 photos.
• You want low power draw and silent operation.
• You are okay with slow initial ML processing.
• You will use it for photo backup + browsing primarily.

Step up to a mini-PC if:

• Your library is 100,000+ photos.
• You need fast face / object recognition.
• Multiple users hit the server concurrently.
• You also want to run other containers (Plex, Jellyfin, *arr stack) alongside.

Common pitfalls

1. Running off an SD card. The most common cause of "Immich kept corrupting and I gave up." Use an SSD. Always.
2. Cheap USB enclosure. Pi's USB controller is fussy. Buy a UASP-mode enclosure from a known brand (Sabrent, Orico, StarTech).
3. Underpowered PSU. A 5 V / 2.5 A phone charger is not enough for Pi + SSD. Use the official 5 V / 3 A.
4. Skipping the off-device backup. A self-hosted server is not a backup strategy. Set up rclone to a B2 or S3 bucket weekly.
5. Exposing the Pi to the internet without HTTPS. Use a Tailscale tunnel or a reverse proxy with Let's Encrypt. Do not port-forward 2283 raw.

Bottom line

A Pi 4 8 GB running Immich off a WD Blue SN550 NVMe and a Samsung 870 EVO SATA SSD backup is the cheapest, lowest-power Google Photos replacement that works in 2026. The initial ML scan is slow; everything else is fast. The Pi pulls less power than a smart speaker, runs silently, and costs about $200 in parts. For a household with 10,000-50,000 photos, this is the sweet-spot self-host.

For larger libraries or impatient users, step up to a small x86 mini-PC and accept the 25-40 W load draw in exchange for 3-5× faster ML inference. Either way, the era of mandatory cloud photo storage is over.

Related guides

• Build a Real-Time Flight Tracker on a Raspberry Pi 4 in 2026
• Host a Quake 3 + UT99 LAN Server on a Raspberry Pi 4 in 2026
• Raspberry Pi AI HAT+ Hits 26 TOPS
• Best Budget Self-Hosting Hardware in 2026

Citations and sources

• Immich — project documentation
• Raspberry Pi — Pi 4 Model B product page
• Phoronix — ARM benchmark coverage

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