I Replaced Another SaaS Subscription with Self-Hosted Immich for 90 Days

If you have been following this blog, you know the pattern by now: the Zapier to n8n switch, the Docker and Podman deep dives, and my standing rule that a SaaS subscription has to earn its keep.

Google One was the next target. Not because Google Photos is bad. It is genuinely excellent at exactly one thing, which is being Google Photos. The problem is everything around it: the subscription creep, the storage math that shares one quota across Photos, Drive and Gmail, and the fact that our family's entire photo archive lives on someone else's servers, scanned and indexed by someone else's models.

So I cancelled Google One, moved the library to Immich running on hardware I already own, and lived with it for 90 days as the primary photo solution for a household of four. This is the unfiltered report: what worked, what it costs, the privacy story, and the parts that are still genuinely missing for families.

The short version

• Immich replaced Google One for our photo library and the recurring cost went to almost zero. The software is free (AGPLv3) and runs on the same N100 mini PC that already runs my six-month n8n review stack. The only recurring costs left are electricity, an optional VPS for offsite backup, and a domain.
• The photos never leave the house. Machine learning, facial recognition, OCR and search all run locally. Nothing is scanned by a cloud service, and there is no advertising data pipeline attached to your library.
• The team has been shipping at full speed for years. Immich went stable with v2.0.0 in October 2025 and shipped v3.1.0 on July 29, 2026, roughly one release per month the entire time. The project passed 110,000 GitHub stars and 10,000 commits, and the core team went full time in 2024 when the project joined FUTO. More on why that matters below.
• The family gap is real, and the maintainers say so themselves. Immich is still fundamentally one user, one library. There are no user groups yet, and shared albums do not merge into a recipient's timeline, memories, or face library. This is the part that decides whether you can switch, so I researched it properly and dedicated a full section to it.

Why Google One stopped making sense

The breaking point was a mix of cost, control, and a quiet storage squeeze. Google One plans as published on Google's own plan page at the time of writing: Basic at 100 GB for $1.99 per month, and the AI Plus tier at 2 TB for $9.99 per month. That storage is shared across Google Photos, Drive and Gmail, which means your inbox and your documents eat the same quota as your family photos.

Two more things made the math worse. First, original-quality photos count against your quota at full size, and the "storage saver" option compresses your originals to fit. Second, a family of four with phones, cameras and years of videos grows a library faster than most people expect, and the tier jumps are steep: $1.99, then $9.99, then roughly $20 and up.

Then there is the part that bothered me most: the photos are processed on Google's infrastructure. Face clustering, object recognition and search all happen in the cloud, which means the entire family archive is a training and feature surface for a company whose business model is not exactly "keep your data private." For some people that trade is fine. For me, after years of running my own systems, it stopped being acceptable for irreplaceable family photos.

The setup (what actually worked)

The migration itself was the part I dreaded, and it went surprisingly well. The stack looks like this:

• Hardware: the same N100 mini PC that runs the n8n stack, plus a pair of large spinning drives in a mirrored layout for the photo store. Nothing exotic, no GPU required for a library this size.
• Software: Immich server, machine learning and Postgres as containers under Docker Compose, exactly the setup the official docs recommend. The Docker Compose vs Kubernetes post covers why a single box stays on Compose.
• Access: local on the LAN, and remote through the same Pangolin and Newt remote access stack I described in the n8n review, with zero forwarded ports on my home router.
• Migration: Google Takeout gave me a dump of the archive, and immich-go did the heavy lifting, recreating albums and preserving dates. For the family NAS folder with the old trips and scans, I used an external library instead, which lets Immich index files in place without copying them.

$ immich-go upload --server=http://immich.local:2283 \
    --api-key YOUR_API_KEY \
    --create-albums ~/Takeout/Google\ Photos

What has been great after 90 days

• Cost. This is the headline. Google One was a recurring bill; Immich is a line item that does not exist. Hardware was already there, electricity is a rounding error, and the software itself is free. My monthly cost table is further down.
• Speed. The web app and mobile apps feel faster than Google Photos on the same network, and everything works over LAN instantly. Thumbnail generation, face detection and OCR all ran fine on the N100 for our library; a GPU is a nice-to-have, not a requirement.
• Originals stay originals. No compression, no "storage saver", no re-encoding behind your back. The files on disk are the files you took, in standard formats, and you can reach them with any tool.
• Search, faces and memories are local. CLIP-based semantic search, facial recognition clustering, OCR text search and the map all run against your own server. The quality is very good for a self-hosted system, and none of it phones home.
• The apps are genuinely good. First-party Android and iOS apps with background backup, album sync, Live Photos and motion photo support, plus a web app that is fast and pleasant.
• The community and the project health. This is not abandonware. There is a new release every month, an honest public roadmap, and an issue tracker where maintainers reply to feature requests in hours, not months.

What is still missing for families (the honest gap)

Here is the part I promised to research deeply, because it is the difference between "Immich replaced Google Photos for a power user" and "Immich replaced Google Photos for a family." I read the official docs, the roadmap, the flagship sharing issue, and a widely-shared discussion from a family user, and the picture is consistent.

One user, one library

Immich's core model is one user per library. Each account has its own timeline, its own faces, its own memories. The partner sharing feature lets two users see each other's entire libraries, and shared albums let users contribute to albums together, but neither creates what a family actually wants: one shared archive where everyone's photos land in the same timeline.

Shared albums do not merge into the timeline, memories, or faces

