Taking control: self-hosting my photo library with Immich

After years of relying on Google Photos, I've finally moved my whole photo collection onto hardware I own. I deployed Immich on my home server in February 2026, a few months after building the server itself, and this is why I did it and how it went.

Why self-host

The motivation is simple: independence from big tech. Google Photos has been convenient, but I've grown increasingly keen to own my media outright.

In late 2025 I built a home NAS and installed Jellyfin on it, a media server that now hosts all of our films and family videos. That build was the start of an effort to become more self-reliant whilst still keeping cloud backups of everything.

With those backups already in place, disaster recovery wasn't a worry. My raw photos from camera SD cards were already sorted into a structured set of folders, so it made sense to build on that rather than keep depending on an outside service.

Enter Immich

Immich is an open-source, self-hosted photo and video manager that sets out to be a genuine alternative to Google Photos. The features I'd actually miss from Google are there, facial recognition and smart search included, and the phone app backs up automatically in the background.

It has also grown up quickly. Immich declared its first stable release, v2.0, in October 2025, a few months before I installed it, and v3 followed in July 2026.

Being open source matters to me as well. If something doesn't work the way I want, I can at least read the code, and in theory send a fix. There's no lock-in either, because the originals sit on my own disks in a folder structure I chose.

The setup

I installed Immich on the TrueNAS box as a custom Docker Compose stack rather than the app from the TrueNAS catalog. The official compose file runs four containers:

• immich-server for the API, the web app and the background jobs. Older guides show a separate microservices container, but that was folded into the server in 2024.
• immich-machine-learning for facial recognition and smart search.
• Postgres with the VectorChord extension, which holds the metadata and the vector embeddings that smart search queries.
• Valkey, the Redis-compatible store Immich uses as its job queue. (The compose service is still called redis, just to keep you on your toes.)

I set up external libraries pointing at my existing photo folders on the server, so Immich could index the collection without moving or duplicating thousands of files.

The main challenge was getting permissions right on TrueNAS. I won't bore you with the details, but if you're heading the same way, read Immich's TrueNAS guide first. It's written for the catalog app, and its notes on dataset ownership and ACL modes apply just as much to a custom stack.

Immich isn't exposed to the public internet. Everything that talks to it, phones included, reaches it over Tailscale, the same as the rest of the NAS.

Folders and albums

The one thing I really wanted when I started was automatic albums built from the folder structure of an external library. Point Immich at a carefully organised collection and it indexes every photo, but none of those folders turn into albums.

Immich has since added a folder view, which lets you browse a library much like a file explorer. You turn it on under Account Settings, then Features, then Folders. It isn't the same as albums, but for a curated external library it gets you most of the way.

For actual albums I ran Salvoxia's immich-folder-album-creator, a Python script that creates an album per folder through the Immich API. It worked, which is more than I can say for my first attempt at the ACLs.

Rule-based albums are still on the roadmap as "Smart albums", marked Soon™. In the meantime v3 shipped a preview of Workflows, a drag-and-drop automation builder for the library. It's early, but it's heading towards the thing I originally wanted.

Importing Google Takeout

The bigger job was getting everything out of Google Photos. Years of phone uploads and shared albums lived in Google's ecosystem, and Google Takeout hands them back as a pile of zip files, with each photo's metadata split out into a separate JSON file.

I used immich-go for the import. It reads the Takeout archives directly, matches each photo with its JSON metadata and uploads through the Immich API, so there's no unzipping and no fixing dates by hand. You'll need an API key from your Immich account settings first:

immich-go upload from-google-photos \
  --server=http://your-nas:2283 \
  --api-key=YOUR_API_KEY \
  --dry-run \
  /path/to/takeout-*.zip

The --dry-run flag reports what would be uploaded without sending anything, so run that first and drop the flag for the real thing. Album syncing is on by default (--sync-albums), which means your Google albums come across as Immich albums.

As an iPhone owner, most of my photos existed in both Google Photos and Apple Photos, and there was plenty of accumulated junk too: screenshots, receipts, photos people had sent me on WhatsApp. You know how it is.

That's where the duplicates utility earns its place. Immich uses machine learning to group photos that look the same, then lets you review each group and choose what to keep. When you keep one, it carries the albums and favourites over from the copies you bin.

Partner sharing is worth knowing about as well. It shows a partner's photos in your own timeline without copying anything between accounts.

Final thoughts

Self-hosting isn't for everyone. It takes some technical knowledge and some hardware, plus maintenance that never quite ends. But if you care about owning your data, Immich makes it a realistic option, and keeping the server as the source of truth (rather than one more copy) is an ongoing micro-project of its own.

If you're considering a similar move, give Immich a try. Eight months in, my photos live on disks in my own house, and the backups are mine to manage.