Sizing a Lean VPS for a Personal Immich Photo Library
TL;DR / Summary: Self-hosting Immich on a cheap VPS works when you separate compute from bulk photo storage and size for thumbnail bursts, not fantasy smartphone counts. Plan disk growth, external object storage or a second volume, and a quiet upload schedule. Review budget VPS plans with RAM and NVMe in mind before you dump a decade of JPEGs onto a tiny root disk.
Photos break “tiny VPS” dreams at the storage layer first
Immich is not a static blog. It generates thumbnails, runs machine-learning jobs, and stores originals that dwarf the application container. A 40 GB root volume that looked fine for a reverse proxy will vanish after one family vacation library. Treat the app VPS as compute plus database, and put bulky originals on a volume or object store you can expand without rebuilding the whole box.
RAM needs spike during initial library ingestion and face recognition passes. A machine that feels fine at idle can thrash when you upload 20,000 historical photos overnight. Schedule big imports in batches and watch memory during the first week.
CPU quality still matters for transcoding previews. Prefer modern single-thread speed over a huge core count you will not saturate with a household of three users.
Draw the storage map before you click “deploy”
List where originals live, where thumbnails live, and where Postgres lives. Keep Postgres on fast local disk. Keep originals on expandable storage. Document mount paths in a one-page runbook so a future restore does not guess.
Estimate yearly growth from your phone habits. If each adult adds 8,000 photos a year at mixed HEIC/JPEG sizes, multiply by household members and add 30% headroom. That napkin math prevents surprise “disk full” alerts during a birthday party upload.
Decide now whether mobile backups upload over cellular. Many families should restrict uploads to Wi-Fi to avoid both carrier pain and random VPS ingress spikes on the road.
Lean sizing bands for a household library
- Trial library under 50 GB: 2–4 GB RAM VPS, NVMe root, nightly database dump.
- Growing family archive: 4–8 GB RAM, separate volume for originals, scheduled ML jobs off-peak.
- Multi-decade scan project: Expand storage first; do not buy CPU you cannot feed with disk.
Import strategy that respects a budget CPU
Do not point every phone at full-resolution historical dump on day one. Start with the last twelve months, confirm mobile sync and sharing albums, then pull older years in weekend batches. This order surfaces permission and URL mistakes early while the dataset is still small.
Pause face recognition during massive imports if the box swaps heavily. Finish file placement first; run ML when the disk queue is calm. Your future search quality still arrives—just without melting the VPS during dinner.
Backups are more than “I have the phones”
Phones are not archives. Dump Postgres regularly and verify you can restore Immich to a fresh VPS with the same volume mounts. Keep a cold copy of originals offline or in a second region. Ransomware and accidental rm do not care that your photos “also exist on a Pixel.”
Test a restore of one album, not merely a file listing. Opening a restored timeline builds confidence ordinary sync checks cannot.
Watch costs after the first happy month
Ingress and snapshot fees can rival the base VPS price if you snapshot huge volumes daily. Snapshot the system disk often; snapshot bulk photo volumes on a slower cadence with verified file-level backups. Downsize CPU later if graphs stay sleepy—storage growth is the bill that usually climbs.
Mobile clients, sharing links, and privacy defaults
Decide who can create share links and whether links expire. Family libraries fail socially when a temporary album becomes a permanent public URL. Set conservative defaults on day one, then loosen for a reunion event with a written end date.
On phones, confirm background upload behavior while charging overnight on Wi-Fi. A client that only uploads when the app is open will frustrate people and create staggered bursts that look like random VPS load spikes. Document the expected behavior in a three-bullet family note.
Turn on multifactor authentication for the admin user before the first external share. Photo archives are intimate; treat the admin account like banking, not like a hobby login reused from a forum.
Thumbnail storms and how to schedule them
Initial thumbnail and preview generation can dominate CPU for hours. Run those jobs after household bedtime or during a weekend morning when nobody needs snappy browsing. If the VPS offers burstable CPU credits, avoid burning the entire bucket on day one; stretch ingestion so interactive browsing stays usable.
Watch swap. If the machine swaps during machine-learning passes, cut concurrency rather than immediately buying a larger plan. Many deployments become fine after concurrency is tamed, saving monthly cost for storage growth instead.
Outbound bandwidth and family slideshow nights
Sharing a full-screen album to relatives on another continent can saturate a cheap network allotment. Prefer generating a smaller shared album or enabling download limits for external guests. Measure one slideshow evening before you invite the entire extended family to browse originals at once.
Import the first album after storage math checks out
Immich on a budget VPS is delightful when disks and RAM are honest. Map originals off the tiny root volume, ingest in batches, and prove backups with a real restore drill. When you pick iron, use Affordable VPS Server to match RAM and NVMe to your library plan, then invite family uploads only after the storage math survives week one.
