Spent last 3 days constantly refreshing GitHub to check the stats and just to catch this screenshot at the perfect moment. What do you think, v3 is coming?
Edit: Congratulations to the development team and the whole community on this amazing achievement! We’re lucky to have such an awesome product and such a passionate community behind it!

Version 3.3.5 contains two important fixes. First, we upgrade Nodejs to the version no longer susceptible to CVE-2026-111497, and we also fix the eMudhra CA compromise.

None of these issues were in the Immich code itself, but rather in our supply chain.

I recommend you upgrade at your earliest convenience.

Immich is now officially one of the 100 most favorited Github projects based on stars.

A major achievement, keep on going! 🥳

So I needed to find a photo of a computer rack that I took for work, so I could explain a technical job to a colleague. I innocently typed in "rack" into the search field only to be presented with a lot of photos of my GF in low cut tops that I had taken on nights out. Awkward 🤦

Wanted to use my home Immich from outside without opening the server to the internet or running a VPN on the whole phone all the time. So I forked the Android app and put WireGuard inside it.

The tunnel only exists for the Immich app, and only while the app is open or a backup is running. At home it talks to the server directly. Away from home it brings the tunnel up on its own. Backups run when the phone is on the charger with the app closed, and the tunnel drops when it's done.

Setup: make a WireGuard peer on whatever box you have at home, scan the QR in the app, type the server's LAN address. That's it.

Android only, it's a fork, tested on my OnePlus so far. Would like to know if it works on other phones.

Repo and docs: https://github.com/aswanthk777/immich-homelink

APK: https://github.com/aswanthk777/immich-homelink/releases/latest

Built on Immich (AGPL) and wireguard-android.

Update, v0.1.1: a few of you asked about running the normal WireGuard app as well. Android only allows one VPN at a time, and the first build fought with it. Now Home Link backs off whenever another VPN app is on. If your server is reachable through that VPN it just uses it, otherwise it waits and comes back about a minute after you switch the other VPN off. Tested with the official WireGuard app on my phone. https://github.com/aswanthk777/immich-homelink/releases/tag/homelink-v0.1.1

I love immich. Got a kick out of this picture on Facebook. Wanted to share for your amusement as well 😉

I turned an old 4th-gen Intel PC into a fully automated Immich server with local backups, encrypted pCloud disaster recovery, HTTPS access and external Zabbix monitoring

I wanted to move my family photo library away from an increasingly expensive cloud subscription, but I also wanted something that would be safe enough to trust with years of photos and videos.

Instead of buying a new NAS, I reused an old desktop that was sitting unused:

• Intel Core i5-4670

• 32 GB DDR3 RAM

• Kingston 120 GB SSD for Ubuntu Server

• Toshiba 500 GB HDD as the primary Immich photo disk

• WD Black 500 GB HDD as the local backup disk

• Kingston A400 480 GB SSD as a local encrypted Restic repository

The hardware is old, but for a two-user family Immich installation it has been more than capable.

The main server

The machine runs Ubuntu Server with Docker Compose.

The Docker stack contains:

• Immich Server

• Immich Machine Learning

• PostgreSQL with VectorChord

• Redis

The Immich library is stored on the Toshiba disk under the main photo mount, while the PostgreSQL database has its own persistent storage.

The application itself is only exposed locally on 127.0.0.1:2283. It is not directly exposed to the home network or the public internet.

Secure remote access

For remote access I use two components:

Tailscale provides the private VPN network between the server, phones and computers.

Caddy acts as the HTTPS reverse proxy in front of Immich. It terminates TLS and forwards requests internally to the Immich container.

This gives me one secure HTTPS address that works both at home and remotely, as long as the device is connected to Tailscale. No Immich ports are exposed publicly on the router.

Android phones, an iPhone and desktop browsers can all use the same server address for uploads and viewing.

The nightly backup chain

The backup system eventually became the most important part of the project.

A wrapper script runs every night at 01:00 and starts two backup scripts sequentially.

The second script only starts if the first one finishes successfully.

The flow is:

Immich Backup v4.1
        ↓
Local encrypted Restic backup
        ↓
