Improving immich selfhosting experience on internet-facing & low-power servers

[fyfrey]

Thanks for creating this wonderful project!

I've managed to temporarily setup immich on my small ARM-based single board computer I use for my personal cloud to try immich. So far, I like it a lot - really impressive work!
However, properly selfhosting immich is difficult due to some inconveniences / missing features:

1. Configurability of external services (postgres, redis): Small (e.g. single-board-computer like Rasp. Pi) servers are often low on RAM and cannot run an individual database and redis in docker for each service 😉
   Thus, I'd be great if immich could use postgres & shared redis instances running directly on the host (or in other existing containers). For this, the redis service needs to be configurable (hostname, port, database index) - best case also supporting unix sockets because accessing the host from within docker containers while having an active firewall on the machine is really troublesome (and unix socket have slightly lower overhead compared to TCP). For postgres, again unix sockets would be great due to the same reasons (edit: for postgres, this is already possible, see my answer below).
2. Running containers as non-root user: Currently the immich container use & require root. This is sub-optimal from a security perspective. I configured an unprivileged user in the docker compose file (something like user: 123:123) but the immich services can no longer start. Thus, I would be great if we can run the immich containers with a non-root user (best directly from the start, otherwise with delayed privilege lowering/user switching)
3. Different VITE_SERVER_ENDPOINT for client and SSR: Currently the immich-web docker container needs to access the public endpoint (I my case TLS via nginx)... which requires additional firewall rules and is a bit less performant than directly connecting to immich-server with plain http. (Note: I've seen the existing discussion, while checking if my post is a duplicate, but wanted to list it here again for completeness.)
4. Secure immich with external authentication: Awesome, that this is already in progress in OAuth2.0/OIDC implementation #207
   Hosting internet-facing services with lots of potentially sensitive, private data is significantly safer with 2FA etc.

I'd be glad to create issues for the first 3 points with more details if needed.

By the way: Not really an issue, but I noticed high CPU-usage from npm during startup. Maybe it's building/transpiling the JS code? In that case, it would be better to deploy the pre-built release JS in the docker images. Maybe this also helps with running as non-root user?

Thanks again for the amazing work!

[bertmelis]

I run postgres on a virtual machine so it's not part of the container setup. I didn't have to do any special things to get it running. In the .env file I added the host. I don't know if it works for Redis as wel.

[fyfrey]

Yeah, I've also managed to use the host's postgres server - however, if you set up ufw as firewall you are into some trouble to make that work from docker. Unix sockets would improve the setup experience a lot in this case as it's trivial to mount the socket file into the containers.
Redis should work similarity but cannot be configured yet.

[fyfrey]

Turns out postgres is already accessible via unix sockets. 🎉 In case someone is interested, here is my working configuration:
Mount the socket into each container by adding the following under volumes of immich-server, immich-microservices, immich-microservices in docker-compose.yml:
- /var/run/postgresql/.s.PGSQL.5432:/usr/src/app/.s.PGSQL.5432 (possibly change the location on the left to the postgres socket on the host system)
Set in .env file: DB_HOSTNAME=/usr/src/app/