Self-Host Immich on a Budget Homelab Box: Storage Tiers That Make Sense

For most homelabbers, a workable budget Immich box is an AMD Ryzen 5 5600G APU with 16–32 GB of RAM, a fast NVMe like the WD Blue SN550 for the OS and Postgres database, and a 1 TB SATA SSD like the Crucial BX500 or Samsung 870 EVO for the photo library itself. Total parts cost under $400, no discrete GPU required, and you get a self-hosted Google Photos replacement that handles a household-sized library without breaking a sweat. The trick is putting the database and the library on different drive tiers — that's where most "Immich feels slow" complaints come from.

Why Immich is the right self-hosted photo target in 2026

Immich quietly became the consensus self-hosted Google Photos replacement over the last two years. It has the features people actually use from cloud photo services — automatic mobile backup, face recognition, smart search, shared albums, map views, timeline scrubbing — and it has the trait those services don't: your photos live on hardware you own. After the steady stream of cloud provider price hikes, AI training opt-out drama, and the basic privacy concerns of giving Google or Apple every picture you take of your kids, the appeal is obvious.

What's less obvious is what hardware you actually need to run it well. Immich's documentation is honest about the requirements — modest CPU, modest RAM, modest GPU optional — but those minimums don't tell you what makes the difference between an Immich that feels snappy and one that doesn't. The answer turns out to be mostly about storage tiering. Get that right, even on cheap hardware, and Immich is genuinely pleasant to use. Get it wrong, and the same software on better hardware feels sluggish.

This guide walks the budget homelab build for Immich with specific picks for the storage tiers, calibrates expectations for the machine-learning workloads, and points out the operational gotchas — backups, power, library size estimation — that bite homelabbers six months in.

Key takeaways

• Immich doesn't need a discrete GPU; the Ryzen 5 5600G's integrated graphics and CPU handle face recognition fine.
• Put the OS and Postgres database on a fast NVMe like the WD Blue SN550. Don't mix it with the photo library.
• Put the photo library on bulk storage — a Crucial BX500 or Samsung 870 EVO at 1 TB is the right starting point.
• 16 GB of RAM is comfortable for most households; 32 GB if you have a big library or want to run other services on the same box.
• Plan backups before you migrate photos in. Self-hosting means you own the backup story.
• The initial ML pass on a large library can take days on CPU; it's a one-time cost, then incremental.

What you'll actually need: a checklist

• Host box. A small-form-factor PC or DIY mini-ITX build is the right answer for 24/7 use. The Ryzen 5 5600G is the canonical pick for budget homelabs because its integrated Vega graphics removes the need for a discrete GPU, and it sips power.
• OS SSD with the Postgres database on it. A WD Blue SN550 1TB NVMe is overkill capacity-wise but the right speed tier for a snappy database. The Postgres database is the single most performance-sensitive part of Immich's stack.
• Library storage. A Crucial BX500 1TB SATA SSD or Samsung 870 EVO at 1 TB or larger. SATA SSDs are dramatically faster than spinning disks for the random reads that thumbnail generation and library browsing trigger.
• RAM. 16 GB minimum. 32 GB if you can swing it — it gives Postgres more cache headroom and leaves room for other containers on the same box.
• OS. Debian, Ubuntu Server LTS, or Proxmox if you want to run Immich in an LXC container or VM. All three are well-supported for Docker, which is how Immich is deployed.
• Backup target. A second SSD (the Samsung 870 EVO is fine), a NAS, or an external drive. We discuss the strategy below.

Step 0 diagnostic: how big is your library, and how fast does it grow?

The single most important number to know before you spec the build is your current library size. Pull up your phone's photo settings or your existing cloud photos account and find out. A representative breakdown for households I've seen:

• A single person taking phone photos casually: 50–150 GB after 5–10 years.
• A young family with a couple of kids: 200–500 GB after 5–10 years, mostly because of video clips that have ballooned in size with each phone generation.
• A heavy photographer (DSLR or mirrorless shooter): 500 GB to several TB, often dominated by raw files.
• A multi-person household pooling everyone's photos: 500 GB to 2 TB.

