Supporting Setups other than specific Docker-Setups under Linux

[Subito]

Hi!

this is in part sparked by #14620, which I find really sad. I experimented with different setups under FreeBSD and Linux and came to the conclusion that its really quite risky to have immich working only in one very specific linux-docker stack. Nobody beeing able to help with issues which arose from e.g a different container networking engine is concerning, because that means as soon as just one tiny brick in this carefully curated stack breaks for any reason (docker changing its license for example), I'm out of luck and immich will perform poorly, if at all.

That excludes immich from properly distributed packages for example. Or from all setups which slightly differ from a default. Thats sad, given that Typescript/Javascript should be quite portable.

I'd be willing to help with porting and supporting different stacks, but so far it seems I'm the only one interested? I got near to no response to my issues and ideas on discord, which let me to believe its not something the immich project is interested in.

Lets get this discussion rolling and maybe get immich robust enough that it supports things like podman or different container network interfaces at least. I think that would be a great addition and make immich more resilient and robust in the process. Because for now I experienced it as very flaky and I'm really hesitant to recommend it to anyone who isn't willing or able to stick to a very specific stack.

Thank you for the incredible work you're all doing, I'm really appreciating immich and I'm really glad I found the project!

Keep up the good work,
cheers,
svbito

[bo0tzz]

To address your points in order

1. chore(docs): stronger discouraging of non-Linux installations #14620 is specifically because we keep seeing significant issues with Windows installations, beyond what could be fixed by more explicit support.
2. Containerization is an ubiquitous technology at this point and does not solely rely on docker the software. A license change there would mean changing what default we suggest and support, but would be effectively a non-event.
3. There are community-made alternative installation methods, including for example packages for Arch and Nix. Those work quite well, we just don't officially support them because it isn't worth the time and energy it'd take away from other aspects of Immich.
4. Immich does work on podman and "different container network interfaces" (although I'm not 100% sure on what you mean by that). We just don't suggest them as the default supported option.

[Subito]

Thanks for the quick response!

2. In that case I should try again. But using podman I had frequent timeout errors (to the point where I got a lot of 502 errors on the frontend) and the only response I got on discord was "use docker" - and indeed switching to docker made the problem go away. That left me a bit puzzled and concerned, because I don't like relying on one company to provide me with the neccessary stack for the software I'm running.

3. Thanks for pointing that out! I'll take a look at those and might be able to infer some knowledge about why I had problems in the first place and what I could do better.

4. Podman supports different network backends (sorry for my confusing choice of words). I had trouble using cni, which is deprecated anyways. So maybe once I migrate completely to netavark its a non-issue.

[mmomjian]

In general if you are having issues with a non standard deployment our first answer will be to eliminate variables and go to a known good host. We can’t know how you have podman configured or how the system is running. However podman does work fine but you should be proficient in managing it yourself I suppose.

[bo0tzz]

This, indeed - it's not that alternative setup methods categorically don't work, it's that we don't have the bandwidth to provide support for them if there are issues and so you're expected to fend for yourself a bit more if you choose to venture off the beaten path.

[Subito]

yes, a lot of things were "non standard", but I think there is a lot of value in flexibility and resilience in the face of non-default setups.

I'll go on to try different setups and see where I encounter problems. The biggest issue were timeout errors which I could not really nail down, or even see why the issue was occuring. I suspect the issue was with the database connection, but in the face of an otherwise fresh and empty server that was irritating. And to see the issue disappearing with a different container-engine (and networking-backend) was weird. But thats a seperate thing and impossible to solve without be beeing able to reproduce the issue easily.

Thanks a lot for your thoughtful responses, they helped me to understand your position and I gained a lot of insight about how I can proceed and maybe help out!

[mmomjian]

Hello, thanks for your discussion. To underscore what bo0tzz said, this really should have been named non-UNIX. while our docs are focused on Linux as that is what most new users will install, immich works fine on many *nix platforms and we have a podman guide in our community guides.

At this time we choose to not include this in our mainline docs as the upkeep burden on the dev team will be too great to keep track of so many install methods. However many users use them and if you want to contribute to the external guide or have other changes that would make things easier we would consider them.

Please do remember that immich is written as a fairly robust client-server architecture with multiple services, each of which would be its own daemon on a classic Linux system. So a simple binary distribution is simply not possible. When compared to other projects of our scope I believe we provide a robust and portable code base. Standardized deployment allows us to keep focus on improving the product itself.

[Subito]

Great to see that clarified, thank you! I totally understand not supporting windows as that is really quite the different beast to "another UNIX-like OS".

As mentioned above, I was not aware of the other packages! A big oversight on my part, I'll take a look at them and that will hopefully get me going in the right direction.

I get your point about the different services and I really like that! I was not thinking about a "binary distribution" but rather a distro-package which would be able to provide all the services and set them up as neccessary.

When compared to other projects of our scope I believe we provide a robust and portable code base.

Absolutely true. Once I turned the right knobs (using the recommended install), it was smooth (and incredible fast) sailing. I'll see if I can help out with porting to other distros, even you're not supporting them officially (which I totally get, thats a big burden).