A Raspberry Pi 4 with 8GB of RAM can self-host Immich for a single household's photo and video library as of 2026, but the experience hinges on two decisions: where you store the data (a USB 3.0 SSD like the Crucial BX500 1TB, not an SD card) and whether you enable hardware acceleration for ML features (currently CPU-only on the Pi, so face recognition and object tagging are slow). Per the Immich documentation, the 8GB Pi is the floor; the 4GB version struggles with ML jobs.
Who this is for
Hobbyists who want a self-hosted alternative to Google Photos or iCloud Photos for a single-user or small-household library — typically tens of thousands of photos and a few hundred videos. The Raspberry Pi 4 is the cheapest credible always-on Linux box that can run Immich, and the 8GB model has just enough RAM to keep the database, ML services, and Immich's microservices stack alive simultaneously.
This is not the article for someone with a hundred-thousand-photo professional archive or a multi-user family server. For those use cases, a small x86 box or a mini-PC is a better fit; the Pi 4 wins on cost, power draw, and simplicity, not on absolute throughput.
Key takeaways
- The 8GB Pi 4 is the floor for a usable Immich install. 4GB struggles; 2GB and 1GB are non-starters.
- Storage choice dominates the experience — a USB 3.0 SSD like the Crucial BX500 1TB is mandatory; SD cards or USB 2.0 will be painful.
- ML jobs (face recognition, object tagging) run on the CPU and are slow on the Pi. Upload and basic browsing are fast.
- Plan for off-Pi backups. A self-hosted server with no backup is a single-disk single-point-of-failure waiting to happen.
- A vintage IDE adapter like the Unitek SATA/IDE to USB 3.0 is useful for ingesting old photo archives from legacy hard drives.
Why Immich on a Pi 4?
Per the Immich project page, Immich is a self-hosted photo and video management application designed as a drop-in replacement for Google Photos. It does the things you actually use Google Photos for: timeline browsing, mobile auto-upload, face grouping, object search, sharing albums. Doing it on hardware you control means the photos never leave your network unless you choose to share them, the subscription bill drops to zero, and you keep the original RAW files instead of compressed previews.
The Pi 4 8GB is the right hardware for this when the alternative is "buy a NAS for $500" or "buy a mini-PC for $300 plus electricity." The Raspberry Pi 4 8GB draws under 10W under typical Immich load, sits anywhere on a shelf without making noise, and runs a current Debian-based OS that Immich officially supports.
The hardware build
A complete Immich-on-Pi-4 build:
- Raspberry Pi 4 Model B 8GB — the 8GB RAM is mandatory; 4GB will OOM under ML load.
- A microSD card for the OS boot drive. Any reputable 32GB+ A2-rated card; this is not where photos live.
- A USB 3.0 SSD for the photo library — the Crucial BX500 1TB in a USB 3.0 enclosure is the value pick. The Pi's USB 3.0 ports cap at around 350 MB/s real-world, which is faster than the BX500 needs anyway.
- A reliable power supply — the official Pi 4 USB-C PSU is the safe choice; underpowered chargers throttle the Pi under load.
- A passive heatsink or small fan — Immich's ML jobs sustain CPU load and the Pi 4 will throttle without active cooling.
Optional: a USB 3.0 IDE adapter is useful for ingesting photo archives from old hard drives during initial library setup. Image the drive, mount the image, and copy the photos into Immich's import directory.
Software setup overview
Per the Immich install documentation, the recommended install is Docker Compose. On a Pi 4, the steps are:
- Install Raspberry Pi OS Lite 64-bit on the SD card. The 64-bit OS is required for current Immich images.
- Install Docker and docker-compose-plugin.
- Mount your USB 3.0 SSD at a stable path (use
/etc/fstabwith the UUID, not the device node). - Download the official
docker-compose.ymland.envfiles from the Immich project. - Edit
.envto pointUPLOAD_LOCATIONat the SSD. docker compose pull && docker compose up -d.- Open
http://<pi-ip>:2283in a browser, create the admin account, configure mobile auto-upload.
The first start takes a few minutes because the Pi has to pull and start several container images (server, microservices, PostgreSQL, Redis, ML). Watch docker compose logs -f for the "Immich Server is listening on port 3001" line before assuming it's up.
Performance frame: what to expect on a Pi 4 8GB
The honest performance picture, based on community reports and the Immich performance documentation:
| Workload | Pi 4 8GB experience |
|---|---|
| Mobile auto-upload | Real-time; no perceptible lag |
| Web UI browsing | Snappy on local network |
| Thumbnail generation | Fast for JPEG, slow for RAW |
| Face recognition (ML) | Slow — minutes per face for a fresh import of thousands of photos |
| Object tagging (ML) | Slow — similar to face recognition |
| Search | Fast once indexed |
| Initial library import | Hours for tens of thousands of files |
The ML jobs are the slow part. They run on the CPU because the Pi 4 has no usable GPU acceleration for ONNX-style models. Once an initial library has been processed, ongoing daily uploads are processed in the background quickly enough that you won't notice the lag. Expect to leave the Pi running for several days after the initial import while ML finishes cataloging.
Why storage choice matters more than CPU
Immich's database and metadata store live on whatever disk you point them at. If that disk is a slow SD card, every database write — and there are many during initial import — pegs IO. A microSD card running at 50 MB/s sequential will turn a one-hour import into a one-day import.
The Crucial BX500 1TB in a USB 3.0 enclosure gives you SATA-SSD performance (around 540 MB/s read, 500 MB/s write) capped by the Pi's USB 3.0 host controller. In practice you'll see 300–350 MB/s sustained, which is far more than Immich needs for any workload. Use this disk for UPLOAD_LOCATION and for the Postgres data volume — both want fast random IO.
The microSD card stays as the OS boot drive only, where it does the right kind of work (read on boot, occasional log writes) at the right speed for what it is.
Backup strategy — non-negotiable
A single-disk self-hosted photo library is a single-disk single-point-of-failure. The SSD will eventually fail. Plan for that before it happens.
The minimum viable backup:
- A second external USB drive for nightly
rsyncof the Immich data directory. - An off-site copy — cloud bucket, a friend's house, anywhere the second disk being stolen along with the first wouldn't take both. Restic or Borg work well for this and have Pi-compatible builds.
- A documented restore procedure you actually test once a year. A backup you can't restore from is theatre.
The Crucial BX500 makes a good secondary backup drive too — buy two for the build, one for the live library and one for the local backup target.
Real-world worked examples
Case 1: a household library of 25,000 photos. Initial import from a USB drive plugged into the Pi takes about 4-6 hours for the copy itself, then another 12-24 hours of background ML processing. Once complete, the daily upload of 20-50 new photos from a phone is real-time. CPU temperature sits around 65°C under sustained ML; an active fan keeps it below 60°C.
Case 2: ingesting an old hard drive of family photos. Connect the old IDE drive to the Pi via the Unitek SATA/IDE to USB 3.0 adapter, mount it read-only, copy the photos to the Immich upload directory. Immich auto-detects the new files and ingests them on its next scan.
Case 3: shared family album. Configure user accounts for each family member. The Pi handles half-a-dozen concurrent users on local network browsing without issue. ML jobs still run in the background regardless of who's logged in.
Real-world pitfalls
- Running on a microSD card. Don't. The lifespan is too short and the write speed is too slow for sustained library work. SD is for the OS boot drive only.
- Skipping the SSD enclosure quality check. A cheap USB 3.0 enclosure can drop to USB 2.0 speeds intermittently. Buy a known-good UASP-compatible enclosure or a self-powered USB SSD.
- Underpowered PSU. Cheap USB-C chargers throttle the Pi and corrupt writes. Use a quality 3A+ power supply.
- Not running Pi OS 64-bit. Current Immich containers require a 64-bit OS. The 32-bit image still ships by default for older Pi compatibility.
- Skipping backups. The single most common failure mode is "the disk died and there was no second copy." Don't be that person.
- Mounting the SSD by device node. USB device nodes shuffle between reboots; mount by UUID in
/etc/fstab.
When NOT to do this
If you have more than ~50,000 photos, an active video collection that you regularly upload, or multiple family members who all want fast ML search, the Pi 4 will frustrate you. A mini-PC with an N100 or N305 CPU costs about 3x more but processes ML jobs 10x faster and handles concurrent users without sweating. The Pi 4 wins on cost and power; it loses on raw throughput.
If you don't have a backup plan, do not start. The self-hosted advantage evaporates the moment you lose the library to a dead disk.
Network exposure and remote access
Once Immich is running on the Pi, the next decision is how (or whether) to expose it outside your home network. Three common patterns:
LAN-only access. Easiest and most secure. Immich is reachable only on your home network. Mobile auto-upload works when you're at home; you'll need to remember to open the app on Wi-Fi to sync. This is the right starting point for most households.
VPN access (Tailscale, WireGuard). A Tailscale or WireGuard tunnel gives you secure access to the Pi from anywhere without exposing it to the open internet. Tailscale's official quickstart takes about 10 minutes on a Pi. Mobile devices on the same tailnet auto-upload over the tunnel. This is the right balance for most users who want remote access without running a public-facing server.
Public reverse proxy with HTTPS. A Cloudflare Tunnel or Nginx reverse proxy with Let's Encrypt certificates gives anyone with the URL and credentials access from the open internet. This is the right pattern for sharing albums externally but adds attack surface — keep Immich up to date and require strong passwords.
Whatever pattern you pick, never expose Immich's admin port to the open internet without authentication. The default configuration assumes a trusted network.
Comparison vs other Pi-class options
A few alternatives to the Pi 4 8GB worth knowing about for the Immich use case:
- Raspberry Pi 5 8GB. Faster than the Pi 4 across the board, modestly more expensive. Worth the upgrade if you're starting fresh; not worth the upgrade if you already have a Pi 4 working.
- Mini-PC with N100 CPU. Roughly 3x the cost of a Pi 4 build, but ML jobs run 5-10x faster and the system handles concurrent users better. The right pick for a household library larger than ~30,000 photos.
- Used ThinkCentre / OptiPlex tiny PC. A used Intel-i5-class mini desktop costs roughly the same as a Pi 4 8GB build but offers x86 compatibility with the entire Linux ecosystem. Slightly more power draw; significantly more headroom.
- NAS appliance (Synology, QNAP). Purpose-built but typically expensive. Immich runs on most modern NAS units via Docker; check the NAS's CPU architecture before assuming.
For most hobbyists at modest library size, the Pi 4 8GB remains the cheapest credible option. Once your library or user count grows past what a single Pi can comfortably handle, the next step up is one of the mini-PC options above.
Power and reliability notes
A Pi 4 running Immich 24/7 has been reliable in community deployments for years, but a few practical notes:
- Use a UPS (uninterruptible power supply) for the Pi + SSD. A power blip during a database write can corrupt Postgres state. Cheap consumer UPSes from APC or CyberPower keep the Pi running through a 5-10 minute outage.
- Monitor disk health. Add
smartmontoolsand check the SSD's SMART data monthly. SSDs fail differently from spinning drives — often without warning until the very end. - Update on a schedule, not impulsively. Set aside a monthly window to update OS packages and the Immich containers. Major Immich updates occasionally require config changes — read the release notes before pulling new images.
- Keep a spare microSD card with a known-good OS image, in case the OS card fails. Restoring the OS is fast; the data on the SSD is preserved.
Bottom line
A Raspberry Pi 4 8GB paired with a Crucial BX500 1TB SSD in a USB 3.0 enclosure is the cheapest credible Immich self-host box as of 2026. Expect snappy day-to-day use, slow initial ML processing, and a non-negotiable need for backups. For ingesting old photo archives, the Unitek SATA/IDE to USB 3.0 adapter is a useful add-on. If your library is much larger than a single household's collection, step up to a small x86 box instead.
Related guides
- Imaging Vintage IDE Drives with a CompactFlash + USB Adapter
- Best Budget GPU for Local LLMs in 2026: The 12GB RTX 3060 Case
- Best AMD Ryzen 5000 CPU for Gaming in 2026: 5 Picks
Citations and sources
- Immich — project home and installation documentation
- Raspberry Pi Foundation — Raspberry Pi 4 product brief
- Restic — encrypted backup tool — reference for an off-site backup workflow
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