This is the single most common complaint, and it is structural. When someone shares an album with you, you see an album. The photos do not appear in your main timeline, do not feed your "on this day" memories, and do not join your face library. The r/immich community puts it bluntly: family members lose memories and timeline continuity, because sharing albums does not give recipients any of that. The maintainers know, which is why the flagship sharing issue #12614, opened in September 2024, explicitly lists albums, partner sharing, library sharing and asset data as the things a better sharing model must cover, and the roadmap lists "better sharing" and "user groups" as Soon.

External libraries are owned by one user

A family NAS folder full of trips and old scans cannot be scanned once and shared as a common pool. An external library must be assigned to one specific user, and there is no shared root that multiple accounts can reference. The GitHub discussion "A Family User's Perspective: Why Immich is currently painful for household use" calls this out as the first deal-breaker, and it is a fair point.

No user groups yet

You cannot create a group called "Family" and share an album with the group in one click. User groups are on the official roadmap as Soon, but right now sharing is per-user, which becomes tedious the moment you have more than two or three accounts.

Faces stay per-user

Face recognition clusters are computed per account and are not shared. If you tag your child's face on your account, the same face on your partner's account is a separate, unnamed cluster. Partner sharing does not fix this today; the roadmap's "better sharing" item explicitly calls out sharing facial recognition data as part of the work.

Storage templates are global, not per-library

There is one global storage template for the whole instance. You cannot have "phone backups go into YYYY/MM/DD" while "professional camera folders keep their original structure." The family-user discussion lists this as pain point two. It is cosmetic in some ways, but it matters when multiple people with different workflows share one server.

Semantic search is good, not Google-scale

The CLIP-based search is impressive for self-hosted software, but complex natural language queries like "kids running on grass in red shirts" still produce weaker results than Google Photos. This is an arms race where Google has a head start measured in years of cloud-scale data.

iCloud imports can scramble your timeline

Photos exported from iCloud often lose their Date Taken EXIF data, and Immich falls back to file creation date, which produces a jumbled timeline. The fix is to import iCloud libraries with immich-go or icloudpd rather than a raw folder dump, and to use the metadata editor for stragglers. It is a real migration gotcha, especially for households coming from Apple.

The team behind it has earned the praise

Immich is one of the best-run open source projects I have followed, and the pace is the evidence. The project started in 2022, crossed 250 contributors in early 2024, and in May 2024 joined FUTO so the core team could work on it full time. Since then it has been a steady stream: v2.0.0 stable in October 2025 with no breaking changes from the 1.x line, then v2.2 with OCR, v2.3 with delete sync, v2.5 with free-up-space and in-app database backup and restore, v2.7 with default CSP hardening, v3.0 with workflows, HLS streaming and a non-destructive mobile editor, and v3.1.0 in July 2026. The project passed 100,000 GitHub stars in May 2026 and sits at 110,000 now, with 10,000 commits on the board.

What makes this remarkable is that the rapid shipping did not come with feature-freeze drama. When the maintainers hit the sharing architecture problem, they did the mature thing: they froze sharing changes, opened a placeholder issue, and said they would design it properly rather than bolt on more half-features. That is exactly how you keep a project healthy over years, and it is why I trust the family features will eventually land even though they are not here yet.

I keep an eye on the releases the same way I track every piece of my stack, using the release-tracking workflow I wrote about, and pin the compose image tag instead of chasing latest.

Privacy: data stays yours

This is the whole point, so let me be precise about what "yours" means. Immich is AGPLv3 and self-hosted, so the server software and your data live on hardware you control. Facial recognition, object detection, CLIP embeddings and OCR all run through the local machine learning container; no photo bytes and no derived face vectors leave your network unless you send them somewhere yourself. There is no telemetry pipeline feeding your family archive into a product-improvement program, which is a categorical difference from the cloud alternative.

The practical consequence: your originals are ordinary files in a directory you can reach with rsync, SCP or a file manager, and your entire library is portable by definition. Leaving Immich is a copy operation, not a Takeout export with missing metadata and an unwieldy zip.

What it actually costs

The numbers below are the recurring monthly picture as I ran it. Google's prices are from the official plan page checked in August 2026 and vary by region. The hardware figures are honest estimates for a mini PC plus two drives amortized over a few years, because the exact number depends on what you already own.

The honest takeaway: at 100 GB you pay about the same as Google's Basic tier, but you get an unlimited-size local library, your originals uncompressed, and no per-gigabyte ceiling. At the 2 TB scale where a family actually lives, you are paying roughly a quarter of Google's price for hardware you own and can keep using for years.

Who should switch, and who should not

Switch if: you are comfortable running Docker containers and doing basic maintenance; you want originals kept uncompressed on your own hardware; the privacy trade matters more than a perfect family library; or you are already self-hosting other services and this is just another container.

Wait if: you are a household of four plus grandparents who all need one merged timeline today; you cannot or will not maintain a server; you rely on Google-scale semantic search; or you expect a one-click Google Photos replacement with zero rough edges. The family gap section above is your checklist, and the roadmap tells you what is coming.

The verdict after 90 days

Ninety days in, I am not going back. The cost went to near zero, the originals are mine in the most literal sense, the apps are fast, and the project is being built by people who demonstrably care and demonstrably ship. For a single user or a couple using partner sharing, Immich already replaces Google Photos with room to spare.

For a full family, it is close but not there yet. The one-user-one-library model, the missing user groups, and the albums-that-do-not-merge problem are real limitations, and I have not papered over them here. The difference is that these are known, tracked, roadmap-level problems in a project that has shipped a stable release every month for years, rather than permanent gaps in a closed product. That is the bet I am making with my family's photos, and after 90 days I am comfortable with it.

Are you on Google One, or have you made the move to Immich? How are you handling the family library problem. Drop your setup in the comments.

Until next time, keep your systems thoughtful.