The growth rate matters too. Photos and especially 4K phone video grow faster than people expect — a modern iPhone or Pixel can easily add 30–60 GB a year per person. Plan for at least three years of headroom from the start, ideally five.

For most readers, a 1 TB SATA SSD for the photo library is the right starting point. It gives you the speed advantage of solid-state storage for thumbnail generation and browsing, and it costs roughly the same as a 4–6 TB spinning drive without the noise and power penalty. If you have a much larger library, two paths: either step up to a 2 TB SSD now, or pair a 1 TB SSD for hot data with a larger spinning disk or NAS for older archives.

Which SSD tier for the OS and database, vs the photo library?

This is the single most important decision in the build. Immich's Postgres database stores all the metadata — face recognition vectors, EXIF data, search indexes, asset relationships, shared album state — and Postgres performance is dominated by random IOPS. An NVMe drive like the WD Blue SN550 is roughly 10× faster than even a quality SATA SSD for the random small-block reads Postgres does most.

The photo library itself, by contrast, is dominated by sequential reads of large files when generating thumbnails, transcoding video, or serving the originals. SATA SSD throughput is more than enough for that workload; you don't gain anything meaningful from NVMe for bulk storage, and NVMe costs more per gigabyte. Put the right drive where it matters.

The Postgres database itself is small — usually a few gigabytes even for a multi-terabyte library — so the NVMe doesn't need to be huge. The 1 TB NVMe gives you headroom for the OS, Docker images, container logs, and the ML model cache that Immich downloads on first run, plus future growth.

How fast does the ML face/object recognition pass run on a budget box?

Immich's machine-learning stack runs face recognition, scene classification, and smart-search embedding. On first run, it processes your entire library, which can take a long time for big collections. On the Ryzen 5 5600G, expect ML throughput in the range of 1–5 photos per second depending on the specific model and your image resolution — call it a few thousand per hour for typical 12-megapixel phone photos. A 100,000-photo library runs the initial pass in roughly a day; a 500,000-photo library is a few days.

The good news is that this is a one-time cost. Once the initial pass completes, Immich processes new uploads incrementally as they arrive, which is essentially free in user-perceived time. The other good news is that ML jobs run as a background queue — you can use Immich normally while the queue grinds through your library.

If you find the CPU ML pass too slow, the most straightforward acceleration is a cheap discrete GPU. A used NVIDIA card with 4–6 GB of VRAM gives you GPU-accelerated ML at roughly 10–30× the CPU speed. For most household libraries, this isn't worth the cost or power draw — the initial pass finishes in a couple of days regardless and then disappears as a problem. For very large libraries (1M+ assets), GPU acceleration becomes more compelling.

Does a fast NVMe really speed up Immich's database and imports?

In a word: yes, noticeably. The two operations that feel slow on Immich are library imports (the system has to read each file, extract EXIF, generate thumbnails in multiple sizes, and queue ML work) and the timeline scroll experience (which fires a lot of small Postgres queries as you scrub). Both benefit from NVMe.

A back-of-envelope comparison: a SATA SSD might give you 80,000–100,000 random read IOPS at queue depth 1. A Gen3 NVMe like the WD Blue SN550 delivers 250,000+ at the same queue depth and far more at higher queue depths. Postgres's typical query pattern lives in that random-small-read zone. The difference shows up in import speed (often 2–3× faster on NVMe) and in timeline scrolling smoothness, especially as the library grows past 50,000 assets.

You can run Immich with everything on a single SATA SSD, and it will work. It will just feel slower than the same machine with a proper NVMe for the database tier. Given how cheap a 500 GB or 1 TB NVMe is today, there's not much reason to skip it.

Power and reliability: keeping a 24/7 box quiet and backed up

A homelab Immich server is on 24/7, which makes power draw and reliability matter more than they would for a desktop. The Ryzen 5 5600G idles in the low 20s of watts at the wall for a properly configured system, which is roughly $25–$40 per year in electricity at typical US rates. Cooling at that draw is trivial — a Noctua tower cooler or even a quality stock cooler runs silent.