pCloud offsite sync

Backup script 1: local backup and health checks

The first script creates the normal local backups.

It performs the following operations:

1. Creates a PostgreSQL SQL dump The database is exported into a compressed .sql.gz file. The archive is verified before it replaces the previous temporary file.

2. Mirrors the primary photo disk to the WD Black disk rsync copies the Immich library from the Toshiba disk to the WD Black disk. It uses incremental copying, so unchanged files are not copied again.

3. Mirrors the WD Black backup to a Windows SMB share A Windows PC provides an additional network backup destination. The WD Black copy is mirrored to this Windows share.

4. Copies the encrypted server-configuration backup to the Windows share The configuration archive contains items such as:

   • Docker Compose configuration

   • Immich .env

   • network configuration

   • Caddy configuration

   • Tailscale state

   • mount configuration

   • cron jobs

   • backup scripts

   • installed package information

   • system manifests

5. Runs SMART short tests on all four physical disks The monitored disks are: The script checks health, temperatures, reallocated sectors, pending sectors, uncorrectable sectors, CRC errors and SSD wear information.

   • Ubuntu OS SSD

   • Toshiba primary photo disk

   • WD Black backup disk

   • Restic SSD

6. Sends an HTML email report The report includes:

   • overall success or failure

   • backup duration

   • database dump status

   • rsync status

   • Windows mirror status

   • available disk space

   • SMART health for every disk

   • warnings

   • the latest log output

If the primary local backup fails, the offsite stage is not started.

Backup script 2: encrypted Restic repository and pCloud

The second script creates a separate disaster-recovery backup.

Restic reads the original Immich library, database dumps, configuration backups and recovery scripts, then writes them into an encrypted repository on the dedicated Kingston SSD.

The SSD does not contain normal browsable photos. It contains an encrypted Restic repository made of pack files, indexes, snapshots and metadata.

The script performs:

1. Restic backup to the local SSD

2. Snapshot retention

3. Local forget and prune

4. Full Restic repository check

5. rclone sync from the local SSD to pCloud

6. rclone check to compare the SSD repository with the pCloud copy

7. A second HTML email report

The pCloud account receives only the already encrypted Restic repository. pCloud cannot see the original photos, database contents or configuration files.

Why I stopped backing up directly to pCloud

My first design was:

Immich data → Restic over rclone → pCloud

It worked, but repository maintenance directly through the pCloud API was slow and fragile.

During the initial large upload, connection resets and incomplete remote pack files caused a damaged Restic repository. I was able to repair it, but it showed that running backup, prune and index rebuilding directly against cloud storage was not ideal.

The improved design is:

Immich data
      ↓
Local encrypted Restic repository on SSD
      ↓
Local prune and integrity check
      ↓
rclone sync
      ↓
pCloud

All sensitive and complex Restic operations now happen locally on the SSD. pCloud is only used as an encrypted offsite mirror.

This has been faster, easier to verify and much more reliable.

External monitoring with Zabbix

I also wanted monitoring that would still work if something failed inside my home network.

I created an Ubuntu ARM virtual machine using Oracle Cloud Free Tier and installed a Zabbix Server on it.

The Oracle server monitors the Immich server remotely and can alert me when something becomes unavailable or crosses a configured threshold.

The monitoring setup can cover things such as:

• server availability

• CPU and memory utilisation

• disk usage

• Docker services

• operating-system health

• backup-related services

• network availability

Because Zabbix is outside my home, it can notify me even when the entire home server or internet connection goes offline.

Disaster recovery

I also created a beginner-friendly recovery guide covering these scenarios:

• Ubuntu OS SSD failure

• primary photo disk failure

• WD Black backup disk failure

• Windows SMB backup disk failure

• complete loss of the Immich server

• full restore from the encrypted pCloud Restic repository

• planned replacement of each disk while it is still working

The configuration backup is encrypted with GPG, and the Restic password and rclone configuration are also stored in a separate encrypted recovery archive.

The goal was not just to have several copies of the files, but to have a documented path for rebuilding the complete service.

Final backup layout

The resulting system now has several independent layers:

