Most active commenters
  • teekert(3)

←back to thread

Self-hosting my photos with Immich

(michael.stapelberg.ch)
659 points birdculture | 19 comments | 30 Nov 25 09:11 UTC | HN request time: 0.835s | source | bottom
Show context
trizic ◴[06 Dec 25 06:19 UTC] No.46171151[source]▶
There is something to be said about NixOS, it really is a matter of setting `services.immich.enable = true;` in a configuration file. I find this really powerful and simpler than docker and docker-compose. But don't get me wrong, I am all for containerization when it comes to other OS/distros. Yes, there is a learning curve for the Nix language and creating your own packages. But anyone who can install a distro can install NixOS. Instead of running your apt/dnf/pacman commands, you edit a file with your package names and services you want to enable, and run `nixos-rebuild switch`. Though, you might find standalone binaries such as uv and its portable Python bundles don't work out the box, there is a a few lines configuration to get it working. Having a single language for configuring all services/applications (neovim,nginx,syncthing,systemd, etc) is refreshing. And of course combined with generative AI, you can set up a lot quickly.

Immich is one of the only apps on iOS that properly does background sync. There is also PhotoSync which is notable for working properly with background sync. I'll take a wild guess that Ente may have got this working right too (at least I'd hope). This works around the limitation that iOS apps can't really run as background apps (appears to me that the app can wake up on some interval, run/sync for a little and try again on the next interval). This is much more usable then for example, the Synology apps for photo sync, which is, the last time I tried, for some reason insanely slow and the phone needs to have the app open and screen on for it fully sync.

Some issues I ran into is the Immich iOS app updating and then being incompatible with the older version of the server installed on my machine. You'd have to disable app updates for all apps, as iOS doesn't support disabling updates for individual apps.

In my specific scenario, the latest version of Immich for NixOS didn't perform a certain migration for my older version of Immich. I had to track down the specific commit that contained the version of Immich which had the migration, apply that, then I was able to get back to the latest version. Luckily, even though I probably applied a few versions before getting the right one, it didn't corrupt the Immich install.

replies(12): >>46171173 #>>46171252 #>>46171317 #>>46171389 #>>46171443 #>>46171602 #>>46172468 #>>46172554 #>>46172583 #>>46174712 #>>46174895 #>>46175288 #
1. kalaksi ◴[06 Dec 25 06:43 UTC] No.46171252[source]▶
I'm running NixOS on some of my hosts, but I still don't fully commit to configuring everything with nix, just the base system, and I prefer docker-compose for the actual services. I do it similarly with Debian hosts using cloud-init (nix is a lot better, though).

The reason is that I want to keep the services in a portable/distro-agnostic format and decoupled from the base system, so I'm not tied too much to a single distro and can manage them separately.

replies(2): >>46171284 #>>46171710 #
2. quag ◴[06 Dec 25 06:51 UTC] No.46171284[source]▶
How do you update the software in the containers when new versions come out or vulnerabilities are actively being exploited?

My understanding is that when using containers updating is an ordeal and you avoid the need my never exposing the services to the internet.

replies(4): >>46171301 #>>46171440 #>>46172144 #>>46172466 #
3. wwarek ◴[06 Dec 25 06:57 UTC] No.46171301[source]▶
> How do you update the software in the containers when new versions come out or vulnerabilities are actively being exploited?

You build new image with updated/patched versions of packages and then replace your vulnerable container with a new one, created from new image

replies(1): >>46172133 #
4. RadiozRadioz ◴[06 Dec 25 07:35 UTC] No.46171440[source]▶
If you're the one building the image, rebuild with newer versions of constituent software and re-create. If you're pulling the image from a public repository (or use a dynamic tag), bump the version number you're pulling and re-create. Several automations exist for both, if you're into automatic updates.

To me, that workflow is no more arduous than what one would do with apt/rpm - rebuild package & install, or just install.

How does one do it on nix? Bump version in a config and install? Seems similar

replies(1): >>46174474 #
5. halz ◴[06 Dec 25 08:43 UTC] No.46171710[source]▶
Ditto on having services expressed in more portable/cross distro containers. With NixOS in particular, I've found the best of both worlds by using podman quadlets via this flake in particular https://github.com/SEIAROTg/quadlet-nix
6. teekert ◴[06 Dec 25 10:12 UTC] No.46172133{3}[source]▶
Am I the only one surprised that this is a serious discussion in 2025?
replies(2): >>46172365 #>>46174833 #
7. teekert ◴[06 Dec 25 10:15 UTC] No.46172144[source]▶
Your understanding of containers is incorrect!

Containers decouple programs from their state. The state/data live outside the container so the container itself is disposable and can be discarded and rebuild cheaply. Of course there need to be some provisions for when the state (ie schema) needs to be updated by the containerized software. But that is the same as for non-containerized services.

I'm a bit surprised this has to be explained in 2025, what field do you work in?

