Immich
💡 Quick Navigation
Immich is my main phone-photo backup system and family photo hub. I do not think of it as just a self-hosted Google Photos clone. Its real job is to bring daily photos, videos, and memories back into storage I control.
In this Home Lab, Immich is one of the few services I choose to run on TrueNAS. The reason is practical: photos and videos are large, thumbnail and machine-learning jobs use CPU / iGPU resources, and the data already lives on the NAS. Keeping the service close to the data is more stable than pushing large media workloads through cross-host mounts.
🎯 Why I Use It
I do not want all photos locked into commercial cloud services
Phone photos are some of the most important data I have, and they also grow quietly over time. Google Photos and iCloud are convenient, but long-term use creates several tradeoffs:
- Storage cost increases with family members and years of photos
- Large exports are not always smooth
- Photos, videos, and metadata are not fully under my control
- Each family member backs up separately, making the overall state harder to audit
Immich solves the simple but important workflow: after a phone takes a photo, that photo automatically comes home. Once the data lands in my own storage, I can decide how it is backed up, retained, and organized.
It reduces phone storage anxiety
The biggest daily benefit is lower phone storage pressure. Photos upload automatically, and I can browse them later through a timeline without keeping every file on the phone itself.
This does not need to fully replace the phone gallery app. The goal is to make sure the phone is no longer the only copy.
🧱 Why It Runs on TrueNAS
Most of my Home Lab services run on OMV as the application layer. Immich is one of the exceptions.
flowchart TD P[Phone / Tablet] --> RP[Reverse Proxy / HTTPS] RP --> IM[Immich<br/>TrueNAS] IM --> DB[(Database / Metadata)] IM --> ML[Thumbnail / ML Jobs] IM --> DATA[(RaidZ2/DataPool/Immich)] DATA --> BK[OMV Backup Target]
Main reasons
| Consideration | Why TrueNAS makes sense |
|---|---|
| Data locality | Original photos and videos live directly on the NAS dataset, avoiding heavy media I/O over NFS |
| Thumbnail and video processing | Immich performs thumbnail, transcoding, and machine-learning related work, which benefits from stronger local hardware |
| Long-term capacity | Photo data grows continuously, so keeping it on the main ZFS pool fits better with snapshots and capacity planning |
| Operational boundary | Immich stores family core data, not just disposable app cache |
The result is a slightly more nuanced rule: most services run on OMV; services that need to stay close to data or hardware resources run on TrueNAS.
📱 How I Actually Use It
Immich currently has a simple role:
- Automatically back up phone photos to home storage
- Serve as the family photo hub
- Browse old photos through a timeline
- Centralize photos and videos uploaded by family phones
I do not treat Immich as a one-time project to organize every historical photo at once. I first make sure new daily photos upload reliably. Once that workflow is stable, old imports, albums, and people organization can be improved gradually without turning the setup into a huge migration project.
Usage experience
| Area | Practical result |
|---|---|
| Phone backup | Automatic upload reduces the risk of phone loss or local storage pressure |
| Photo browsing | Timeline browsing is intuitive for finding recent photos |
| Family use | Centralized family media is easier to manage than photos scattered across phones and cloud accounts |
| Operations | Storage and backup planning need to happen early, otherwise the service gets harder to move later |
💽 Storage and Data Planning
The most important part of Immich is not the web UI or mobile app. It is data planning.
The main Immich data lives in the TrueNAS data pool:
RaidZ2/DataPool/ImmichThis dataset is long-term preserved data and should not be treated the same as disposable cache. Immich data falls into three broad groups:
| Data type | Importance | Notes |
|---|---|---|
| Original photos / videos | Highest | Core uploaded data from phones. If lost, it cannot be rebuilt |
| Database / metadata | Highest | Albums, users, upload state, and asset relationships depend on the DB |
| Thumbnails / cache | Medium | Rebuildable, but rebuilding costs time and CPU |
Important
Backing up only the photo files is not a complete Immich backup. The database and the relationship between uploaded files and application state matter too. If they are restored from mismatched points in time, the files may exist but the application state can be inconsistent.
🔁 Backup and Risk Control
Immich is one of the services I prioritize for backup because it stores family memories, not a disposable utility.
My overall backup direction is:
- TrueNAS holds the primary data
- OMV acts as an independent backup landing zone
- Important data is synced on a schedule to the OMV backup drive
- Before service updates, I confirm there is a rollback-capable data state
What I pay attention to
- Original media needs a second copy: a single pool is not enough.
- Database and files need to be protected together: if their restore points are too far apart, recovery gets messy.
- Restore drills matter: a backup that has never been restored is only potentially useful.
- Sync is not backup: phone auto-upload is ingestion, not redundancy.
What I avoid
- I do not make Immich the only place where photos exist
- I do not import a huge historical library before backup is in place
- I do not blindly update core services with
latest - I do not only check whether containers started; I also verify the app, DB, upload flow, and browsing path
⚠️ Pitfalls I Ran Into
Capacity grows faster than expected
Photo services make capacity easy to underestimate. A single phone may look manageable at first, but videos, Live Photos, multiple family members, and historical imports quickly change the numbers.
Before bringing Immich fully online, I think through:
- How much photo and video data is created per year?
- How much will family members multiply that growth?
- How long can the pool capacity last?
- Does the backup target have enough space too?
Plan first, then invite family members
Once family members use Immich, it is no longer just a personal lab service. Updates, downtime, and failed backups can affect other people.
The safer approach is to run it with my own phone first, confirm upload, backup, update, and restore workflows, then invite family members after the basics are stable.
A photo service is more than an app folder
For many services, keeping the config directory is enough to rebuild. Immich needs a broader view:
- app data
- upload library
- database
- thumbnails / generated files
- machine-learning indexes or metadata
These parts do not have equal importance, and the backup strategy should not treat them all the same way.
⬆️ Upgrade and Maintenance Principles
Immich moves quickly. That is good for features, but it also means upgrades deserve care.
My upgrade rules:
- Read the release notes first, especially breaking changes, DB migrations, and mobile-app compatibility.
- Confirm backup state before updating, and take an extra snapshot when needed.
- Upgrade only Immich-related services in one maintenance window, not multiple core services at the same time.
- After the update, check login, timeline, upload, thumbnails, video playback, and background jobs.
- Keep the previous image tag or a rollback-capable state so a failed upgrade does not become emergency surgery.
Routine checks
- Phone uploads are still running
- Disk growth matches expectations
- Backup jobs are succeeding
- Database / metadata is included in backup scope
- Thumbnails and background jobs are not stuck
- Family members are not seeing login or sync problems
Conclusion
Immich is one of the most practical services in my Home Lab. It is not just a technical demo. It helps bring phone photos home every day, reduces phone storage anxiety, and keeps the family photo library from depending entirely on commercial cloud services.
But it is also not a service to deploy casually. The real work is deciding where the data lives, how it is backed up, how it is restored, and who is affected once family members start using it.
Further reading: Home Lab Overview, TrueNAS, OpenMediaVault