I teach a free software development course to my undergrad students. It's really exciting to stumble upon one of the work they did for my class in the wild (it's the first listed bug fix — which is the last of the three pull requests this student got merged in Immich during my course). I feel so proud! :)
An incredible piece of software, on par with Google Photos. I've been using it behind Tailscale for months with no problems ever since I first got into homelabbing.
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
I would say at this point it's better than Google Photos!! The team is absolutely amazing, and I agree that it's astounding to see IMO the best (general purpose) photo app out there being open source
I've been considering it as well. I'm using 1.5TB in google one storage. mostly from photos/videos from the last decade from 4 family members.
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.
I would like to replace iCloud but it doesn't seem to sync changes/deletions with iPhone yet. I don't want to have to make changes/deletions in two places every time. v3 seems to have improved background uploads which is great as that has been a frequent complaint.
A lot of people talking about encryption in the comment section, thought I would share my setup. I have been running Immich for family and friends on a Hetzner auction server for about 1.5 years now.
Hetzner community provides official full-disk encryption documentation:
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.
FYI the setup you mention is not "end-to-end" encrypted. E2EE means client-to-client encrypted, with the server processing encrypted bits only. Your approach is encryption in transit and at rest. At rest is relatively irrelevent for large cloud providers, as they are probably better at managing the lifecycle of disks than most businesses or people. It's unlikely someone's going to physically rob a data center or end up with a refurb drive that hasn't been thoroughly processed and wiped.
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.
In memory. If the police shows up and they disconnect my server to sieze it, for example, the photos are lost to them.
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.
This is not end to end encryption. There is nothing stopping you (or Hetzner) from accessing your family’s data, as one the disks are mounted to a host they are decrypted and available for use.
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
This is only true if you are so highly individualistic you don’t consider a family unit as a single entity.
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.
It's a definition question. E2ee means in this cases that "the server" cannot decipher the data: the keys to that are only on the client and never shared with the server.
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).
> 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.
True. But the server is not completely unprotected even if not stored in my basement.
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.
Ok but again, that is introducing an arbitrary split that is not based on tech. What if I have two phones? Would you expect phone A to see images taken by phone B? If yes, obviously my phones need to share keys.
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.
E2EE, by definition, means that the server storing the data can't decrypt it. Your server can decrypt the data. Thus, it's not E2EE. Is this a problem? No. You've decided that the server is trusted (a "peer device"), so it's fine if the server can decrypt the data. That's a perfectly reasonable security posture, but it's still not E2EE.
I don’t think there is a formal definition of E2EE.
Here’s Wikipedia’s definition:
„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“
Note the complete lack of client/server distinction. It’s simply about intended recipients.
In many cases "transport encryption" would also fit that definition.
E2ee is quite well established imho. The server at Hetzner (a.k.a. "someone else's computer") is NOT to be trusted in e2ee schemes. Until today I'd be willing to say everyone agrees on this, but now I doubt that :)
I see e2e encryption over photo galleries a must since is a way of protecting yourself against misconfigured servers, future exploits or unpatched software.
If you want a cheaper alternative, maybe look into ServaRica. That's where I run my Immich instance for my wife and me. 4TB for $11 per month. The servers (cpus) are not super fast, but fast enough for me.
So many comments here about missing end to end encryption, but seriously - why would anyone want this?
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.
It would make hosting a "Family and/or friends" instance possible.
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.
I really don't think you want E2EE for this. I host storage for family and friends, I haven't set Immich up yet (don't think I'd have space for everyone's photos) but the choice is between:
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.
Ah yeah I see. I guess the fallback there would be to split the service up into a remote encrypted storage layer that goes on the VPS and then host the actual service (with the decryption keys) locally?
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 guess the fallback there would be to split the service up
I feel like it may be different enough that it's just not worth doing for Immich. To me, if you want the convenience of Immich in a trusted server, then Immich is great. If you want to host on an untrusted server, Ente is more to the point.
Those are two different models:
- With Immich, the server can do a lot of stuff (like processing on the images) but at the cost of the server accessing the images.
- With Ente, the server cannot access the images (that's the feature) but at the cost of not being able to do that kind of processing.
I am happy both exist, I think there is space for both.
You can run it on an encrypted volume on a VPS. Technically, it is also possible to use confidential VMs, but I have not at all kept up with those developments these days. Confidential here means that the SoC/CPU provides the ability for VMs memory to be encrypted with a key that the host never has access to. There's also remote attestation for it. I personally like e2e encryption at the application layer in some applications, but I personally do not think that it'd be practical for immich unless they also do confidential compute for the classifiers and identifiers. That is something Apple can do because they have the capital, not an open source project.
If you run it on an encrypted volume on the VPS, you get encryption at rest (e.g. if someone steals the disks, it's encrypted), but still your VPS provider is able to decrypt it (otherwise it just couldn't run).
Normally I either encrypt a non-boot drive (if the VPS provider offers such a thing) or use gocryptfs. It’s still a pain though when reboots happen, unless you also put your key there. Application layer encryption makes it easier.
gocryptfs is great, I use it to encrypt storage in embedded scenarios where the OS doesn't have the userspace tools or kernel modules to manage encrypted block devices.
My cousin just dumped 50GB of photos from his weddings in a Google Drive folder and shared with his contacts. I wanted to extract photos of my immediate family members from it and just save those. I setup immich on my macbook to do this but sadly I found the face recognition is nowhere near as good as Google Photos. It missed a lot of photos with tricky angles. Other than that, everything else looked quite solid to me.
Choosing 1 is totally fine but that doesn't mean it should not be possible to choose 2, right? Just because I don't need a feature doesn't mean I loudly complain when others ask for it.
Two people in my life when I was a kid have since been sent to prison for pedophilia. There's a 0.0% chance I'm hosting encrypted media for anyone other than my spouse. The low but nonzero risk of the cops asking me about some encrypted files I'm holding for a friend simply would not be worth the risk for saving someone the tens of dollars a month to self host their own content.
I meant hosting such instance with the bare minimum privacy considerations. Otherwise you would have to be honest with them that you’ll have complete access to all their photos and make sure they understand it. People’s camera roll is often akin to their text history or email. It can contain plenty of personal and private things. Just because we’re friends, or even siblings, it doesn’t mean it’s free-for-all access to everything.
Agreed on the difficulty of implementing server side features though, especially all the things people expect from a Google Photos alternative.
I think the point of E2E encryption is that you could host it with a cloud provider and the provider would not be able to see your data. Kind of like how Proton Drive claims it does not know which files you have.
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.
Seriously! How do techies and devs of all people not understand that the cloud is someone else's computer, and that the best way to prevent leaks, exploitation, or abuse of user data is to prevent anyone from being able to decrypt it but the end users themselves.
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).
> It should be standard for anything hosted on someone else's computer.
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.
I'd personally rather have E2EE and periodically back things up to an encrypted hard drive so any losses aren't catastrophic, but I am probably more cynical than most in my trust of companies/other people with my data and am technical so understand the risk model both ways better than most people.
>I'd personally rather have E2EE and periodically back things up to an encrypted hard drive so any losses aren't catastrophic
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.
Why is there "a very good possibility" of losing your photos because they are E2EE? Do you not use a password manager and backup your data?
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.
No it's not. The point of E2EE is that only the client apps decrypt/encrypt content, and the server just processes the encrypted bits. Most E2EE service providers do this by encrypting your encryption key. That's how you can login on other devices without you having to store and import an encryption key every time. When you login they send you an encrypted blob that contains your encryption key, which is decrypted client side, then the key is used to decrypt your data locally on the client. This does not break E2EE, but it does mean you have to trust the provider, which is why most of them are entirely open source.
Sharing and emergency access also use similar public key cryptography techniques to provide shared access to E2EE data. A similar principle applies to your phones encryption aswell, and is the reason you can wipe/reset your device in seconds, instead of minutes/hours. They only wipe the encryption key; not the encrypted data.
I think you are slightly confused about E2EE, let me try to address a few points:
- The whole point of end-to-end encryption is that nobody in the middle (e.g. the server) can possibly have access to the encrypted data. If they can (e.g. by giving you a way to reset your password), then it is not end-to-end encryption, period.
- It is possible for a provider to "encrypt an encryption key" with another key they cannot access, e.g. a password. In that case your password (probably through a KDF) is the key to decrypt the encryption key that is used further.
- It is possible for an app to store your key locally. Ideally you would store your key in a secure element on your phone for instance, and unlock it e.g. with biometry.
- In any case, if the client (e.g. the app) is not open source, you cannot easily know if it does what it says. That's why it's easier to trust Signal than WhatsApp.
- If you lose your "key" (whatever it is that the server doesn't know), your data is lost. If you can lose your key and the server can help you recover, it means that the data was not end-to-end encrypted and the server could access it without needing you at all (obviously, because you lost the part that they needed).
Now, in order to seriously trust E2EE, you need to trust the implementation. That means that if you cannot audit the code (typically, WhatsApp), then it's difficult to trust it. Another example is ProtonMail: you open the webpage in your browser, and at this point it downloads a client that is supposed to do the decryption locally. How do you trust that client? You could try to audit it, but next time you reload the page, it may download modified sources, and you won't know (there aren't tools to pin the version of a webapp from the browser).
In that sense it's even harder to trust ProtonMail than WhatsApp: it would be trivial for Proton to serve a different client that would exfiltrate your password just for you, just this one time, and no audit by anyone else in the world would ever detect it. So when you use ProtonMail in the browser, you trust the Proton server, which defeats the purpose of E2EE. It is still better than non-E2EE like GMail (where you know Google reads all emails of everybody), but you still trust the Proton server, which is not what is usually expected with E2EE.
In a recovery scenario, you don't have the password or whatever you used to encrypt the key.
And again: the whole point E2EE is that you don't have to trust the provider. Open source in general doesn't help you here because you don't know what software or which version of the code the provider is running. Your only chance is to run open source client software, review it to ensure E2EE has been implement properly, then you don't need to trust the provider.
Either the provider knows the secret, then they can help you in a recovery scenario, but then they also can read your data. Or they don't know the secret, in which case they cannot help you in a recovery scenario.
I don’t agree E2EE is right for everything, and especially not for a personal photo library.
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.
Especially that it would come with the loss of quite a few features, or at least a significantly worse way to implement them.
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.
Also bottlenecked when it comes to background operations.
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.
Sounds like you want your photos on a unencrypted HDD, which you can do regardless of whether or not a cloud service is E2EE, so I don't see how E2EE is an issue...
No, I do not want that. I have my photos on an encrypted HDD, in a server running Immich in my basement, and I connect to it using WireGuard. Everything is encrypted at rest and in transit.
There’s no cloud.
I get to reap the benefits of not using E2EE encryption, like offloading machine learning tasks and transcoding to a server, and having extremely simple clients that don’t need to roll their own application-layer crypto.
E2EE isn’t a silver bullet.
It solves a specific problem — trusting the server — and introduces another — pushing complexity to the clients. If you already trust the server, because it’s running on your infrastructure, there are no upsides.
And Immich was designed specifically for self-hosting. To not depend on the cloud. It makes no sense for it to make trade-offs that don’t benefit self-hosting.
I hear ya, I was being a little bit over the top. But I really do think that for every one user who would turn on e2ee and get some genuine benefit out of it, there would be a dozen that turn it on because "encryption good" and accidentally lose all their data.
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.
Yeah Immich and Ente are going for two different use cases. While Ente can be self hosted, I view it as more of an escape hatch if they ever enshittify vs how I would start off using the service. I like not having to manage ingress for a photos service so my family can use it but others cannot
I think the application layer is the wrong layer for encryption for immich anyways, I just encrypt the whole disk on my server. When _self_ hosting, there's no need to prevent access to files from the operator.
To me there are two good products: Immich and Ente.
* 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.
>So many comments here about missing end to end encryption, but seriously - why would anyone want this?
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?
I want to host an instance for me and my family. Right now we have a Google One instance shared by 5 people. Having e2e means my family members can rest assured that I or whoever I share admin rights with cannot look at their private photos. It's an important enough feature even without thinking about 3rd party bad actors.
I agree, we used to have photo albums in cupboards, and they used to get burnt if the house burned down, or water damaged if the boiler broke, or even stolen. Now we have them digitally and we can back them up off-site. That's all the change I need with immich.
To fully encrypt them would just be inviting more problems.
This actually happened to me, without getting into the specifics, a family member with mental issues took all the childhood photo albums and burned them.
If they steal your homelab, e2ee doesn't help, it's encryption at rest. E2ee is for rogue devices sniffing the network, which is more or less of a concern depending on your setup. I'd not have unencrypted traffic in my network if I had for instance those shady TV boxes.
That’s incorrect. E2EE means encrypted data leaves the device, stored encrypted, and server(s) have no keys to decrypt it, only your (or other) client software does.
It's encryption both at rest and on transit. At rest there are levels of encryption, at object level or at filesystem level. E2ee for immich would mean the objects are encrypted and transmitting the data is encrypted. If the scenario is the server is stolen, you need encryption at rest. Even at FS level is enough.
I've seen a lot of companies use "e2ee" to basically just mean encryption during transit, not even in rest. It's wrong, but I can see where this idea can propagate.
That’s actually true, but that’s a different issue - companies lying in their marketing materials, making claims that do not match the reality (or well-established definitions, if a company choses to mean something else and call that E2EE).
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.)
I have no idea, I use wireguard to access it. I have disk encryption setup. They'd need to hack my linux server SSH which I have protection turned on to shut it down after failed attempts. It would be a challenge to get access to my photos on disk. They could steal my phone and access through the app if they could get them all before I disabled access since Im using encrypted icloud account.
In the end who would want all my photos for that amount of work lol?
I just want to be able to share my hosted service with other people and not have the responsibility of being able to access their photos. Me or anyone that happens to gain access to my server.
Im wary about having my PII hosted on vpses which I suppose makes me a privacy nut. I just host immich on an old laptop and use the VPS to establish a wireguard tunnel.
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.
Agreed. It's especially frustrating to read of extremely high standard (even though justified, I'm not suggesting it's OK to have a subpar experience) while most people just share everything and anything on Facebook, TikTok, SharePoint, etc and have no idea what permissions even mean.
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!
When I was switching to GrapheneOS from iOS, I decided to self host my photos. I considered Immich, but I settled on Ente because of the encryption. Ente Photos is extremely polished and it's comparable quality to Apple photos.
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.
> Ente Photos is extremely polished and it's comparable quality to Apple photos.
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.
I've been bitten too many times - is Ente a commercial product that pays lip service to self hosting as form of marketing, but with friction to guide you towards the hosted version (e.g. rocketchat and many others) or does it genuinely support self hosting as a first class product?
Ente Auth is also the best, because it works on any device, including the one you're trying to access (maybe it defeats the purpose of 2FA but sometimes I don't care).
Ente auth is a really nice secure and private cloud authenticator.
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.
I guess the free-ness of auth and I think locker is included with any photos subscription so maybe that’s the appeal.
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.
I got into Ente because I wanted to create photo upload links on a per-even basis - I can tell all my friends, if you take pics or video tonight, upload it at this URL - and it just works. No app necessary, very simple, very cheap. Then from there, I got the photo backup / archive service because why not.
They really are pretty much just what they appear to be. Im a fan.
For what it's worth, Immich supports this too. You can create an album (for each event), create a shared link, allow public anonymous uploads for the shared link, and then give the link to everyone at the event, and ask them to upload their photos. It can be done from any web browser.
I would love to know if there's a way to secure this though. I'm not prepared to have people constantly trying to login to my immich instance so it's only accessible via VPN
You can use something like Immich Public Proxy to only expose the /share path of your server and keep the main /api path that has everything else behind VPN
Beware that migrating back from Immich to iCloud/Google is not something Immich cares about. There is no "download all" anywhere, best way is to go to the server and get raw files from there.
It's tricky with iOS. Plugging iPhone into a server is stupid. Adding server as a network storage in Files app is smarter, but downloading photos this way does not guarantee deduplication. Would be great if Immmich iOS app had a restore functionality as convenient as existing backup functionality.
The immediately obvious and simple to handle on-disk format for everything I cared about was one of the things that convinced me to give it a try. Well-crafted exporters are great and all, but I really like being confident that I can convert it by hand even if the company ceases to exist.
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.
what do you mean download all? its your server over your files. If you want them, go get them! Or just point google / apple / whatever upload at your library directory.
A download button would be great but the files are already stored on the device you can copy them with a usb or go on the device and upload it directly.
Yes, that's even more stupid! Best way to export photos from iCloud if you don't have mac is to use iCloud from the browser and bulk download from there, but it has a 10k files-per download limit! It also doesn't allow you to select all and partiton download this way, I had to manually increase selection until it's 10k and remember where I started.
And yet, the same is true for Apple photos about ease of export:
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.
Are there any side effects of leaving Immich public? I think people overestimate the risks. Just update your stuff regularly, follow simple rules, and set up something like CrowdSec. I know it's simpler to just use Tailscale and similar tools, but recently I see the trend that people don't even consider otherwise.
I only wish it would support nested albums (or albums in folders) so it could be an easy replacement for lightroom cloud as well.
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.
I'm in the same boat, and have been meaning to try immich but slightly worried about migration effort. Should I import fresh into Immich or setup my existing photoprism as an external library? I think the former is probably correct, but the latter might be easier?
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.
I can only comment about battery life. It's proportinal to how much tailscale is really being used: If you use tailscale with an "exit node", i.e. all traffic is routed through it and it's working continously, it drains battery. If it's only used for services on your tailnet, e.g. Immich, the impact will be very small.
I have a static route configured on my home's gateway that enables any device on my network to access Tailscale. I have Tailscale turned on my iPhone pretty much all the time anyway, but even if I didn't I'd still be able to access services I have hosted that are only accessible on my tailnet.
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.
Here's some data. Well, technically anecdata, I suppose.
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.
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.
I remember having problems using tailscale vpn 24/7 and pihole on my home network with the phone pointed at the 192.168 address for DNS. Pages would take 5s to resolve and start loading.
Unfortunately, Pihole was less important than Tailscale and I have to put up with mobile ads.
I'm on iPhone, i found a workaround involving having headscale set the dns using 'magicdns' or something and having that pihole join the tailnet. after that everything is mostly groovy but the individual components don't easily seem to be able to connect to a different vpn.
I leave my phone connected 24/7 and don’t notice any downsides. Only have to disable it on some networks when traveling to make awful captive portals work.
i've had tailscale almost permanently enabled for a couple of years at this point and it's never a problem (ios, nextdns with a tailscale specific profile rather than a pihole or something)
There's a lot of things I spent a ton of time setting up, use once, and then never again. Tons of things that are easy to set up, and provide small benefits every day for a long time. Immich has got to be the thing that I've spent ages setting up, use extremely infrequently but the one time a year I use it I'm so happy I did. Great software.
Man, I wish my experience was as nice. I used the proxmox lxc for it and after a 2 months of organizing I had some corruption and didn't have the fortitude to get through the debugging. It might have been related to a big version migration if I remember correctly. It turned me off the stack. The upgrading wasn't as turnkey as I wanted it to be and I dont think the case is different today.
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.
I'm not sure I will ever upgrade Immich again. When I upgraded to the next minor version (I forget which off the top of my head), the data migration corrupted my database such that no images would be served. Fortunately I had the old database backed up, so I restored it, rolled back to the older version of Immich, and things were back to normal. I like Immich, but this is not good for software that's beyond the first major version, and also handles archiving people's personal data.
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 had an issue where my thumbnails were borked somehow, so I deleted them all. However, I didn't delete the database entries, so they never got regenerated.
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.
In my case I spent it not so much time setting it up, some time upgrading with some manual work required from time to time with breaking changes (but not so often) and I use it weekly, it just works and it's wonderful.
Does anyone have any pointers on the best way to import roughly 14 Google takeout chunks into 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".
If you can get all the images into a filesystem (on a NAS or similar server share), you can use the External Libraries feature in Immich (https://docs.immich.app/features/libraries/). This allows it to crunch through the media files via an async import job (a bit more reliable than having to directly upload via the web api).
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!
This is a good usage pattern if you're absolutely married to the file structure you have and/or want to keep using the files where they are.
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
I went through the same path as you - I think I even landed up with 14 takeout files as well!
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:
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.
> 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".
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.
You can use this tool to get them into Immich, it will parse all the metadata and recreate albums as you have in GPhotos https://github.com/simulot/immich-go
Oh wow, it recreates the Google Photos albums? That's the first time I've heard of a tool doing that. I've spent a ton of time organizing my Google Photos albums, that's a big reason I stay with it.
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.
Just a quick note that native windows extract is 32bit and dies on archives gt 4gb. Use 7zip or something to extract in case you happen to be using that one.
Has the ios photo sync gotten better? I've got 20k photos on my phone, and last I tried it filled up the storage on my phone with the originals, and never completed the process, even after leaving my phone open, unlocked, and the immich app running in the foreground for several days, on the same local network as the server.
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.
I have a largish library at about 400gb. I synced it completely using the mobile app. It took a few months (it just finished in early June) but it’ll eventually do it. I know there are other ways but I figured this was the laziest way to do it.
I have synced ~9000 photos from my phone in february. That worked pretty well. I was done in about 10 hours. I don't remember whether the originals were downloaded, or whether they were deleted automatically afterwards. Felt like a smooth process though.
> 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.
Large file uploads are non-resumable. That is, if you have any videos at a decent bitrate and resolution, you need to be able to upload the whole file in a single session. iOS doesn't make this easy to do via background uploads. I uploaded everything by keeping the app open overnight.
No, it’s an Immich issue. Not OP, but I was already using Synology Photos. Synology finished syncing my library in two days, while Immich was still syncing after more than a week. I decided it wasn’t worth it after that experience.
Why are you syncing from your phone instead of your Synology then? Can't you sync from your NAS then just have pictures uploaded as you take them? iOS has a lot of restrictions compared to Android so two days really doesn't feel like a meaningful difference from a week.
The 2 days were spent uploading my entire library from scratch. After that, daily syncs only take a few minutes.
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’m not an Immich or Synology user but essentially the mobile apps end up replicating your whole structure a little better, at least when I did the iCloud library to Ente import.
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.
I have a different bash with them than the lack of E2EE: they do not make it easy to import from other servicesvlike Google Photos or iCloud, which should be a priority.
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.
Their business model is basically donations, it's not a for-profit operation. Maybe if you consider yourself less of a customer and more the beneficiary of a community effort, it'll be easier to "get"
Don't patronize me, my arguments still stand: they offer all bells and whistles while completely dropping the ball at making you feel those photos are well taken care of. The core employees live off of Immich so spare me the spiel.
It seemed like that for me, too, until I realized my photos were botched. The only way to know that was looking into the logs: I have some 9000 photos which it silently fails to extract metadata from. The only sign in the UI that something is off is the fact those 9k photos never get processed, you can try in perpetuity. The logs reveal they were botched either by immich-go or iOS app, ffmpeg freaks out when processing them. After checking in the gallery they're indeed messed up.
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.
> mmich 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.
I don't see it. I made a remark that nice-to-haves are less important than the bare essentials. And I don't get how this quasi-commercial product doesn't have this locked in, despite them making an every effort to come off as polished.
No. They're not. You export photos using Google Takeout, iCloud has something similar. And their own iOS app also has unresolved bugs because of which I can't fully import my gallery.
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.
> No. They're not. You export photos using Google Takeout, iCloud has something similar.
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/
This is why I said A-B testing would be important.
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?
> 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).
Immich is an amazing software. I use it regularly as an alternative along side Google photos. I keep in it large videos that I wouldn't upload normally to Google photos + the snappy experience at home vs Cloud-Bades solution.
I wish they would better support external image sources - images not uploaded/managed by Immich, just a folder of images it has access to - especially if it's read only. It mostly works, but the UI and logic breaks in a lot of little ways.
Yup. I love Immich, but I'm also a control freak, so my 25 years of digital photos I had before using Immich still exist in an External Library. It mostly works but I still have some issues. Like I keep getting a batch of ~70 photos that lose their "date taken" and revert to the date/time I started using Immich. (Fortunately the file names are date/times and I can manually go through and fix them, but having done it at least three times, it's getting old!)
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!
How does the mobile app sync work with Immich? My use-case is that I want to install the mobile app on the phone of my relatives (including iPhones), and it should keep syncing their pictures "forever" even though they never, ever open the app.
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.
With works for me on Android with Pixel phone, after I added Immich to the list of apps that can work in the background.
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.
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.
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.
I've been self hosting immich for the past 6 months. It's pretty awesome. The App has some performance issues but the web is flawless. I cut down on my iCloud plan since I deleted most of my videos from it. I use restic to manage backups with my own key offsite.
I would switch immediately if they added support for non-photo elements in albums like google photo has. E.g. texts and maps. And the option to chose the order of album elements yourself.
These make my albums feel like small blogs which really adds to the experience when sharing e.g. travel albums.
yes. https://docs.immich.app/features/editing/
And it is very aware of exif. It also has AI features to analyze the photos (or videos) and you can for example search for "cat" and it will find all photos with cats.
I have a bunch of spare s3 compatable storage from a cloud provider which I would really like to use to run Immich, but everytime i look into it it seems not possible.
I got annoyed with Immich and external storage, because in order for every user to have their own facial recognition data on a large set of photos, you have to add the folder as external storage for each user, which means image previews for each user, even though the source image is the same. So if you have 3 users, you use up 3 times the space for the same thumbnail image.
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.
My only disappointment with this release is that the beta version of workflows does not have the ability to sort photos into albums by face detected (yet). That’s what I’ve been waiting for as both Google Photos and Ente support smart albums
Okay? So don't use it, use a managed service like Google Photos, Apple Photos, Dropbox, etc where your photos and files might be arbitrarily removed or your access to them limited while they are scanned for disavowed content.
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.
Yes but magical homomorphic encryption aside, the person has conflicting requests at that point. They are asking for an image app that can’t view their images.
That’s not an image app anymore, that’s just encrypted storage.
I think the idea is that the images are decrypted by the client. See how Ente does it: https://ente.com/architecture
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.
You can have immich on truenas that has the whole pool encrypted, same goes with opencloud for other docs/files. Plus all nas backup features, I think it’s a better approach than dealing with each app encryption.
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.
It's also a kind of funny thing how HN has the attitude of "never implement your own encrypted anything" but then demand their apps build in e2e encryption. It may be one abstraction higher, but it's still fundamentally the same problem. With the unfortunate exception of web browsers, if I'm going to use something that performs encryption, then I want encryption to be the only job it has.
When we talk about "E2EE" messenger apps, that usually means more than just using HTTPS. VPNs can certainly help with encryption in transit, but that's a very different concept.
Unfortunately this comes up a lot, with people asking if Immich supports end-to-end encryption and getting told to use LUKS or Tailscale.
So if you don't want a self hosted service there are tons of cloud providers. Google photos, iCloud, etc. Some people don't want to pay a monthly fee to store their photos or don't want to risk losing something with sentimental value just because a company decides to ban you
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.
Valid points. But I see self-hosting even as renting a VPS from someone and running the service there. Which solves most of the dev ops problems that I dont wanna bother with.
Maybe it's not "actual" self-hosting, but concenient enough to use it
Lessons from using self hosted image services years ago:
- 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.
I'm saying your contribution is outdated and irrelevant, and my primary intention in commenting is to label it as such for any passers-by who might think you're talking about the current state Immich.
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.
I'm glad you're happy with it, and perhaps Immich will continue to remain secure. 3 years is comforting.
I will note that the last solution I used was fine for over a decade before it broke (and eventually the project died). For much of the time I was using it, it was the primary open source self hosting solution.
So one of my criteria is: "If the project dies, can I maintain it?" Obviously, I can't use that approach for everything (limited skills and time) - I do use NextCloud, for instance (which, BTW, is fairly painful for some of the reasons I listed above). But wherever I can (and wherever it's important), it's best to develop your own stack.
Best to think in the long term. But yes, for sure, there are down sides to my approach.
S3 has many open implementations you can self host. Some are quite lean even. Unless you need really complex IAM stuff it's a solid and rather simple experience to run it.
Wouldn't it then be reasonable to focus on those many features, instead of storage? I would enjoy using with S3, as expanding S3 storage is easier than expanding the storage of a virtual machine: usually it happens automatically.
Perfect is the enemy of the good. While there's an ideal case where you're hosting it on a box in your house, that's not for everybody. So while hosting it on AWS doesn't remove every dependency on big tech, at least it's not a full on Google hosted SaaS product.
I think "perfect is the enemy of good" is actually an argument against AWS integration. Using S3 as a backend is a lot more complex than using local storage so it would take a lot more time to implement, that's why local storage is good enough
Only if we look at resources it takes to implement features as limited and we're in starvation mode. With AI writing code these days, if they choose to use it, it's less about the resources to make the features and more about what having the features enables.
I think I dug my own grave by not being explicit that I thought S3 as a protocol and not the AWS product. :)
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.
I teach a free software development course to my undergrad students. It's really exciting to stumble upon one of the work they did for my class in the wild (it's the first listed bug fix — which is the last of the three pull requests this student got merged in Immich during my course). I feel so proud! :)
Thank you for supporting Open Source as a professor!
Naww, that's awesome! gj :)
An incredible piece of software, on par with Google Photos. I've been using it behind Tailscale for months with no problems ever since I first got into homelabbing.
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
Please buy a license if you are happy with the project :) it's free, but you can still buy a license for a small amount of what you saved
Done! <3
Good point. Will do so as well. I've been using it for about a year now on my NAS. I basically set it and forget it, and it has just worked.
I would say at this point it's better than Google Photos!! The team is absolutely amazing, and I agree that it's astounding to see IMO the best (general purpose) photo app out there being open source
I've been considering it as well. I'm using 1.5TB in google one storage. mostly from photos/videos from the last decade from 4 family members.
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.
Immich promotes a 3-2-1 backup strategy in their docs you can read about: https://docs.immich.app/administration/backup-and-restore/
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.
I would like to replace iCloud but it doesn't seem to sync changes/deletions with iPhone yet. I don't want to have to make changes/deletions in two places every time. v3 seems to have improved background uploads which is great as that has been a frequent complaint.
[dead]
A lot of people talking about encryption in the comment section, thought I would share my setup. I have been running Immich for family and friends on a Hetzner auction server for about 1.5 years now.
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.
FYI the setup you mention is not "end-to-end" encrypted. E2EE means client-to-client encrypted, with the server processing encrypted bits only. Your approach is encryption in transit and at rest. At rest is relatively irrelevent for large cloud providers, as they are probably better at managing the lifecycle of disks than most businesses or people. It's unlikely someone's going to physically rob a data center or end up with a refurb drive that hasn't been thoroughly processed and wiped.
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.
I do happen to have some experience.
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.
Hetzner has fewer employees I guess, but since your photos are decrypted there, you have basically the same problem.
In memory. If the police shows up and they disconnect my server to sieze it, for example, the photos are lost to them.
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.
This is not end to end encryption. There is nothing stopping you (or Hetzner) from accessing your family’s data, as one the disks are mounted to a host they are decrypted and available for use.
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
This is only true if you are so highly individualistic you don’t consider a family unit as a single entity.
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.
It's a definition question. E2ee means in this cases that "the server" cannot decipher the data: the keys to that are only on the client and never shared with the server.
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).
I think that is a bit stretch.
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.
True. But the server is not completely unprotected even if not stored in my basement.
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.
What is the relevant definition of client and server if they are both peer devices under roughly equal level of control of a single entity?
The client in your family members devices has encryption keys that you do not have in your client or on the server
Ok but again, that is introducing an arbitrary split that is not based on tech. What if I have two phones? Would you expect phone A to see images taken by phone B? If yes, obviously my phones need to share keys.
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.
E2EE, by definition, means that the server storing the data can't decrypt it. Your server can decrypt the data. Thus, it's not E2EE. Is this a problem? No. You've decided that the server is trusted (a "peer device"), so it's fine if the server can decrypt the data. That's a perfectly reasonable security posture, but it's still not E2EE.
I don’t think there is a formal definition of E2EE.
Here’s Wikipedia’s definition:
„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“
Note the complete lack of client/server distinction. It’s simply about intended recipients.
In many cases "transport encryption" would also fit that definition.
E2ee is quite well established imho. The server at Hetzner (a.k.a. "someone else's computer") is NOT to be trusted in e2ee schemes. Until today I'd be willing to say everyone agrees on this, but now I doubt that :)
I see e2e encryption over photo galleries a must since is a way of protecting yourself against misconfigured servers, future exploits or unpatched software.
how much storage and how much do you pay Hetzner?
Prices have jumped considerably, but basically anything on Server Auction is good https://www.hetzner.com/sb/
I pay 60/month for 50 TB with a 10 year old intel xenon.
If you want a cheaper alternative, maybe look into ServaRica. That's where I run my Immich instance for my wife and me. 4TB for $11 per month. The servers (cpus) are not super fast, but fast enough for me.
[flagged]
So many comments here about missing end to end encryption, but seriously - why would anyone want this?
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.
It would make hosting a "Family and/or friends" instance possible.
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.
I really don't think you want E2EE for this. I host storage for family and friends, I haven't set Immich up yet (don't think I'd have space for everyone's photos) but the choice is between:
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.
I do agree that this is a use-case.
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.
Ah yeah I see. I guess the fallback there would be to split the service up into a remote encrypted storage layer that goes on the VPS and then host the actual service (with the decryption keys) locally?
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 guess the fallback there would be to split the service up
I feel like it may be different enough that it's just not worth doing for Immich. To me, if you want the convenience of Immich in a trusted server, then Immich is great. If you want to host on an untrusted server, Ente is more to the point.
Those are two different models:
- With Immich, the server can do a lot of stuff (like processing on the images) but at the cost of the server accessing the images.
- With Ente, the server cannot access the images (that's the feature) but at the cost of not being able to do that kind of processing.
I am happy both exist, I think there is space for both.
You can run it on an encrypted volume on a VPS. Technically, it is also possible to use confidential VMs, but I have not at all kept up with those developments these days. Confidential here means that the SoC/CPU provides the ability for VMs memory to be encrypted with a key that the host never has access to. There's also remote attestation for it. I personally like e2e encryption at the application layer in some applications, but I personally do not think that it'd be practical for immich unless they also do confidential compute for the classifiers and identifiers. That is something Apple can do because they have the capital, not an open source project.
> You can run it on an encrypted volume on a VPS.
If you run it on an encrypted volume on the VPS, you get encryption at rest (e.g. if someone steals the disks, it's encrypted), but still your VPS provider is able to decrypt it (otherwise it just couldn't run).
Normally I either encrypt a non-boot drive (if the VPS provider offers such a thing) or use gocryptfs. It’s still a pain though when reboots happen, unless you also put your key there. Application layer encryption makes it easier.
gocryptfs is great, I use it to encrypt storage in embedded scenarios where the OS doesn't have the userspace tools or kernel modules to manage encrypted block devices.
My cousin just dumped 50GB of photos from his weddings in a Google Drive folder and shared with his contacts. I wanted to extract photos of my immediate family members from it and just save those. I setup immich on my macbook to do this but sadly I found the face recognition is nowhere near as good as Google Photos. It missed a lot of photos with tricky angles. Other than that, everything else looked quite solid to me.
Choosing 1 is totally fine but that doesn't mean it should not be possible to choose 2, right? Just because I don't need a feature doesn't mean I loudly complain when others ask for it.
Two people in my life when I was a kid have since been sent to prison for pedophilia. There's a 0.0% chance I'm hosting encrypted media for anyone other than my spouse. The low but nonzero risk of the cops asking me about some encrypted files I'm holding for a friend simply would not be worth the risk for saving someone the tens of dollars a month to self host their own content.
You can host a family and friends' instance on your own hardware.
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.
I meant hosting such instance with the bare minimum privacy considerations. Otherwise you would have to be honest with them that you’ll have complete access to all their photos and make sure they understand it. People’s camera roll is often akin to their text history or email. It can contain plenty of personal and private things. Just because we’re friends, or even siblings, it doesn’t mean it’s free-for-all access to everything.
Agreed on the difficulty of implementing server side features though, especially all the things people expect from a Google Photos alternative.
Who wants to be support for family and friends.
I think the point of E2E encryption is that you could host it with a cloud provider and the provider would not be able to see your data. Kind of like how Proton Drive claims it does not know which files you have.
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.
Seriously! How do techies and devs of all people not understand that the cloud is someone else's computer, and that the best way to prevent leaks, exploitation, or abuse of user data is to prevent anyone from being able to decrypt it but the end users themselves.
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).
> It should be standard for anything hosted on someone else's computer.
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.
I'd personally rather have E2EE and periodically back things up to an encrypted hard drive so any losses aren't catastrophic, but I am probably more cynical than most in my trust of companies/other people with my data and am technical so understand the risk model both ways better than most people.
>I'd personally rather have E2EE and periodically back things up to an encrypted hard drive so any losses aren't catastrophic
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.
Why is there "a very good possibility" of losing your photos because they are E2EE? Do you not use a password manager and backup your data?
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.
> can't provide recovery or emergency access mechanisms
If they can do that then they are not e2ee.
see other comment https://news.ycombinator.com/item?id=48772802
Other commentes already pointed out to you the reasons E2EE may be not what you think it is, but I still feel the need to answer the question:
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.
> How do techies and devs of all people not understand
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.
> That's the whole point of E2EE.
No it's not. The point of E2EE is that only the client apps decrypt/encrypt content, and the server just processes the encrypted bits. Most E2EE service providers do this by encrypting your encryption key. That's how you can login on other devices without you having to store and import an encryption key every time. When you login they send you an encrypted blob that contains your encryption key, which is decrypted client side, then the key is used to decrypt your data locally on the client. This does not break E2EE, but it does mean you have to trust the provider, which is why most of them are entirely open source.
Sharing and emergency access also use similar public key cryptography techniques to provide shared access to E2EE data. A similar principle applies to your phones encryption aswell, and is the reason you can wipe/reset your device in seconds, instead of minutes/hours. They only wipe the encryption key; not the encrypted data.
I think you are slightly confused about E2EE, let me try to address a few points:
- The whole point of end-to-end encryption is that nobody in the middle (e.g. the server) can possibly have access to the encrypted data. If they can (e.g. by giving you a way to reset your password), then it is not end-to-end encryption, period.
- It is possible for a provider to "encrypt an encryption key" with another key they cannot access, e.g. a password. In that case your password (probably through a KDF) is the key to decrypt the encryption key that is used further.
- It is possible for an app to store your key locally. Ideally you would store your key in a secure element on your phone for instance, and unlock it e.g. with biometry.
- In any case, if the client (e.g. the app) is not open source, you cannot easily know if it does what it says. That's why it's easier to trust Signal than WhatsApp.
- If you lose your "key" (whatever it is that the server doesn't know), your data is lost. If you can lose your key and the server can help you recover, it means that the data was not end-to-end encrypted and the server could access it without needing you at all (obviously, because you lost the part that they needed).
Now, in order to seriously trust E2EE, you need to trust the implementation. That means that if you cannot audit the code (typically, WhatsApp), then it's difficult to trust it. Another example is ProtonMail: you open the webpage in your browser, and at this point it downloads a client that is supposed to do the decryption locally. How do you trust that client? You could try to audit it, but next time you reload the page, it may download modified sources, and you won't know (there aren't tools to pin the version of a webapp from the browser).
In that sense it's even harder to trust ProtonMail than WhatsApp: it would be trivial for Proton to serve a different client that would exfiltrate your password just for you, just this one time, and no audit by anyone else in the world would ever detect it. So when you use ProtonMail in the browser, you trust the Proton server, which defeats the purpose of E2EE. It is still better than non-E2EE like GMail (where you know Google reads all emails of everybody), but you still trust the Proton server, which is not what is usually expected with E2EE.
In a recovery scenario, you don't have the password or whatever you used to encrypt the key.
And again: the whole point E2EE is that you don't have to trust the provider. Open source in general doesn't help you here because you don't know what software or which version of the code the provider is running. Your only chance is to run open source client software, review it to ensure E2EE has been implement properly, then you don't need to trust the provider.
Either the provider knows the secret, then they can help you in a recovery scenario, but then they also can read your data. Or they don't know the secret, in which case they cannot help you in a recovery scenario.
I don’t agree E2EE is right for everything, and especially not for a personal photo library.
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.
Especially that it would come with the loss of quite a few features, or at least a significantly worse way to implement them.
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.
Also bottlenecked when it comes to background operations.
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.
E2EE means the keys are on your own computer (or device or brain etc). The “someone else’s” computer is just hosting encrypted blobs.
I understand what it is. I still don’t want the encrypted blobs outside my control.
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.
Sounds like you want your photos on a unencrypted HDD, which you can do regardless of whether or not a cloud service is E2EE, so I don't see how E2EE is an issue...
No, I do not want that. I have my photos on an encrypted HDD, in a server running Immich in my basement, and I connect to it using WireGuard. Everything is encrypted at rest and in transit.
There’s no cloud.
I get to reap the benefits of not using E2EE encryption, like offloading machine learning tasks and transcoding to a server, and having extremely simple clients that don’t need to roll their own application-layer crypto.
E2EE isn’t a silver bullet. It solves a specific problem — trusting the server — and introduces another — pushing complexity to the clients. If you already trust the server, because it’s running on your infrastructure, there are no upsides.
And Immich was designed specifically for self-hosting. To not depend on the cloud. It makes no sense for it to make trade-offs that don’t benefit self-hosting.
I think we can imagine a scenario where not all of our photos are non-sensitive.
I also imagine that a true E2EE architecture means you have more flexibility with cloud storage, managed hosting, and off-site backups.
I hear ya, I was being a little bit over the top. But I really do think that for every one user who would turn on e2ee and get some genuine benefit out of it, there would be a dozen that turn it on because "encryption good" and accidentally lose all their data.
True, e2ee is pretty scary as far as data loss.
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.
Yeah Immich and Ente are going for two different use cases. While Ente can be self hosted, I view it as more of an escape hatch if they ever enshittify vs how I would start off using the service. I like not having to manage ingress for a photos service so my family can use it but others cannot
I think the application layer is the wrong layer for encryption for immich anyways, I just encrypt the whole disk on my server. When _self_ hosting, there's no need to prevent access to files from the operator.
To me there are two good products: Immich and Ente.
* 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.
>So many comments here about missing end to end encryption, but seriously - why would anyone want this?
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?
I want to host an instance for me and my family. Right now we have a Google One instance shared by 5 people. Having e2e means my family members can rest assured that I or whoever I share admin rights with cannot look at their private photos. It's an important enough feature even without thinking about 3rd party bad actors.
I agree, we used to have photo albums in cupboards, and they used to get burnt if the house burned down, or water damaged if the boiler broke, or even stolen. Now we have them digitally and we can back them up off-site. That's all the change I need with immich.
To fully encrypt them would just be inviting more problems.
This actually happened to me, without getting into the specifics, a family member with mental issues took all the childhood photo albums and burned them.
If they steal your homelab, e2ee doesn't help, it's encryption at rest. E2ee is for rogue devices sniffing the network, which is more or less of a concern depending on your setup. I'd not have unencrypted traffic in my network if I had for instance those shady TV boxes.
That’s incorrect. E2EE means encrypted data leaves the device, stored encrypted, and server(s) have no keys to decrypt it, only your (or other) client software does.
It's encryption both at rest and on transit. At rest there are levels of encryption, at object level or at filesystem level. E2ee for immich would mean the objects are encrypted and transmitting the data is encrypted. If the scenario is the server is stolen, you need encryption at rest. Even at FS level is enough.
Not sure why you're continuing to argue, GP's right.
e2ee means that the encryption keys are stored client-side by the intended recipient. It's not just in transit and in rest.
I've seen a lot of companies use "e2ee" to basically just mean encryption during transit, not even in rest. It's wrong, but I can see where this idea can propagate.
That’s actually true, but that’s a different issue - companies lying in their marketing materials, making claims that do not match the reality (or well-established definitions, if a company choses to mean something else and call that E2EE).
Freedom of speech
yes that does guarantee you the right to espouse stupid opinion, correct!
This. I think encryption is the job of the underlying operating system not the app running on top of it
e2e is not for rogue devices sniffing the network. TLS protects against that without any E2E.
TLS?
I have an use case.
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.)
I have no idea, I use wireguard to access it. I have disk encryption setup. They'd need to hack my linux server SSH which I have protection turned on to shut it down after failed attempts. It would be a challenge to get access to my photos on disk. They could steal my phone and access through the app if they could get them all before I disabled access since Im using encrypted icloud account.
In the end who would want all my photos for that amount of work lol?
You know why. I know why.
The people who care about this disproportionately collect distasteful media and would be in criminal proceedings if their material was uncovered.
I just want to be able to share my hosted service with other people and not have the responsibility of being able to access their photos. Me or anyone that happens to gain access to my server.
You seem to be mixing up e2e encryption with at-rest-encryption?
If you have a server in your homelab where you self-host I mich just encrypt the hard drive with LUKS.
You solve this by communicating with it via encrypted methods, like HTTPS, and using a storage volume that is encrypted and gets unlocked at boot.
Privacy extremists are always very vocal but most people do not care at all about this.
Maybe people have pornography production streams they want to manage using Immmich?
Im wary about having my PII hosted on vpses which I suppose makes me a privacy nut. I just host immich on an old laptop and use the VPS to establish a wireguard tunnel.
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.
Agreed. It's especially frustrating to read of extremely high standard (even though justified, I'm not suggesting it's OK to have a subpar experience) while most people just share everything and anything on Facebook, TikTok, SharePoint, etc and have no idea what permissions even mean.
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!
When I was switching to GrapheneOS from iOS, I decided to self host my photos. I considered Immich, but I settled on Ente because of the encryption. Ente Photos is extremely polished and it's comparable quality to Apple photos.
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.
> Ente Photos is extremely polished and it's comparable quality to Apple photos.
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.
Well I'm a complete newb, self-hosted it completely by just following instructions from GLM 4.7 (didn't log in) and it works reliably.
Did you try it with the free 10GB on their hosted servers?
I'm using Android so maybe it's different on iOS.
for people wondering:
"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...
https://github.com/ente/ente
I've been bitten too many times - is Ente a commercial product that pays lip service to self hosting as form of marketing, but with friction to guide you towards the hosted version (e.g. rocketchat and many others) or does it genuinely support self hosting as a first class product?
I self host it and it's polished.
The latter, it works quite well
Ente Auth is also the best, because it works on any device, including the one you're trying to access (maybe it defeats the purpose of 2FA but sometimes I don't care).
I use and like Ente Photos a lot but I’ve never understood the appeal of their other products.
Ente Auth and Locker both seem like limited feature subsets of solutions like 1Password.
Ente auth is a really nice secure and private cloud authenticator.
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.
I guess the free-ness of auth and I think locker is included with any photos subscription so maybe that’s the appeal.
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.
Ente is a cool company, all their products feel polished and I like their marketing mascots.
I got into Ente because I wanted to create photo upload links on a per-even basis - I can tell all my friends, if you take pics or video tonight, upload it at this URL - and it just works. No app necessary, very simple, very cheap. Then from there, I got the photo backup / archive service because why not.
They really are pretty much just what they appear to be. Im a fan.
For what it's worth, Immich supports this too. You can create an album (for each event), create a shared link, allow public anonymous uploads for the shared link, and then give the link to everyone at the event, and ask them to upload their photos. It can be done from any web browser.
I would love to know if there's a way to secure this though. I'm not prepared to have people constantly trying to login to my immich instance so it's only accessible via VPN
You can use something like Immich Public Proxy to only expose the /share path of your server and keep the main /api path that has everything else behind VPN
Awesome!!!
Immich is such a no-brainer replacement for Apple Photos or Google Photos, combined with VPN like Tailscale, it's almost a drop in replacement
Beware that migrating back from Immich to iCloud/Google is not something Immich cares about. There is no "download all" anywhere, best way is to go to the server and get raw files from there.
https://github.com/immich-app/immich/discussions/14365
They’re literally on a disk drive I can physically touch. I think I can figure out a migration strategy for that.
It's tricky with iOS. Plugging iPhone into a server is stupid. Adding server as a network storage in Files app is smarter, but downloading photos this way does not guarantee deduplication. Would be great if Immmich iOS app had a restore functionality as convenient as existing backup functionality.
You migrate from the server, not the client. You seem confused about what Immich is.
The immediately obvious and simple to handle on-disk format for everything I cared about was one of the things that convinced me to give it a try. Well-crafted exporters are great and all, but I really like being confident that I can convert it by hand even if the company ceases to exist.
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.
This is symptoms of a chronically cloud-native brain. What is a file system?
what do you mean download all? its your server over your files. If you want them, go get them! Or just point google / apple / whatever upload at your library directory.
A download button would be great but the files are already stored on the device you can copy them with a usb or go on the device and upload it directly.
maybe I fail to see your point, but following the link, then https://github.com/immich-app/immich/discussions/5068 is referenced which is resolved by pr https://github.com/immich-app/immich/pull/18878 adding bulk download functionality (may have manually select all to bulk download, unsure). At any rate I don't see where they say explicitly that they are against it
[dead]
There’s no download all in apple photos either unless they added it
Yes, that's even more stupid! Best way to export photos from iCloud if you don't have mac is to use iCloud from the browser and bulk download from there, but it has a 10k files-per download limit! It also doesn't allow you to select all and partiton download this way, I had to manually increase selection until it's 10k and remember where I started.
You can download all you Apple data now, including photos.
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.
And yet, the same is true for Apple photos about ease of export:
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.
Or you can get all you data from https://privacy.apple.com/account
CMD-A then export all X unmodified originals works fine
Except when your library is huge: https://www.reddit.com/r/ios/comments/15sa6vg/how_to_downloa...
It's just files on a disc drive. Why do you need a button for this?
Maybe I'm missing something but the linked discussion has a link to a closed issue that links a PR that added the feature you say is missing.
I put all my files in a folder. I’d simply get them there. No concern about this at all.
Are there any side effects of leaving Immich public? I think people overestimate the risks. Just update your stuff regularly, follow simple rules, and set up something like CrowdSec. I know it's simpler to just use Tailscale and similar tools, but recently I see the trend that people don't even consider otherwise.
I'd throw it behind Wireguard, personally. Belt and suspenders.
(I keep meaning to look at it and keep kicking it down the road.)
That's what I do. I have Wireguard connected on my iPhone at all times.
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.
> Are there any side effects of leaving Immich public ?
Yes: it is necessary to share selected albums through public URL.
There is a project, which proxies album requests to a private immich instance, if one doesn't want to expose it: https://github.com/alangrainger/immich-public-proxy
I only wish it would support nested albums (or albums in folders) so it could be an easy replacement for lightroom cloud as well.
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.
You can use tags for this, they nest nicely
I’ve been using photoprism. Should I switch?
I'm in the same boat, and have been meaning to try immich but slightly worried about migration effort. Should I import fresh into Immich or setup my existing photoprism as an external library? I think the former is probably correct, but the latter might be easier?
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.
Give it a try, Immich is truly wonderful. Rich in features, polished UX, it's now better than Google Photos.
Is there any side effects of leaving the phone connected to Tailscale VPN all day?
I can only comment about battery life. It's proportinal to how much tailscale is really being used: If you use tailscale with an "exit node", i.e. all traffic is routed through it and it's working continously, it drains battery. If it's only used for services on your tailnet, e.g. Immich, the impact will be very small.
I have a static route configured on my home's gateway that enables any device on my network to access Tailscale. I have Tailscale turned on my iPhone pretty much all the time anyway, but even if I didn't I'd still be able to access services I have hosted that are only accessible on my tailnet.
Could impact battery usage, possibly?
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.
Here's some data. Well, technically anecdata, I suppose.
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.
Okay, not bad at all then. I've never left it on for long, so I wasn't really sure.
On an older iPhone, my Settings shows 3% going toward Tailscale.
If you are okay with internet exposure on some level, Cloudflare Tunnel is a really fantastic product:
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.
Note that Cloudflare Tunnel blocks requests above 100MiB, which makes it impossible to upload long videos. This is being addressed in https://github.com/immich-app/immich/pull/22385
Oh good callout, I had only tried it for not-giant-upload services.
[dead]
If Tailscale is on, I can't concurrently run a DNS-blocking local VPN, so I see ads in mobile Chrome.
I use nextdns with tailscale.
https://tailscale.com/docs/integrations/nextdns
Put a Pihole container on your homelab which you have the Tailscale exit node on and then set it as the forced Tailnet DNS.
Could host it in the tailnet?
You can but it’s a lot slower.
I remember having problems using tailscale vpn 24/7 and pihole on my home network with the phone pointed at the 192.168 address for DNS. Pages would take 5s to resolve and start loading.
Unfortunately, Pihole was less important than Tailscale and I have to put up with mobile ads.
If you're on Android and don't like mobile ads [Morphe](https://morphe.software/) might be worth a look.
I'm on iPhone, i found a workaround involving having headscale set the dns using 'magicdns' or something and having that pihole join the tailnet. after that everything is mostly groovy but the individual components don't easily seem to be able to connect to a different vpn.
No lots of people including myself do this for homelab access purposes it just works (tm).
I leave my phone connected 24/7 and don’t notice any downsides. Only have to disable it on some networks when traveling to make awful captive portals work.
i've had tailscale almost permanently enabled for a couple of years at this point and it's never a problem (ios, nextdns with a tailscale specific profile rather than a pihole or something)
There's a lot of things I spent a ton of time setting up, use once, and then never again. Tons of things that are easy to set up, and provide small benefits every day for a long time. Immich has got to be the thing that I've spent ages setting up, use extremely infrequently but the one time a year I use it I'm so happy I did. Great software.
Man, I wish my experience was as nice. I used the proxmox lxc for it and after a 2 months of organizing I had some corruption and didn't have the fortitude to get through the debugging. It might have been related to a big version migration if I remember correctly. It turned me off the stack. The upgrading wasn't as turnkey as I wanted it to be and I dont think the case is different today.
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.
I'm not sure I will ever upgrade Immich again. When I upgraded to the next minor version (I forget which off the top of my head), the data migration corrupted my database such that no images would be served. Fortunately I had the old database backed up, so I restored it, rolled back to the older version of Immich, and things were back to normal. I like Immich, but this is not good for software that's beyond the first major version, and also handles archiving people's personal data.
> Fortunately I had the old database backed up
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 had an issue where my thumbnails were borked somehow, so I deleted them all. However, I didn't delete the database entries, so they never got regenerated.
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.
In proxmox restoring a backup is really easy, I'm surprised you didn't do that!
Yes! Or even better, use Proxmox snapshots during upgrades for easy rollback on failure
if you have a PBS its just incredibly simple.
[dead]
In my case I spent it not so much time setting it up, some time upgrading with some manual work required from time to time with breaking changes (but not so often) and I use it weekly, it just works and it's wonderful.
[dead]
Does anyone have any pointers on the best way to import roughly 14 Google takeout chunks into 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.
If you can get all the images into a filesystem (on a NAS or similar server share), you can use the External Libraries feature in Immich (https://docs.immich.app/features/libraries/). This allows it to crunch through the media files via an async import job (a bit more reliable than having to directly upload via the web api).
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!
This is a good usage pattern if you're absolutely married to the file structure you have and/or want to keep using the files where they are.
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
I went through the same path as you - I think I even landed up with 14 takeout files as well!
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.
> 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".
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.
You can use this tool to get them into Immich, it will parse all the metadata and recreate albums as you have in GPhotos https://github.com/simulot/immich-go
Oh wow, it recreates the Google Photos albums? That's the first time I've heard of a tool doing that. I've spent a ton of time organizing my Google Photos albums, that's a big reason I stay with it.
Likely not the best approach:
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.
immich-go has what you need
This! When you have the pictures on your disk just use immich-go to import them.
Just a quick note that native windows extract is 32bit and dies on archives gt 4gb. Use 7zip or something to extract in case you happen to be using that one.
Has the ios photo sync gotten better? I've got 20k photos on my phone, and last I tried it filled up the storage on my phone with the originals, and never completed the process, even after leaving my phone open, unlocked, and the immich app running in the foreground for several days, on the same local network as the server.
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.
I have a largish library at about 400gb. I synced it completely using the mobile app. It took a few months (it just finished in early June) but it’ll eventually do it. I know there are other ways but I figured this was the laziest way to do it.
I have synced ~9000 photos from my phone in february. That worked pretty well. I was done in about 10 hours. I don't remember whether the originals were downloaded, or whether they were deleted automatically afterwards. Felt like a smooth process though.
The release notes says:
> 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.
Large file uploads are non-resumable. That is, if you have any videos at a decent bitrate and resolution, you need to be able to upload the whole file in a single session. iOS doesn't make this easy to do via background uploads. I uploaded everything by keeping the app open overnight.
Sync was already fixed in the last major version, at least for us (android and iphone)
Likely more of an IOS issue than Immich issue. Apple doesn't care for apps that make it easier to exit iCloud.
No, it’s an Immich issue. Not OP, but I was already using Synology Photos. Synology finished syncing my library in two days, while Immich was still syncing after more than a week. I decided it wasn’t worth it after that experience.
Why are you syncing from your phone instead of your Synology then? Can't you sync from your NAS then just have pictures uploaded as you take them? iOS has a lot of restrictions compared to Android so two days really doesn't feel like a meaningful difference from a week.
The 2 days were spent uploading my entire library from scratch. After that, daily syncs only take a few minutes.
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’m not an Immich or Synology user but essentially the mobile apps end up replicating your whole structure a little better, at least when I did the iCloud library to Ente import.
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.
I have a different bash with them than the lack of E2EE: they do not make it easy to import from other servicesvlike Google Photos or iCloud, which should be a priority.
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!
> 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.
They make money on that, it's not just a hobby project
Their business model is basically donations, it's not a for-profit operation. Maybe if you consider yourself less of a customer and more the beneficiary of a community effort, it'll be easier to "get"
Don't patronize me, my arguments still stand: they offer all bells and whistles while completely dropping the ball at making you feel those photos are well taken care of. The core employees live off of Immich so spare me the spiel.
In the same universe, I took a google takeout last week to migrate to immich, 12k photos/videos.
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.
It seemed like that for me, too, until I realized my photos were botched. The only way to know that was looking into the logs: I have some 9000 photos which it silently fails to extract metadata from. The only sign in the UI that something is off is the fact those 9k photos never get processed, you can try in perpetuity. The logs reveal they were botched either by immich-go or iOS app, ffmpeg freaks out when processing them. After checking in the gallery they're indeed messed up.
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.
> mmich 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.
> How do you imagine this wold work
The way it CURRENTLY already works. Through Google/iCloud takouts, or the Android/iOS apps if user chooses to do so.
You can't provide an easy UX-friendly alternative to takeout, and it already backups photos through Android/iOS apps if user choses so.
The amount of entitlement on display here is astounding.
What entitlement? Did I say I DEMAND something? DID I? You can't criticize a free project because God forbid that makes you entitled?
And how do you know I haven't donated and don't regularly do so?
If I had to guess, the last paragraph of your original comment comes across as very harsh.
I don't see it. I made a remark that nice-to-haves are less important than the bare essentials. And I don't get how this quasi-commercial product doesn't have this locked in, despite them making an every effort to come off as polished.
> they do not make it easy to import from other servicesvlike Google Photos or iCloud
Because those services are closed black boxes that don't really let you access them except in a very roundabout way?
No. They're not. You export photos using Google Takeout, iCloud has something similar. And their own iOS app also has unresolved bugs because of which I can't fully import my gallery.
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.
> No. They're not. You export photos using Google Takeout, iCloud has something similar.
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/
This is why I said A-B testing would be important.
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?
> 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).
Immich is an amazing software. I use it regularly as an alternative along side Google photos. I keep in it large videos that I wouldn't upload normally to Google photos + the snappy experience at home vs Cloud-Bades solution.
I wish they would better support external image sources - images not uploaded/managed by Immich, just a folder of images it has access to - especially if it's read only. It mostly works, but the UI and logic breaks in a lot of little ways.
We know, and it's something we're working on. The plan is to unify the external and internal libraries in a better way
Yup. I love Immich, but I'm also a control freak, so my 25 years of digital photos I had before using Immich still exist in an External Library. It mostly works but I still have some issues. Like I keep getting a batch of ~70 photos that lose their "date taken" and revert to the date/time I started using Immich. (Fortunately the file names are date/times and I can manually go through and fix them, but having done it at least three times, it's getting old!)
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!
Does Immich support read-only source folders yet? I'd like to keep the original files intact, but allow Immich to index them.
Yes, at least for a year. There is a ”external library” feature, I think that does what you want.
Thank you! That was not available the last time I checked.
It's been available for nearly three years
Yes, using external libraries. It's been a feature for several years. Make it read-only by mounting docker compose read only
[dead]
How does the mobile app sync work with Immich? My use-case is that I want to install the mobile app on the phone of my relatives (including iPhones), and it should keep syncing their pictures "forever" even though they never, ever open the app.
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.
With works for me on Android with Pixel phone, after I added Immich to the list of apps that can work in the background.
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.
Yeah I saw that, which suggests that it was not totally working before. Not criticising of course, I know it's hard especially on iOS.
> 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?
> Upload asset directly to album on the mobile app
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.
Migrated 700GB of photos from Google to local Immich. The whole family uses it and we’re happy to be supporting the project!
Immich is the best self-hosted app I use. Hats off to the developers!
Has anyone personally upgraded to 3.0? How is the experience?
docker compose down
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.
[dead]
I have come to the realisation that I don't need 10,000 photos. I probably need < 100. I will print them and keep them in a paper album...
Which I am yet to do...
My wife only printed the 6 photo albums because I gathered all our photos from three different Google Photos accounts, a hard drive, and two laptops.
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.
Print them, absolutely, you won't regret it! But it's also good to keep a local and locally owned digital version neatly organized.
And where is the pool you pick these 100 photos from?
local hard drives..
I have realized the same.
Only it is different 100 photos every year.
Shameless plug: I made a native iOS/Mac app that's adjacent to Immich, but narrower in scope. It focuses on local image search and photo organization.
Everything is indexed and searched locally, so the photos never leave the device.
https://photos.getsupercurate.com
Great app! Great to see the progress with it.
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.
I've been self hosting immich for the past 6 months. It's pretty awesome. The App has some performance issues but the web is flawless. I cut down on my iCloud plan since I deleted most of my videos from it. I use restic to manage backups with my own key offsite.
I would switch immediately if they added support for non-photo elements in albums like google photo has. E.g. texts and maps. And the option to chose the order of album elements yourself.
These make my albums feel like small blogs which really adds to the experience when sharing e.g. travel albums.
Does it have image editing tools like rotate and crop and is it aware of basic exif metadata?
yes. https://docs.immich.app/features/editing/ And it is very aware of exif. It also has AI features to analyze the photos (or videos) and you can for example search for "cat" and it will find all photos with cats.
Yes. But it's not editor. You don't have manual export, you crop/rotate thumbnails which might not be suitable for print for example.
I have a bunch of spare s3 compatable storage from a cloud provider which I would really like to use to run Immich, but everytime i look into it it seems not possible.
Immich is amazing, been using it as a backup since my phone is always full
I got annoyed with Immich and external storage, because in order for every user to have their own facial recognition data on a large set of photos, you have to add the folder as external storage for each user, which means image previews for each user, even though the source image is the same. So if you have 3 users, you use up 3 times the space for the same thumbnail image.
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.
I don't think that has changed, but AFAIK is on the Roadmap. Or at least they talked about it.
My only disappointment with this release is that the beta version of workflows does not have the ability to sort photos into albums by face detected (yet). That’s what I’ve been waiting for as both Google Photos and Ente support smart albums
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]
I don't want yet another self hosted service to manage (update, backups, possible hardware failures, energy costs, ups, etc.).
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 :-)
Okay? So don't use it, use a managed service like Google Photos, Apple Photos, Dropbox, etc where your photos and files might be arbitrarily removed or your access to them limited while they are scanned for disavowed content.
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.
What do you mean Immich is not end-to-end encrypted? You control both ends, you can encrypt it any way you want…
They said they only want to control one of the ends
Fair enough, but the Immich provider they link to also uses SSL and claims to encrypt at rest.
It they don’t consider that e2e encrypted, literally nothing is then…
Encryption at rest means they have the key. End to end means they don‘t. Huge difference!
Yes but magical homomorphic encryption aside, the person has conflicting requests at that point. They are asking for an image app that can’t view their images.
That’s not an image app anymore, that’s just encrypted storage.
I think the idea is that the images are decrypted by the client. See how Ente does it: https://ente.com/architecture
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.
You can have immich on truenas that has the whole pool encrypted, same goes with opencloud for other docs/files. Plus all nas backup features, I think it’s a better approach than dealing with each app encryption.
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.
VPN (or other) Tunnel.
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.
It's also a kind of funny thing how HN has the attitude of "never implement your own encrypted anything" but then demand their apps build in e2e encryption. It may be one abstraction higher, but it's still fundamentally the same problem. With the unfortunate exception of web browsers, if I'm going to use something that performs encryption, then I want encryption to be the only job it has.
How are VPNs related to end-to-end encryption?
Their primary purpose is usually encrypt the connection between different endpoints… by creating virtual private networks…
When we talk about "E2EE" messenger apps, that usually means more than just using HTTPS. VPNs can certainly help with encryption in transit, but that's a very different concept.
Unfortunately this comes up a lot, with people asking if Immich supports end-to-end encryption and getting told to use LUKS or Tailscale.
I believe OP meant at rest encryption, meaning, just because someone had an access to your physical drive doesn’t mean they can browse your pics.
If you don’t want self-hosted and you want E2EE, Ente Photos is the best solution on the market that I have found.
Thank you for the tip! Luckily there are some useful and thoughtful commenters on HN too, other than all the downvotes and negativity :-)
Apparently HN does not like "not self hosting" and/or "e2e encryption" ?
Meanwhile, i also found https://zeitkapsl.eu/
Thanks for the other recommendation, it doesn’t hurt to know of more of them.
So if you don't want a self hosted service there are tons of cloud providers. Google photos, iCloud, etc. Some people don't want to pay a monthly fee to store their photos or don't want to risk losing something with sentimental value just because a company decides to ban you
There are simpler options now to self-host these kinds of apps. It's not that hard anymore
Sure!
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.
Valid points. But I see self-hosting even as renting a VPS from someone and running the service there. Which solves most of the dev ops problems that I dont wanna bother with. Maybe it's not "actual" self-hosting, but concenient enough to use it
it's really not much to manage assuming you are already doing backups. you ~ pay the energy cost either way.
Lessons from using self hosted image services years ago:
- 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.
> Lessons from using self hosted image services years ago:
Alternate title: "Outdated lessons I haven't re-evaluated"
Are you saying there are never backward incompatible changes?
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?
I'm saying your contribution is outdated and irrelevant, and my primary intention in commenting is to label it as such for any passers-by who might think you're talking about the current state Immich.
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.
I'm glad you're happy with it, and perhaps Immich will continue to remain secure. 3 years is comforting.
I will note that the last solution I used was fine for over a decade before it broke (and eventually the project died). For much of the time I was using it, it was the primary open source self hosting solution.
So one of my criteria is: "If the project dies, can I maintain it?" Obviously, I can't use that approach for everything (limited skills and time) - I do use NextCloud, for instance (which, BTW, is fairly painful for some of the reasons I listed above). But wherever I can (and wherever it's important), it's best to develop your own stack.
Best to think in the long term. But yes, for sure, there are down sides to my approach.
You can use https://ente.com/ (it's open-source). It also makes the seemingly much better decision of storing photos in S3.
The point of Immich is self hosting. Using AWS defeats that purpose
S3 has many open implementations you can self host. Some are quite lean even. Unless you need really complex IAM stuff it's a solid and rather simple experience to run it.
This is a good point. I'd rather have something with the S3 option, so I can serve the pages from my house but the images from a speedier source.
Yeah but Immich provides a lot more features than just storage
Wouldn't it then be reasonable to focus on those many features, instead of storage? I would enjoy using with S3, as expanding S3 storage is easier than expanding the storage of a virtual machine: usually it happens automatically.
Of course this topic has been discussed: https://github.com/immich-app/immich/discussions/1683
Perfect is the enemy of the good. While there's an ideal case where you're hosting it on a box in your house, that's not for everybody. So while hosting it on AWS doesn't remove every dependency on big tech, at least it's not a full on Google hosted SaaS product.
I think "perfect is the enemy of good" is actually an argument against AWS integration. Using S3 as a backend is a lot more complex than using local storage so it would take a lot more time to implement, that's why local storage is good enough
Only if we look at resources it takes to implement features as limited and we're in starvation mode. With AI writing code these days, if they choose to use it, it's less about the resources to make the features and more about what having the features enables.
Ente’s cloud-hosted solution does not use S3:
https://ente.com/reliability/
For self-hosting, “S3” usually just means “S3-compatible.” Although maybe that’s exactly what you meant.
+1 for Ente. Replaced Google photos for me
Thank you for the tip! Luckily there are some useful and thoughtful commenters on HN too, other than all the downvotes and negativity :-)
Apparently HN does not like "not self hosting" and/or "e2e encryption" ?
Meanwhile, i also found https://zeitkapsl.eu/
I think I dug my own grave by not being explicit that I thought S3 as a protocol and not the AWS product. :)
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.
> I don't want yet another self hosted service to manage
Isn't system administration a solved problem now with LLMs? At least for these simple problem domains?
[dead]