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.
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.
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
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
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/
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.
> 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?
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.
[dead]