replies(3): >>46173603 #>>46173863 #>>46173968 #
8. AdrianB1 ◴[06 Dec 25 11:04 UTC] No.46172365{4}[source]▶
Perhaps. There are many people, even in the IT industry, that don't deal with containers at all; think about the Windows apps, games, embedded stuff, etc. Containers are a niche in the grand scheme of things, not the vast majority like some people assume.
replies(1): >>46172566 #
9. corn13read2 ◴[06 Dec 25 11:22 UTC] No.46172466[source]▶
pull new container, stop old and start new. can also make immutable containers.
10. teekert ◴[06 Dec 25 11:44 UTC] No.46172566{5}[source]▶
Really? I'm a biologist, just do some self hosting as a hobby, and need a lot of FOSS software for work. I have experienced containers as nothing other than pervasive. I guess my surprise is just stemming from the fact that I, a non CS person even knows containers and see them as almost unavoidable. But what you say sounds logical.
replies(3): >>46173906 #>>46175300 #>>46175708 #
11. fijiaarone ◴[06 Dec 25 14:26 UTC] No.46173603{3}[source]▶
Your understanding of not-containers is incorrect.

In non-containerized applications, the data & state live outside the application, store in files, database, cache, s3, etc.

In fact, this is the only way containers can decouple programs from state — if it’s already done so by the application. But with containers you have the extra steps of setting up volumes, virtual networks, and port translation.

But I’m not surprised this has to be explained to some people in 2025, considering you probably think that a CPU is something transmitted by a series of tubes from AWS to Vercel that is made obsolete by NVidia NFTs.

12. johannes1234321 ◴[06 Dec 25 15:06 UTC] No.46173863{3}[source]▶
It's not that easy.

First I need to monitor all the dependencies inside my containers, which is half a Linux distribution in many cases.

Then I have to rebuild and mess with all potential issues if software builds ...

Yes, in the happy path it is just a "docker build" which updates stuff from a Linux distro repo and then builds only what is needed, but as soon as the happy path fails this can become really tedious really quickly as all people write their Dockerfiles differently, handle build step differently, use different base Linux distributions, ...

I'm a bit surprised this has to be explained in 2025, what field do you work in?

replies(1): >>46173934 #
13. fwip ◴[06 Dec 25 15:11 UTC] No.46173906{6}[source]▶
Self-hosting and bioinformatics are both great use cases for containers, because you want "just let me run this software somebody else wrote," without caring what language it's in, or looking for rpms, etc etc.

If you're e.g: a Java shop, your company already has a deployment strategy for everything you write, so there's not as much pressure to deploy arbitrary things into production.

14. rkomorn ◴[06 Dec 25 15:15 UTC] No.46173934{4}[source]▶
It does feel like one of the side effects of containers is that now, instead of having to worry about dependencies on one host, you have to worry about dependencies for the host (because you can't just ignore security issues on the host) as well as in every container on said host.

So you go from having to worry about one image + N services to up-to-N images + N services.

15. zelphirkalt ◴[06 Dec 25 15:19 UTC] No.46173968{3}[source]▶
I think you are not too wrong about this.

Just that state _can_ be outside the container, and in most cases should. It doesn't have to be outside the container. A process running in a container can also write files inside the container, in a location not covered by any mount or volume. The downside or upside of this is, that once you down your container, stuff is basically gone, which is why usually the state does live outside, like you are saying.

16. mixedCase ◴[06 Dec 25 16:20 UTC] No.46174474{3}[source]▶
Now do that for 30 services and system config such as firewall, routing if you do that, DNS, and so on and so forth. Nix is a one stop shop to have everything done right, declaratively, and with an easy lock file, unlike Docker.

Doing all that with containers is a spaghetti soup of custom scripts.

17. jbstack ◴[06 Dec 25 17:07 UTC] No.46174833{4}[source]▶
I refer you to:

https://xkcd.com/1053/

18. senbrow ◴[06 Dec 25 18:11 UTC] No.46175300{6}[source]▶
The world is too complex, and life paths too varied, to reliably assume "everyone" in a community or group knows about some fact.

You're usually deep within a social bubble of some sort if you find yourself assuming otherwise.

replies(1): >>46175531 #
19. WarOnPrivacy ◴[06 Dec 25 19:00 UTC] No.46175708{6}[source]▶
I'm a career IT guy who supports biz in my metro area. I've never used docker nor run into it with any of my customers vendors. My current clients are Windows shops across med, pharma, web retail and brick/mortar retail. Virtualization here is hyper-v.

And it this isn't a non-FOSS world. BSD powers firewalls and NAS. About a third of the VMs under my care are *nix.

And as curious as some might be at the lack of dockerism in my world, I'm equally confounded at the lack of compartmentalization in their browsing - using just one browser and that one w/o containers. Why on Earth do folks at this technical level let their internet instances constantly sniff at each other?

But we live where we live.