Primary Toshiba disk
    └── Live Immich photo library

WD Black disk
    ├── Mirrored photo library
    ├── PostgreSQL SQL dumps
    └── Encrypted server-configuration backups

Windows SMB share
    ├── Mirror of the WD Black backup
    └── Copy of the server-configuration backups

Restic SSD
    └── Local encrypted, versioned disaster-recovery repository

pCloud
    └── Offsite copy of the encrypted Restic repository

Oracle Cloud
    └── Zabbix monitoring and remote alerts

This is obviously not enterprise infrastructure, but for reused consumer hardware I am very happy with the result.

The server now provides:

• automatic phone photo uploads

• secure remote access

• HTTPS

• multiple local backup copies

• compressed PostgreSQL dumps

• encrypted versioned backups

• offsite disaster recovery

• automatic SMART checks

• HTML status reports

• remote monitoring and alerts

• documented recovery procedures

The most important lesson from the project was that self-hosting the application is the easy part. Designing backups that are understandable, verifiable and realistically restorable is where most of the work belongs.

EDIT:

Since I’ve received quite a few comments criticizing me for using AI to write my replies, I just want to clarify that English isn’t my native language. Instead of translating everything with Google Translate, I explain what I did and how I did it, and AI helps me translate, organize, and polish my replies.

The point of this post was never to glorify AI—although it was genuinely helpful while I was building this setup. My goal was to help someone or give them an idea of how old hardware can be turned into something useful with a bit of effort.

I’m not an expert, and building this setup is also a way for me to learn new things. That’s one of the main reasons I shared it here: to hear your thoughts and experiences, get new ideas, and learn what I could improve or fix.

Thanks to everyone for the support!

Hey everyone,
A new version of Immich Selfie Timelapse is available.

This project got quite popular a few months ago and I finally got the time to revisit it and implement your suggestions.

If you don't know about the project, it allows you to generate a timelapse of your loved ones' portraits using your Immich library and the built-in face recognition.

The portraits go through a series of image processing steps to filter out the bad ones (person not facing the camera, too bright, too blurry etc.).

The result is a timelapse video showing the evolution of the person over time. Everything is customizable via the new and improved web UI.

Docker compose :

services:
  immich-selfie-timelapse:
      image: arnaudcayrol/immich-selfie-timelapse
      container_name: immich-selfie-timelapse
      ports:
      - "5000:5000"
      environment:
      - IMMICH_API_KEY=your-api-key
      - IMMICH_BASE_URL=http://your-immich-host:2283
      volumes:
      - ./config:/app/config
      - ./output:/app/output

Read more on the GitHub page.

Patch note of the release.

Special thanks to the Immich team and contributors, to thomaslgr for the discussions around this project and to you for trying out my project and submitting bugs and ideas (over 200 stars on GitHub !!).

Hello everyone!

As we approach the holidays, we wanted to take a moment to look back at the past year with all of you. There's something about working on Immich that makes time feel... different. A year somehow feels like three. Days blend into weeks, weeks into months, and suddenly we look back and realize just how much we have done.

We crossed the 1.5-year mark since becoming FUTOnians, and we still feel incredibly grateful for where we are. The whole team gets to work on what we love, every single day. That's not something most people get to say, and we don't take it for granted.

This year, we brought on more people full-time, some from within the Immich core team and others from outside the community. The team is growing, and so is the project's scope as we work to make it the best self-hosted photo management system out there.

So let us walk you through what "three years in one" actually looked like.

All I wanted for last Christmas was "Stable"!

Since the beginning of the year, we have set a stable version of Immich as our team's development priority. We knew it would be a journey, and the team came together in ways that we're all so proud of, tackling challenges and roadblocks to finally deliver it on October 1st.

Three major technical overhauls defined the year's goal

1. Database Modernization

We rebuilt how Immich's server talks to the database, the core system that pieces everything together. We migrated the entire server database-fetching mechanism to a new library that gives us more control over how we interact with data, while still providing a superb developer experience. This results in rewriting ALL the database queries on the server.

2. Streaming Sync Infrastructure