The reliability discipline matters more. Immich is now your photo backup, which means the device storing the master copy of your family's photos is hardware you own. That introduces failure modes that Google Photos quietly absorbed for you: drive failures, controller failures, electrical surges, accidental rm -rf, ransomware. The right answer is a backup strategy that exists before you put any photos onto the system.

The minimum viable backup is a 3-2-1 setup: three copies of the data (the primary library plus two backups), on two different storage media (an SSD and either another SSD or a spinning drive), with one copy off-site (a friend's house, a cloud bucket, a safety deposit box). For a budget build, that often looks like: primary library on the Samsung 870 EVO, a second backup on a Crucial BX500 in an external enclosure, and an encrypted off-site copy synced to Backblaze B2 or rclone-mounted cloud storage. Restic and BorgBackup are both excellent tools for the local-and-remote backup combination.

Test the backup. An untested backup is not a backup. Do a restore from your backup once a quarter to confirm the data is actually there and your tooling still works.

Common pitfalls when self-hosting Immich

• Putting the Postgres database on the same drive as the photo library. This is the #1 reason Immich feels slow on otherwise capable hardware. Split the tiers from the start.
• Underestimating library size. Phone video has ballooned. A 500 GB drive will fill faster than you expect.
• Skipping the backup setup. Self-hosting means owning the backup story. Don't put your family's photos on a homelab box without a tested 3-2-1 backup.
• Running the initial ML pass during the day and being surprised that the box is busy. Schedule it to run overnight, or just accept that the first 24–72 hours are noisy.
• Forgetting the mobile app's network requirements. Immich's mobile backup needs reachability from your phone to the server. Tailscale or WireGuard are the easy ways to make that work over the open internet without exposing your server directly.
• Ignoring power supply quality. A cheap PSU on a 24/7 box is the wrong place to save $30. Buy a quality unit rated for continuous operation.

When NOT to self-host Immich

Honest answer: if you don't already enjoy running a homelab, the operational overhead of self-hosting your family's photos is real. Google Photos and iCloud absorb a lot of complexity — backups, redundancy, offsite storage, software updates, disaster recovery. Self-hosting moves all of that into your court. For a household where one person manages the homelab and the rest just want the photos to work, you have to commit to maintaining the box reliably enough that no one notices.

If the household is one missed backup or one drive failure away from losing the family's photos, the right answer is to stay on cloud photos until you're confident in your backup discipline. There's no shame in using Google Photos for backups while you experiment with Immich for browsing and self-hosted access. The hybrid path — cloud for the family-critical primary backup, Immich for the self-hosted experience — is a sensible bridge.

Bottom line: the budget Immich storage recipe

A Ryzen 5 5600G host, WD Blue SN550 1TB NVMe for OS + database, Samsung 870 EVO or Crucial BX500 1 TB SATA SSD for the photo library, 16–32 GB of RAM, and a separate SSD for backups. Total parts cost under $400 for a build that handles a household-sized library comfortably and idles quietly enough to live in a closet.

The most important decision in the build is the storage tier split. Put the database on NVMe, put the library on a SATA SSD, and resist the temptation to "simplify" by putting everything on one drive. The same hardware feels meaningfully better when the database has its own fast storage.

For households outgrowing the 1 TB library tier, the same architecture scales cleanly: swap in a 2 TB or 4 TB SATA SSD for the library, or add a spinning disk or NAS for cold archive and keep the SATA SSD for hot data. The host CPU and database NVMe rarely need to change as the library grows — bulk storage is where capacity needs to expand.

Related guides

• Self-Host Jellyfin on a Ryzen 5 5600G Mini Build in 2026
• Ryzen 5 5600G vs Ryzen 7 5700X for a Budget Homelab and Virtualization
• Samsung 870 EVO vs Crucial BX500: Best Budget SATA SSD
• Homelab Month One: Raspberry Pi 4 or a Ryzen 5 Mini-PC?

Sources

• Immich project documentation
• Phoronix — Linux performance benchmarks
• AMD — Ryzen 5 5600G product page