zlacker

[return to "Self-hosting my photos with Immich"]
1. trizic+QMj[view] [source] 2025-12-06 06:19:03
>>birdcu+(OP)
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.

◧◩
2. Dedime+wPj[view] [source] 2025-12-06 07:01:22
>>trizic+QMj
My problem with NixOS is the second you try to go "outside the guardrails", the difficulty increases 100x
◧◩◪
3. lilyba+U8k[view] [source] 2025-12-06 11:34:19
>>Dedime+wPj
Is it? Why? If a NixOS module doesn’t support what you need, you can just write your own module, and the module system lets you disable existing modules if you need to. Doing anything custom this way still feels easier than doing it in an imperative world.
◧◩◪◨
4. maccar+Hek[view] [source] 2025-12-06 12:41:59
>>lilyba+U8k
> you can just write your own module, and the module system lets you disable existing modules if you need to

That sounds about 100x more difficult to me

◧◩◪◨⬒
5. Scandi+Zjk[view] [source] 2025-12-06 13:27:37
>>maccar+Hek
I can see your point that it can be daunting to have all the pain upfront. When I was using Ubuntu on my servers it was super simple to get things running

The problem was when I had to change some obscure .ini file in /etc for a dependency to something new I was setting up. Three days later I'd realise something unrelated had stopped working and then had to figure out which change in the last many days caused this

For me this is at least 100x more difficult than writing a Nix module, because I'm simply not good at documenting my changes in parallel with making them

For others this might not be a problem, so then an imperative solution might be the best choice

Having used Nix and NixOS for the past 6-7 years, I honestly can't imagine myself using anything than declarative configuration again - but again, it's just a good fit for me and how my mind works

◧◩◪◨⬒⬓
6. onioni+Nmk[view] [source] 2025-12-06 13:54:11
>>Scandi+Zjk
In the NixOS scenario you described, what keeps you from finding an unrelated thing stopped working three days later and having to find what changed?

I’m asking because you spoke to me when you said “because I'm simply not good at documenting my changes in parallel with making them”, and I want to understand if NixOS is something I should look into. There are all kinds of things like immich that I don’t use because I don’t want the personal tech debt of maintaining them.

◧◩◪◨⬒⬓⬔
7. Scandi+Vtk[view] [source] 2025-12-06 14:59:03
>>onioni+Nmk
I think the sibling answer by oasisaimlessly is really good. I'd supplement it by saying that because you can have the entire configuration in a git repo, you can see what you've changed at what point in time

I'm the beginning I was doing one change, writing that change down in some log, then doing another change (this I'll mess up in about five minutes)

Now I'm creating a new commit, writing a description for it to help myself remember what I'm doing and then changing the Nix code. I can then review everything I've changed on the system by doing a simple diff. If something breaks I can look at my commit history and see every change I've ever made

It does still have some overhead in terms of keeping a clean commut history. I occasionally get distracted by other issues while working and I'll have to split the changes into two different commits, but I can do that after I've checked everything works, so it becomes a step at the end where I can focus fully on it instead of yet another thing I need to keep track of mentally

◧◩◪◨⬒⬓⬔⧯
8. maccar+0Nk[view] [source] 2025-12-06 17:30:36
>>Scandi+Vtk
> because you can have the entire configuration in a git repo, you can see what you've changed at what point in time

That’s true of docker too.

◧◩◪◨⬒⬓⬔⧯▣
9. Scandi+cQk[view] [source] 2025-12-06 17:55:52
>>maccar+0Nk
I'm not really sure what your point is, but I'll try to take it in good faith and read it as "why doesn't docker solve the problem for it, since you can also keep those configurations in a git repo?"

If any kind of apt upgrade or similar command is run in a dockerfile, it is no longer reproducible. Because of this it's necessary to keep track of which dockerfiles do that and keep track of when a build was performed; that's more out-of-band logging. With NixOS I will get the exact same system configuration if I build the same commit (barring some very exotic edge cases)

Besides that, docker still needs to run on a system, which must also be maintained, so Docker only partly addresses a subset of the issue

If Docker works for you and you're not facing any issues with such a setup, then that's great. NixOS is the best solution for me

◧◩◪◨⬒⬓⬔⧯▣▦
10. maccar+G0l[view] [source] 2025-12-06 19:17:53
>>Scandi+cQk
That’s all my point was, yeah. Genuinely no extra snark intended.

> it is no longer reproducible

The problem I have with this is that most of the software I use isn’t reproducible, and reproducible isn’t something that is the be all and end all to me. If you want reproducible then yes nix is the only game in town, but if you want strong versioning with source controlled configuration, containers are 1000x easier and give you 95% of the benefit

> docker still needs to run on a system

This is a fair point but very little of that system impacts the app you’re running in a container, and if you’re regularly breaking running containers due to poking around in the host, you’re likely going to do it by running some similar command whether the OS wants you to do it or not.

◧◩◪◨⬒⬓⬔⧯▣▦▧
11. Scandi+47l[view] [source] 2025-12-06 20:11:28
>>maccar+G0l
> if you want strong versioning with source controlled configuration, containers are 1000x easier and give you 95% of the benefit

For some I'm sure that's the case; it wasn't in my case.

I ran docker for several years before. First docker-compose, then docker swarm, finally Nomad.

Getting things running is pretty fast, but handling volumes, backups, upgrades of anything in the stack (OS, scheduler, containers, etc) broke something almost every time - doing an update to a new release of Ubuntu would pretty much always require backing up all the volumes and local state to external media, wiping the disk, installing the new version, and restoring from the backup

That's not to talk about getting things running after an issue. Because a lot of configuration can't be done through docker envs, it has to be done through the service. As a consequence that config is now state

I had an nvme fail on me six months ago. Recovering was as simple as swapping the drive, booting the install media, install the OS, and transfering the most recent backup before rebooting

Took about 1.5 hours and everything was back up and running without any issues

[go to top]