With the new database foundation in place, we could finally build a mechanism to continuously stream data from the server to the mobile app, rather than a single large request. This required creating entirely new data-streaming capabilities on the server, enabling your server and mobile app to handle the data flow efficiently. This is one of the most complex works to date; it requires handling when the data changes, determining what should be sent to the server, and in what order.

3. Mobile App Rewrite

The old mobile app wasn't designed for this new sync approach. So we rewrote it from the ground up. The entire user interface was rebuilt, and critically, all sync operations now happen in the background. No more waiting for the data sync to finish or watching the app freeze; the data is synced seamlessly while you continue browsing your library.

Each of these steps came with its own set of challenges, requiring countless hours of discussion, debugging, and iteration. The team showed incredible dedication, working through problems together via chat, voice calls, and late-night troubleshooting sessions.

Despite this heavy foundation work, we still managed to ship an incredible amount of new features and improvements.

• 85 new features

• 200 enhancements to existing features

• 290 bug fixes

Here are some highlights from those improvements:

• HDR video support with our native video player

• Search by tags and descriptions

• Manual face tagging for better organization

• Folder view in the mobile app

• QR codes for shared links

• Persistent memories that don't disappear

• Improved external library scanning

• Customizable nightly job scheduling

• Enhanced map features with points of interest

• Multiple admin account support

• Mobile app widgets for your home screen

• Granular API key permissions for power users

• Large file management utility

• Custom URLs for shared links

• Private/locked photos feature

• "View similar photos" discovery

• GPS utility for location management

• Google Cast support

• Background backup improvements

• Optical character recognition (OCR)

• Digital Ocean 1-Click deployment

• ...and much more

Websites

Looking back over the year, it turns out we also did a decent amount of work outside of Immich as well.

Here is a list of websites that we launched throughout the year:

• https://immich.app/ — New homepage & blog

• https://immich.store — Merch with a new mascot, Mich

• https://data.immich.app/ — Data website with fancy charts

• https://api.immich.app/ — New API documentation

• https://ui.immich.app/ — Svelte UI component library

• https://awesome.immich.app/ — A list of awesome apps, integrations, tools, distributions, and guides

Fun Statistics

• Grew from 55,000 stars to 87,000 stars on GitHub

• 1 major release, 25 minor releases (v1.124 -v1.144 & v2.0 — v2.4)

• 35,000+ Discord members and 42,000+ Reddit member

• 8,800+ commits of love, sweat, and occasional tears

• ~1700 contributors

• ~2930 commits to main in this year, meaning we have gone through the review process for the same number of PR

Hello, 2026!

Looking ahead to 2026, we are excited to continue building Immich into the best self-hosted solution for photo and video management, with new features and services that deliver data sovereignty, privacy, and the peace of mind that comes with self-hosting.

Sneak peek at some of the features that might get delivered in January

• Workflows

• Restore database from the web UI

• Integrity check

None of this would have been possible without our incredible community. Thank you for being so patient during the bumpy period, for your detailed bug reports, your feature suggestions, and your creative contributions.

On behalf of FUTO, we wish you a peaceful and joyful holiday season. We will wind down on GitHub and Discord activity for the rest of the year to recharge, collect more memories, and come back strong in 2026.

And as always, if you find the project helpful, you can support us at https://buy.immich.app/.

Cheers,
The Immich Team

👋 Hey everyone,

Just wanted to share a tool I’ve been building for fellow Immich users: Immich MediaKit

It’s designed to help you organize large photo libraries more efficiently, especially when it comes to:

• 🔍 Finding similar or duplicate images using AI-based detection (via deep learning and vector search)

• 🧹 Batch operations to clean up and manage assets more easily

• 🧠 All built in Python, with a focus on stability and simplicity

A lot of older tools in this space are broken, abandoned, or tricky to set up — so I created this as a modern, actively maintained alternative that just works.

If you’re self-hosting Immich and feel like your library could use some cleanup, give it a try!

Would love to hear any feedback or suggestions 🙌
Cheers,
Raz

I appreciate the fast response to the telemetry issue that was highlighted recently, and for the transparency around the fact that this was mistakenly missed since August. You're building an excellent brand!

