Immich 3.0
github.com
github.com
> After months of hard work from the team and our amazing contributors, we're thrilled to announce the next major version of Immich: v3.0.0!
A quite amazing open source project, that COMPLETELY FAILS to explain to a newcomer what it is, what problem it solves, etc.
Actually, moving from Google Photos to Immich after I hit my 100GB storage limit was the whole reason I got into self-hosting, and what a fun ride that has been!
I can't believe self-hosted products of this caliber are free. Huge shout-out to HomeAssistant, PiHole, paperless-ngx, Dawarich, and countless others for the same reason.
Congrats to the team on the release and thank you for helping me catalogue my personal memories
Have you thought about backups and redundancy? I was thinking of hosting it on my homelab with backups on some cheap cloud storage but almost any cloud storage ends up costing somewhat similar to Google One so I've been a bit reluctant.
A good backup story is probably the only thing keeping me from switching.
Admittedly I have not set up backups yet because my homelab setup is not very mature.
I'm running everything off a single mini PC connected to a fresh 1TB SSD. My next "homelab goal" is setting up a NAS/DAS once I can snag something affordable off eBay/FB Marketplace/Kleinanzeigen/etc.
I think there are some super cheap cloud storage solutions where you pay a lot less in costs to not have on-demand access. That is the route I was going to go personally.
Hetzner community provides official full-disk encryption documentation:
https://community.hetzner.com/tutorials/install-debian-with-...
Letsencrypt gives free reliable SSL. You can easily hide Immich behind Nginx proxy that handles SSL for you.
Add cron based automated backup of the entire Immich data to a local encrypted NAS and there you go. Reliable, end-to-end, encrypted at rest setup. So far, it required exactly 0 maintenance.
It’s also more secure because I just drop traffic from all but 3 geographies at the IP level. And you can also add a WAP on the Nginx proxy.
It is also more more secure than Google/iCloude because the „employee of the company“ attack vector is much smaller. It’s documented that Google looks at your photos and is perfectly happy to file false police reports: https://www.eff.org/deeplinks/2022/08/googles-scans-private-...
By comparison, yes it is theoretically possible for Hetzner employees to access my server physically and extract the encryption key from RAM, or setup a fake SSH server to try to steal the key, but that is far more complicated attack and hasn’t been documented yet. And it risks detection.
It's not necessarily more secure than managed providers either, simply because you are probably not a security engineer, and have far less resources to secure your server. It does prevent Google/iCloud from scraping your data, but it certainly does not mean Hetzner can't access your data. They control the overarching hypervisor and control plane managing your servers/VM's, so there's no way to know what capabilities have been implemented. The majority of what intelligence agencies are capable of has not been leaked or documented publicly.
For 99.99% of the population, does the threat model really include targeted NSA attack with higher probability than „Google’s automated system sent the police to my door“? No, no it doesn’t.
It is demonstrably more secure for even a semi experienced sysop to host Immich for their family than for them to use Google/Apple.
But I do agree that _some_ experience is required.
And the Hetzner employee would need to specifically target me, because I doubt they would implement a dragnet that pierces through the bespoke random process on my bare metal server to scan the photos in memory.
That is a lot more secure than „Google scans all pictures routinely and fully automatically sends the police to your door, and you have no recourse if they are wrong“ that the EFF article discussed.
True E2EE would be that all data on those disks is encrypted by the client your family uses, so even if you combed through the disk volume you would only see cipher text
If you consider nuclear family as an entity, it’s e2ee. Practically.
Putting aside the fact that yes, the server can be compromised if somebody chose to attach to the live RAM and recover keys. But practically, nobody will. Same way Google will not deliver a special compromised image of the mobile app on my phone, even though they completely can.
This setup simply does fit the definition. And trying to say it is "e2ee practically" is a bit dishonest: there is no definition for "practical e2ee".
The point of e2ee is that you do not have to trust the server (see Bitwarden for instance).
Let's see e.g. Wikipedia:
> End-to-end encryption (E2EE) is a method of implementing a secure communication system where only the sender and intended recipient can read the messages
It is only about the sender and intended recipient. In this case, if they actually would self-host, the server and sending devices are in the same entity group and it is encrypted where it matters. In the case of Hetzner, it is not, because Hetzner can access the machines as they are not in the sender's or receivers basement.
But there are some other benefits with E2EE if going strictly with "client-to-client" model - if server is compromised by the bug, there is higher chance that then data gets stolen as plaintext.
The disks are fully encrypted, so the attacker must be careful not to accidentally interrupt power or force a reboot.
And they can’t just log into the machine, it is still a normal Linux machine with passwords.
So they need to attach to a running system and actively hack it, which is completely possible but is not going to be done by a random employee for no reason.
So what is different in saying „All family devices should see images taken by any device“? They are all clients, including the storage&processing device.
Insisting that E2EE have „ends“ on clients is not useful. It’s much better to define „end“ based on control.
I pay 60/month for 50 TB with a 10 year old intel xenon.
Lets say burglars break in and steal your homelab. Because you don't have e2ee, they can see all the photos you saved of your dead grandmother! Oh no!
Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that remain of your grandma - you just copy across the .jpgs to a new device.
I do go back and forth on the accessibility tradeoffs of E2EE for average people though. In this scenario, lose or forget your key/password and you lose ALL of your photos which are very important to some people. Losing them is pretty catastrophic. Google Photos or iPhotos really gives people a sense of security about their photos.
ps: It would also make it easier to host cloud instances for Immich without encrypting the file system of a remote server/VPS. Especially when renting servers from small-time sellers, I'm always weary about how much I can really trust their employees access control. I know some level of trust is unavoidable with physical access, but how do they handle those disks during maintenance would also be relevant.
1. "Hey just so you know, I have access to everything you upload here".
2. "Do NOT lose your password or your data will be GONE FOREVER and I CANNOT get it back".
I definitely prefer 1 and I'm sure my users do too. They shouldn't upload it if they didn't trust me anyway.
In my case I follow it up with "and I might actually go digging around in your files if I need to debug something or you're wasting disk space". But I think you could also follow it up with "but I do promise not to look" and that would be valid too.
This whole thing only makes sense for people you're pretty close to.
(I do tell people not to back up their password managers on my system though).
I guess maybe for Immich specifically it would be nice to have a "vault" feature where people can upload nudes etc where they are willing to trade risk of loss for privacy on a per-photo basis.
Now a use-case for E2EE is if you want to host it on a VPS, I would say. I wouldn't trust the VPS with the photos of my friends/family.
But ISTR reading Immich kinda assumes the storage is on a plain local filesystem so you get perf issues if you do something clever under its feet. Could be out of date on that.
I have a small vps which just tunnels into a laptop running at home.
Half of the features of immich would become 10x harder to implement if encryption needed to be done client side.
Agreed on the difficulty of implementing server side features though, especially all the things people expect from a Google Photos alternative.
This would force features like semantic search, face detection, video transcoding and thumbnail generation into the clients instead.
Immich assumes trusting the server to have access to your photos is fine. That is always the case when you’re self-hosting.
And I think that’s reasonable, since most users give that trust to Google and Apple.
IMO this is the single greatest problem with the selfhosted community; the idea that E2EE is only necessary for passwords and other highly sensitive PII. It should be standard for anything hosted on someone else's computer.
You might argue it's not neccessary for cat photos, but mistakes happen and you can accidentally upload things you don't intend to. You might argue it's not neccessary for games, ebooks or other copyrighted media, but the cloud provider could scan and delete anything you own that matches a hash of copyrighted material, at any time. You can accidentally paste a password, or other sensitive piece of text, into any text field of any website or application, and have it distributed to computers around the world.
E2EE can mitigate against numerous attack vectors, and reduces the surface area and blast radius of most attacks. That also applies to your own computers, if someone steals your hardware or hacks into your network. It is vital in the age of AI where all of your data could be exploited for training and profit, or used against you. The only data that should not be E2EE is situations where it is technically impossible, or the data is explicitly shared as "public" (e.g. the clearnet).
As long you understand the risks.
I'd rather have my family photos beying unencrypted than a very good possibilty of loosing them which happed more than once with other e2e things simply because I have no key to decrypt.
Then again - if I have to chose I'd rather have the at my home lab.
Are suggesting backing up decrypted data to an encrypted hard drive?
>better than most people.
Typically people who are so high on themself either too young or simply actually lack the understanding and usually it shows. But sure, most people out of 8 billion around the world have no idea about those things.
Anyway the whole point of my comment is:
- there is data I'm not willing and don't have to share - and it stays with me. Like family documents, photos etc.
There is no reason why E2EE services can't provide recovery or emergency access mechanisms, or implement plaintext export functionality from clients for storage elsewhere. Most reputable providers already have functionality to enable recovery and backup.
If they can do that then they are not e2ee.
1. Password manager gives you access to your secrets (key included), yes, but it does not eliminate human factor.
You may forget to add your key in the first place or you can delete a note with it without even realising that this was THE key.
This may seem like a fantasy, but if you ask people or search the web - this happens all the time.
2. Backups will be encrypted the same was as the original. So this wont's save you in case you have lost your keys.
Bottom line: the whole point of E2EE is a guarantee that only keyholders can ever access the data. Period. Lost key == Lost data. No exceptions.
I find it interesting to start with this, and follow with:
> There is no reason why E2EE services can't provide recovery or emergency access mechanisms
If the service can help you recover your data after you lose the key, it means that they have the key, and therefore it's not end-to-end encrypted.
That's the whole point of E2EE.
I don’t want to hold the keys to my photo library on someone else’s computer. I want to actually have all the bits and all the hardware in my house. I want to have access to it even if the Internet ends.
Like if you have to bring the data to your client device to do any kind of processing, you are quite bottlenecked when it comes to bulk operations (e.g. searching).
Sure there is very interesting research into managing that (homomorphic encryption), but I think it only makes sense on a Google cloud/apple scale. For a small, self-hosted app, I would much rather have my own hardware with FS-level encryption , or some kind of trusted compute as a whole. I don't think this has to be solved by an image host service.
Trusting the server, all the app in your phone has to do in the sliver of CPU time the OS gives it in the background is send it off to the server, where it can do compute-intensive things like transcoding video.
If you don’t trust the server, you’ll probably have to do these things while your app is in the foreground.
Sure, they’re useless without the keys. But the key is also useless without the blobs, in the sense that I don’t have my photos.
I also imagine that a true E2EE architecture means you have more flexibility with cloud storage, managed hosting, and off-site backups.
Still, good application design can help mitigate that. Apple does it with their e2ee recovery methods, although Ente does rely on a recovery key that you should print out and put in a safe as well as store in other safe locations.
But also, what I love about the E2EE of Ente is that I can securely use a cloud hosted provider but then my home NAS backups are unencrypted.
The Ente desktop app has a continuous export feature where I just leave the application on my main desktop computer and it constantly backs it up to my home NAS. It also does the local machine learning and video streaming encoding processing on the desktop.
So, if I lose my Ente account, no big deal. I get another one and wipe everything and restore from my NAS backup.
I feel like this is the best of all worlds. I get cloud convenience and no real self-hosting burden along with solid ownership of my data.
Perhaps Immich doesn’t bother with e2ee since it’s primarily designed for self-hosting, while for Ente it’s meant to be suitable for both a paid cloud service and self-hosting.
* Immich doesn't have end-to-end encryption, so I see it for self-hosting (i.e. on hardware I trust, typically at home).
* Ente has end-to-end encryption, which means I can host it on a random VPS.
Two different requirements for two different setups. E2EE adds some complexity, typically to set up a backup somewhere accessible. The fact that I have an unencrypted SDD next to my server at home that my family can grab and access photos is a feature to me: if I disappear I want them to be able to access them.
I trust GrapheneOS's security 10x more than my server. Why would I want encryption on messaging, if it's 'just for messaging my grandma'. My data is important to me and I want to keep it secure, even if I don't have a high threat model. E2ee should be the baseline, there's no reason to make security worse on purpose. Encryption in this case is important because it allows defense in depth, it allows others to know their photos are private when using my server and it prevents data access if someone has physical access.
Why trust two devices when one trust one device do trick?
> Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that remain of your grandma - you just copy across the .jpgs to a new device.
Yes, that's what happens when you lose your keys with e2ee. Every e2ee service is like this. Apple photos, Ente photos, Signal. If I couldn't manage a few words, why would I trust myself to manage a whole server?
To fully encrypt them would just be inviting more problems.
e2ee means that the encryption keys are stored client-side by the intended recipient. It's not just in transit and in rest.
I have a multi-region homelab cluster and I share some photos with my friends in the US and my parents in Russia. I’m auto-uploading full library (basically replacing iCloud/Google Photos) and I can share links to selected photos or albums (a reachable node will be determined by a split-view DNS). All without risks of exposing my full photo archive in case either node gets seized or otherwise compromised.
(Now, this is what I’m trying to do. I set things up, but it’s not really functional at the moment, because Ente is buggy af, and I haven’t yet learned how to rebuild and debug their iOS app.)
In the end who would want all my photos for that amount of work lol?
The people who care about this disproportionately collect distasteful media and would be in criminal proceedings if their material was uncovered.
If you have a server in your homelab where you self-host I mich just encrypt the hard drive with LUKS.
Maybe people have pornography production streams they want to manage using Immmich?
I think it's ridiculous to expect immich to rearchitect everything in order to make it better able to run on untrusted hardware. It should stick to doing what it is good at.
So... yeah, sure, e2ee and encryption and all that but don't wait on perfection when the otherwise situation is pretty dire. It's only encroaching BigTech fueled by surveillance capitalism even more!
It's cool they keep the server open and selfhostable instead of only open clients like many e2ee projects do.
I like how you can share an album and anyone can contribute to it without an account. Another cool feature is that you can select photos to lock when you hand your phone to somebody so they can only see the ones you selected without your device unlock.
If only. It can’t even upload photos any reliably (I self-host). I had it simply fail to upload anything for days (it doesn’t provide any diagnostics, gotta figure out how to build and debug it myself), with no apparent reason. That’s despite keeping app in the foreground, on a charger, for hours, with video uploads and ML features all disabled so it was supposed to focus on just the photos. Server side is fine, web-based uploads work without any issues, app just doesn’t. I haven’t figured it out yet.
Did you try it with the free 10GB on their hosted servers?
I'm using Android so maybe it's different on iOS.
"Ente Photos is a paid service, but we offer 10GB of free storage. You can also >>clone this repository and choose to self-host<<."
So both forms...
Ente Auth and Locker both seem like limited feature subsets of solutions like 1Password.
It's completely free and there's no lock in, so I suppose it's for getting more people hearing the name.
Haven't tried locker but I agree it seemed rather pointless.
People say not to use your pw manager for authenticator for security, so that's something for using a separate app. Depends if your using auth for just getting through or actually want the benefits.
Maybe it’s bad practice but I don’t mind 2FA being in 1Password because the secret key is the second form of authentication. Nobody can login to my 1Password without the secret key or access to a logged-in device. My credentials can be compromised and it wouldn’t matter.
The secret key is not technically “something you have” but it’s close enough for me.
They really are pretty much just what they appear to be. Im a fan.
Backups are easy too: you can very reasonably just rsync the library folder, and it'll be recoverable from that alone (I tried it! Worked great). You'll lose accounts and image-content search and iirc faces (possibly painful), but most of that is trivially rebuilt or not very interesting for single-person scenarios.
https://privacy.apple.com/account -> "Get a copy of your data"
Then you will need to chose the maximum size of an archive part and wait for link to a download page.
If you set the pref to keep originals locally, they're all on your drive, in original form, as well as the derived versions including caches of raw to jpeg, resolutions, and edited versions.
That said, Apple Photos does let you export even if only in cloud. Open the library, select all, and File > Export ... > Export Unmodified Originals.
It pauses for a second or two on my quarter million images, but is then happy to comply.
(I keep meaning to look at it and keep kicking it down the road.)
LLMs became so good that I don't trust a codebase like Immich to have ports to my server exposed publicly.
I put everything behind Wireguard to limit the number of lines of code that might bring down my setup.
Yes: it is necessary to share selected albums through public URL.
I have all of my photos organized like this: `events -> year/month - holiday -> (album_1, ...)`. and: `home town -> year -> (album_1, ...)`. Photos will be in multiple albums, and there will be edits as well. And I need to track the picked/rejected state as well (and filter on it).
Only reason I haven't moved over to Immich yet is because I am struggling to map my photo organization onto it's way of doing things in a way that's nice. So far my attempts have been unwieldy.
Anyone have experience with this? I haven't done much modification or album creation in photoprism, so am happy to start from scratch on that front.
But the way I do access Immich externally is not with Tailscale directly on my phone but involves exposing a caddy instance, running on a $1 VPS, to the internet.
If requests include a specific very long header (which I randomly made up), it then forwards those requests to my real Immich instance, which runs on my NAS. Headers can be configured within the mobile app. It has worked really well for me so far.
My phone has been powered on but inactive all night; I charged it to 80% before going to bed, then unplugged it and left it where I can reach it from my bed, as is my habit. (I'm in an Asian timezone, in case you hadn't guessed, so it's morning for me while it's evening in America right now). Its battery is now at 73%. The Android battery report says 6% battery usage from Kindle (makes sense, I started reading a book when I woke up), 0.7% from Signal (haven't sent any messages yet today but have received a few), and 0.3% from Tailscale.
So when you're not using the Tailscale network actively, you'll hardly notice the battery drain.
https://developers.cloudflare.com/tunnel/
It’s obviously not a magical security layer that eliminates all issues related to public Internet exposure, but in my opinion it is good enough for the average home user.
Unfortunately, Pihole was less important than Tailscale and I have to put up with mobile ads.
I just want to be able to organize my folders outside of some dumb library system and immich at the time fought that as well.
You say this as if it wasn’t Immich itself that backed up the database automatically next to your image files.
I think they’re one of the best self-hosted services when it comes to backup/restore — enabling it by default — and when it comes to migrations — no breaking changes in minor versions after 1.0.
Did you report this issue so I could try and reproduce it?
I ended up doing that manually, but it's great to see that is now a first class citizen in 3.0.0. I love Immich.
I've downloaded all the chunks once, only to find them corrupted due to... Their 50gb size and using a browser in theory. One also cannot seem to use wget or alternatives because of the auth / session cookies required via Google takeout.
I've yet to even broach the aspect of importing each giant bundle into immich because I've not had success in even grabbing the takeout files correctly, but would LOVE pointers on the best way of importing the roughly 700gb into the database without it ALL going wrong.
I've had great success with immich running in docker for the past year or so, although I have yet to upgrade to the newest version. Google photos backups have been disabled on my phone for a year or so, but I yet to haul in all of the past years.
Also, anyone know if I can get immich to upload the photos without... Running immich once in a while? Would be great if it just automatically sent them to "my cloud".
Great software.
In my setup, I exclusively use the external libraries feature, pointed at a read-only share from my NAS mounted onto my Immich server. (The external libraries are set to resynchronize to the database every few hours). This means I can manage all my media assets myself without worrying about Immich accidentally corrupting them, and if I eventually move off Immich, I just have a single folder of media files organized by date to port around.
The only downside is that I don't directly upload any media files directly to Immich, but that's okay. I have Syncopoli sync files from my phones (on a scheduled cadence) to an intermediary server which organizes and cleans exif data from media files before dropping it into its permanent home on my NAS share. No manual steps to get photos from my phone to my Immich instance!
Not really applicable if what you have is a google takeout dump. Better in that case to import all the photos and let immich handle them moving forward using a tool like https://github.com/simulot/immich-go
Its a bit of a trial, but quite doable. Its likely that things have improved since I did it about 6 months ago.
*Getting the files from takeout* I tried downloading the files onto my laptop via a browser, and then copying them over to my NAS, but quickly gave up. The best approach is to download them directly to the NAS. As you pointed out auth/cookies is an issue. There are multiple ways of solving the issue, but for me I found the best way was to use chromes dev console network view to identify the network request for each file, then right click on it and select "Copy cURL". SSH into my nas and use that command to download the file. There is a bit more info on how to do this here:
https://trog.qgl.org/20241001/downloading-a-google-takeout-f...
*Importing them into immich*
Once I had all my takeout files on the nas, I used immich-go to import them: https://github.com/simulot/immich-go
This took a bit of tweaking to get the right set of command line args that worked well for what I wanted it to do. I also found immich errored out a few times during the import. Fortunately immich-go can just pick up the import where it left of, so I kept re-running it until everything was imported.
*Cleaning it all up* If you just want a huge flat dump of your files your probably good. In my case there were various things I wasn't quite happy about. The default handling of stacking edited images with the originals in albums wasn't what I was after. I wanted to replicate sharing of albums with immich users to match what I had in google photos. For all this kind of cleanup work, I found it quite helpful to work with an AI agent. Give it an API key for your server + the url and get it to help you write cleanup scripts.
See the release note that this HN thread links to ;-)
>>> Background backup improvements Background backup on Android is now significantly more reliable. Previously, the background backup on Android was limited to newly taken photos. Now, the app uses a new periodic task scheduler, which allows you to upload your entire library in the background, and it plays nicer with Android's background execution limits, properly cleans up tasks, and warns you when battery optimization and notification settings might interfere with backups.
On iOS, the background refresh task now runs its sync and upload work in parallel, so uploads actually start within the short time window iOS allows.
I had ~200GiB. I selected below 10k files at a time to upload in the web UI (selected all 2014, then 2015). It was fine. More than that many and the UI became unusable.
External Libraries seem like a good option.
They have also recently improved the background import in the Android app so I have heard so that might be worth a try.
I know they were working on it, but haven't kept up, I just want to know if it works better now and I should try again.
> On iOS, the background refresh task now runs its sync and upload work in parallel, so uploads actually start within the short time window iOS allows.
But I don't know if that fixes your issue.
I don’t think this should be framed as iOS vs Android. From a technical perspective, I understand why the behavior differs. But from a user’s perspective, all they see is that one app works much better than the other.
My family doesn’t care about the technical reasons. They just saw one app finish much sooner than the other, and they preferred the one that worked better. Based on that experience, I can’t recommend Immich to them.
I could have done a data download from Apple but essentially leaving the Ente app open and choosing my albums to back up was a “set it and forget it” process.
They rely on immich-go project, which is ridden with bugs and basically abandonware by now. Their own iOS app, which can also be used for syncing iCloud gallery, has outstanding, 2 y/o or so bugs that will fail to upload the Live Motion photos.
My photos exported to Immigh have some 9000 broken, half imported Live Photos and I just don't have time to fix that.
The fact that THIS is not their priority, the most comprehensively A-B tested feature is beyond me. Who cares about OCR if you can't trust that they didn't butcher your imported memories? I just don't get it!
This is open source, volunteer developers often focus on doing things that are fun to them, or that scratch their own itch. I can't imagine dealing with Google Photos semi-broken exports is fun to anybody, and you only deal with the pain of the import once, afterwards there's no itch to scratch.
I set up immich backed by ceph last week and I got everything migrated via immich-go, with all metadata albums and all.
Had to change some parallelization option, but otherwise it was a breeze.
Besides, having to use external tool you check out from GitHub is the exact opposite of what should be the priority I am talking about. Immich gives you that clean, very easy UX/UI, targeting every regular user as a real alternative to Google or Apple offerings, yet you can't easily and safely import your photos. That's inconsistent at best. Misleading.
How do you imagine this wold work, given that there are no APIs for Google Photos or iCloud Photos to batch import them into a different service while preserving all data. At best you can work with the Gallery/Photos access on your phone.
The way it CURRENTLY already works. Through Google/iCloud takouts, or the Android/iOS apps if user chooses to do so.
And how do you know I haven't donated and don't regularly do so?
Because those services are closed black boxes that don't really let you access them except in a very roundabout way?
There's no "black box" magic here. Sure, there are some edge cases that need to be handled when importing the exported dataset, but it's all documented.
So, they are black boxes that don't make things easy or convenient for people. E.g. Google Takeout separates images and their metadata. With people running into issues like this: https://www.reddit.com/r/googlephotos/comments/1lqx331/googl... (as comments point out, Google just randomly changes file names as well, which breaks import tools)
> Sure, there are some edge cases that need to be handled when importing the exported dataset, but it's all documented.
As in: it's not really documented. Those takeouts, iCloud and Google shenanigans etc. have been reverse engineered by people to work. Meanwhile for closest friends only Apple, Google and some of their closes friends provide a way to transfer libraries directly, without "takeouts" and workarounds: https://portmap.dtinit.org/
BUT, that's irrelevant: their own iOS app butchers Live Photos and there's unresolved bugs that get hardly any traction. This isn't rocket science here, no wild-guessing, they get access to the Photo library like any other app using their SDK. They just lose those Live Photos when backing up to immich and no one got to the bottom of it.
WHY do you keep ignoring that aspect that I have mentioned like 3 times by now?
Which aspect? The only "aspect" you're talking about is, basically, "immich should make this fully documented easily and trivially implemented batch backup from iCloud Photos/Google Photos".
I mean, even live photos isn't documented anywhere, and Apple changes how it's implemented from time to time (e.g. moving from JPEG + MOV to HEIC + H.265).
I "restarted" maybe twice when I first got into Immich to find a good set up for playing reasonably nicely with external libraries, but it does need just a bit more polish. Good to see a sibling comment that it's on their list of priorities!
Hackers
The coolest thing I've done with Immich is just set up Docker on a more powerful machine, run the machine learning libraries, and point my instance (on a low powered server) to use that external computing for face recognition and OCR. Very cool!
I tried Nextcloud, but the apps/server end up failing to sync after at most a couple month, and it's painful to recover from that. So it doesn't work for me.
I have been considering Immich and Ente, but I would love to know if somebody has experience with that.
But as you can see in the linked release note, they made a lot of change to background sync on Android and iOS. It should (TM) work out of the box now.
> works for me on Android with Pixel phone
But do you open the Immich app on Android from time to time, or never and just use it to sync transparently in the background?
Does this fix this problem? https://github.com/immich-app/immich/discussions/12748
It's a pretty big issue for me having multiple devices and multiple people who want to pool pictures of our cats together in one album.
Currently I have to do this kind of set up:
1. Syncthing sync our photos back to the homelab server hosting immich - /mnt/Syncthing/a1/cats/ - /mnt/Syncthing/a2/cats/ - /mnt/Syncthing/b/cats/
2. cron job copying (hard-link) the photos to a folder mounted as read-only external library volume - /mnt/immich/ext-lib/cats/
3. cron job to run a script that automatically creates albums from external library folder structure: https://github.com/Salvoxia/immich-folder-album-creator
4. cron job clean up photos in the syncthing folder that are older than a year to free up space for our phones (~1TB total. Yes we have problem)
--------------
That said, congrat on the 3.0 release. Although I'm slightly bumped out because I literally just discovered this program a month ago and stabilized my self-host set up just one week ago.
IMMICH_VERSION=v3
docker compose pull
docker compose up
No issues so far. The web UI is not significantly changed, the biggest improvements are on mobile.
Which I am yet to do...
And yes, we only look at physical photos or the "on this day X years ago" reels. But to get here, Immich was a valuable tool.
Only it is different 100 photos every year.
The biggest complaint has always been how hard it is to self-host it, but that's not true anymore. If you have a good underlying system that handles all the boring stuff, you can actually have a pretty good experience.
I'm biased because I'm building an OS for this, and it makes spinning up imich so easy.
Everything is indexed and searched locally, so the photos never leave the device.
These make my albums feel like small blogs which really adds to the experience when sharing e.g. travel albums.
It got to where I had 20% of my space was just thumbnails for each user, even though it was one set of images in the external storage.
Maybe that's changed recently.
Unfortunately Immich is not end-to-end encrypted. If that would have be the case i'd use https://pixelunion.eu/
Seems like a great app though. So... i'm still pondering what to do :-)
You can also just use a secure transport layer (like WireGuard or a VPN) instead of relying on every project to implement end-to-end encryption.
It they don’t consider that e2e encrypted, literally nothing is then…
That’s not an image app anymore, that’s just encrypted storage.
Of course - this sacrifice quite a bit of functionality since more or less all functions which require looking at the pixels need to be client-side. But to be fair - the client is part of the "app", so it's not "just" encrypted storage.
Edit: regarding cloud based backup, besides the usual privacy and security concerns, you can’t guarantee the fixed price, you might subscribe now and pay for a year, next year you have the typical “oops, operation cost are high we have to raise the prices or shutdown” blog post and now you’re stuck again, download, find another, upload, etc.
That's the objective answer. There's no mystery here. That's exactly how you get what you want and it's not too hard. Not trying to dunk on you or anyone one but this is an easily solved problem, and I think I want to highlight it like this to make sure everyone understands.
Anything web/internet/network service thing, you can add this on. This composability is important to remember in software, this even goes back to "The Unix Way" type stuff.
Unfortunately this comes up a lot, with people asking if Immich supports end-to-end encryption and getting told to use LUKS or Tailscale.
Apparently HN does not like "not self hosting" and/or "e2e encryption" ?
Meanwhile, i also found https://zeitkapsl.eu/
- Upgrade breaks things. Need to restore from DB, install previous version, etc.
- Need to update frequently (i.e. if I wait 2 years, the upgrade script doesn't work).
- Discovering a corruption months/years later. Some data just lost by that point.
- Backward incompatible changes
Of course, if you need the features, by all means use it. I just want to back up my photos and use FolderSync daily. I have a separate workflow for pruning. As long as FolderSync (or some similar app) exists, I know this flow will work 10 years from now (heck, I've been using it for almost as long). No time spent worrying about upgrading, etc.
Alternate title: "Outdated lessons I haven't re-evaluated"
Are you saying there's no need to back up the underlying DB?
Are you saying I can keep an insurance running for, say, three years and it'll be trivial to upgrade after that?
That sad, I'm happy to answer your questions. I've run Immich in docker for 3 years with automatic updates through watchtower. Updates are frequent but require no effort from me and have never broken anything, nor is there an "update script" to fail. Nor have I encountered "corruption" at any point. I do back up the database and my photo library.
I'm glad you're happy with your solution, you can share it without disparaging other solutions you're unfamiliar with.
However, i also want the availability of my photos to be reliable, just like e-mail. It always has to work, wherever i am.
When i'm on the road, and there's some random issue due to power outage, database corruption, or whatever else, i don't want to have to wait until i get back home and make the time to fix things.
On the other hand, when i'm self hosting something like an RSS reader or Jellyfin to stream videos, it's less of an issue. That can wait a few days or weeks until i can fix it.
Of course this topic has been discussed: https://github.com/immich-app/immich/discussions/1683
For self-hosting, “S3” usually just means “S3-compatible.” Although maybe that’s exactly what you meant.
Apparently HN does not like "not self hosting" and/or "e2e encryption" ?
Meanwhile, i also found https://zeitkapsl.eu/
To elaborate a bit further, the S3 layer makes sense once you self-host S3 yourself. This allows clusterization of multiple hosts to offer redundancy in self-hosted setting -- for example, a friend of mine and I run S3 instances and "seed" each others' buckets for photo storage, but also for package manager (Nix). Having this kind of sane object storage just expands in use-cases, like with Matrix, etc., which all then inherit the clusterization hence redundancy for free.
The E2E encryption is also very useful when you are backing up or hosting photo galleries for friends and family -- because you cannot do metadata analysis on encrypted files, they have to do that on their own devices. This makes self-hosting much more "fearless" because I do not have to account for the fact that when/if my nodes are becoming a sauna-stoves for doing inference when someone dumps an album in.
The datasets that I have are terabytes. At some point it's just cheaper (accounting your time as free) to buy a 20tb drives and get yourself a runway for 5 years or more + space to do other stuff.
Isn't system administration a solved problem now with LLMs? At least for these simple problem domains?