docs: recommend disabling nginx proxy buffering

[oddlama]

By default, nginx buffers requests and responses to proxy servers. This means the whole body is first written to a temporary file in /tmp and then passed to the proxy when it has been received. This PR adds two options to the nginx proxy documentation to disable this buffering.

Buffering causes issues when the proxy server has a tmpfs mounted on /tmp (which is almost always the case) and you try uploading files larger than the tmpfs (even if the backend immich instance could handle it). The proxy request will be aborted by nginx if it cannot be stored first. Disabling the buffering also increases transfer speeds as the file will immediately be passed to immich.

[github-actions]

Label error. Requires exactly 1 of: changelog:.*. Found: documentation

[mmomjian]

I used to have this disabled as well, but I don't think it's a good practice as a default config. Our goal is to provide a bare bones proxy config for the Immich-specific topics, which this isn't really part of.

https://www.nginx.com/blog/avoiding-top-10-nginx-configuration-mistakes/#proxy_buffering-off

[oddlama]

I used to have this disabled as well, but I don't think it's a good practice as a default config.

The current default config prevents uploads that are larger than the size of the proxies tmpfs, without generating any errors in the immich logs (since the request never reaches immich). I don't think this is a good default.

Our goal is to provide a bare bones proxy config for the Immich-specific topics, which this isn't really part of.

How is this not immich-specific?

https://www.nginx.com/blog/avoiding-top-10-nginx-configuration-mistakes/#proxy_buffering-off

I have to disagree. This article is discussing configuration mistakes related to nginx deployments that serve a substantial amount of clients. It is also only about proxy_buffering (server -> proxy -> client), not proxy_request_buffering (client -> proxy -> server). So all of this applies to scenarios where the proxy server is actually actively load balancing or rate limiting, which is not the case for 99% of the immich instances in existence.

It only lists downsides about rate limiting and caching, while a reverse proxy like the one documented by us is usually used by people to do SSL termination, and nothing more. So how is this relevant? I think the immich documentation should provide a good default for the majority of users. Anyone who's doing fancy stuff with a load balancer will know what they are doing.
Please enlighten me if you have deeper knowledge justifying why this is bad for the specific case of an immich instance.

I guess what we can argue about is whether proxy_buffering should be included in this PR, since it doesn't play a role in fixing the tmpfs disk space issue, but I don't see how this would be strictly bad practice here.

[mmomjian]

My opinion is that if you are using tmpfs for your proxy (which I don't believe is the default) you should know how to manage the disk space and RAM on your proxy. Immich is not here to teach someone how to use their reverse proxy.

Logs should be monitored on the reverse proxy end in addition to Immich. Maybe other maintainers will disagree, or we can add a tooltip or such.

[oddlama]

My opinion is that if you are using tmpfs for your proxy (which I don't believe is the default) you should know how to manage the disk space and RAM on your proxy.

Depends on the distribution, the systemd default is to enable it. If you don't believe it, look at the tmp.mount unit which is enabled by default via basic.target and basic.target is required by multi-user.target. Notably, raspbian (and maybe debian based stuff?) disables this in their default installation, but many do not (NixOS, Arch, Docker(!), ...).

$ mount
[...]
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)

you should know how to manage the disk space and RAM on your proxy.

You and I may, but I figured others - especially beginners - might very well not. So this is why I though it would be a great addition to the docs. If you don't think so that's fine to me, I don't want to argue.