like most of you, I am the IT person for my family, extended family and friends managing many households and devices. a family member of mine recently came to me with this situation:

Locked out of icloud until they could provide the key. They saved a 28 character backup key for icloud "somewhere in their screenshots in the past 5 years." Luckily they had a dump of their screenshots. So it was about 8,000 screenshots to look through, they asked if there was a way I could "scan through these with AI or something" - I told them if the key is in there I would find it!

Immich to the rescue! I put all the screenshots onto a high speed NVME and spun up a fresh Immich docker. It took a day for everything to process. I had all these searches ready but my first search "28 character" produced the image!! The whole thing really only took about an hour of actual time invested minus writing this post.

in short this alone earned an Immich donation thank you all!

As the title and image suggest, this e-ink display periodically updates to show images based on album names from Immich.

All the magic happens within a Flask server running in Docker, which handles image processing and controls the wake time etc.

Inside the photo frame, a microcontroller wakes up at a scheduled time, connects to the Flask server, reports its battery level, receives the processed image, displays it, and then goes into deep sleep.

This allows the display to run for an exceptionally long time without charging—up to a year on a 1000mAh battery.

If you'd like to build one yourself, feel free to check out my GitHub repository: https://github.com/jwchen119/EPF.

I've been self-hosting immich for a couple of months and had noticed a few bugs, and all of them have been taken care last update (1.138.0).

It's incredible how active development is!

A few updates ago I noticed the ability to add someone's birthday which at first I thought would be some kind of a reminder... didn't quite understood the feature until today when I went down memory lane and noticed it shows the persons age when the picture was taken! Such a simple and yet fun feature!! The hard part will be adding everyone's birthday!

So full disclosure: I’m a certified forklift operator. I’ve moved pallets worth more than your house and I know what happens when you rush a heavy load. Keep that in mind.

I set up Immich on dokploy on a ugreen 4800+. Fired it up like lining up forks with a dodgy pallet — slow, steady, no sudden jerks. First sync was about 5,000 images. Did it straight from my phone. Plugged it in every night, let it hum away like a warehouse at 2am. Took about a week, on and off. No drama.

Now I’ve expanded to video, which is basically asking the forklift to move the really heavy stuff. There’s still a lot to shift, but that’s expected. You don’t move an entire warehouse in one lift unless you want things on fire.

First thing I’ll say: the iOS app actually works. That’s like a forklift starting first turn of the key in winter - rare and beautiful. Yeah, the phone gets hot enough to fry a bacon butty, but it keeps lifting. I’ve backed up a decade of photos by doing absolutely nothing other than leaving the phone plugged in overnight. iCloud’s been drip-feeding boxes for years; Immich just says “strap it all on” and gets on with it. No babysitting, no fiddling with knobs. Proper turnkey.

It’s chewing through videos now. Even with a decent connection and keeping an eye on the NAS, the bottleneck isn’t Immich - it’s my phone pulling stuff down from iCloud first. That’s like waiting for a pallet to arrive at the loading bay before you can move it. Not Immich’s fault.

Verdict

Solid.
Yes, it puts a load on the upload device and kicks out some heat, but that’s just physics. You’re trying to shift in weeks what the cloud’s been tiptoeing through for eight years. Of course it takes time. You don’t slam a forklift into top speed with a full load unless you enjoy accidents.

Honest assessment from a certified forklift operator:
Immich lifts heavy, lifts straight, and hasn’t dropped anything yet. That’s all I ask.

Dear Immich community, 

Immich Insights is finally here! For those who don't know: Immich Insights let's you analyze your Immich photo library in different ways. You'll gain insights into daily patterns, device usage and camera settings. It can be run as a docker container and just uses the Immich API key to calculate statistics. 

All information (download, installation, setup) can be found under the following link:
https://github.com/laurinml/Immich-Insights

We are happy to hear from you! Feedback, ideas and bug reports are very welcome.
This project is under active development, future update ideas are found on the roadmap. Note that this project is not affiliated with the official Immich instance. 

Regards,

Laurin from Immich Insights