[Feature] Configurable upload URL — send asset uploads to a different host than browsing

[olragon]

[Feature] Configurable upload URL — send asset uploads to a different host than browsing

Problem

Immich uploads each asset as a single, non-resumable POST /api/assets. When the
server is reached through a proxy or tunnel that caps request-body size, any file
above that cap fails with 413 and there is no client-side workaround. The most
common case is Cloudflare's 100 MB body limit on the Free/Pro plans (and via
Cloudflare Tunnel), which blocks large videos. This is already reported and
discussed:

• [Feature] Uploads fail behind Cloudflare Free due to 100MB limit – proposal: chunked uploads #25183 — Uploads fail behind Cloudflare Free due to the 100 MB limit
• [Feature]: Upload large files in chunks #1674 — Upload large files in chunks (the "proper" long-term fix; still open)

Chunked/resumable upload (#1674) would solve the root cause but is a large piece
of work. This proposal is a small, orthogonal improvement that helps today
without touching the transfer protocol.

Why the existing endpoint switching doesn't cover it

The app's Automatic URL Switching swaps the single server endpoint (browse
and upload together) based on a matched Wi-Fi SSID. That is network-based and
local-only — it can't route just uploads to a different host, and it does
nothing on cellular / away from the configured SSID. The related requests are
about multiplying SSID→endpoint mappings, not a per-traffic-type endpoint:

• [Feature] Support multiple Wi-Fi SSIDs with configurable local server endpoints #28436 — Support multiple Wi-Fi SSIDs with configurable local server endpoints
• [Feature] Allow for multiple SSIDs on the Multiple Network screen on phone app (specifying home network IP) #15980 — Allow for multiple SSIDs on the Multiple Network screen

Proposal

Add an optional, admin-set uploadUrl to the server config that is pushed to
clients via ServerConfigDto. When it is non-empty, clients send asset uploads
to that base URL instead of the main endpoint; everything else (browsing,
thumbnails, playback, websocket) keeps using the normal endpoint. Empty by
default → no behaviour change.

This lets an operator point uploads at a host that isn't behind the size-capping
proxy (e.g. a direct/grey-cloud hostname), while keeping the main URL on the
proxied/CDN path for browsing. It's a few small changes and is fully backward
compatible.

Reference implementation (for discussion, not a PR)

I put a working reference on a fork so the shape is concrete:
https://github.com/olragon/immich/tree/feat/configurable-upload-url

• server — uploadUrl on the admin server config + ServerConfigDto
  (validated as empty-or-URL; the path is preserved so it can include /api),
  regenerated OpenAPI spec + TypeScript SDK. Existing server unit tests updated
  and passing (55 tests across the touched suites).
• web — an admin "Upload URL" field beside "External domain" + i18n string.
• mobile — reads uploadUrl from the server config, persists it, and uses it
  as the base URL for the foreground and background upload paths only (they are
  already hand-rolled and independent of the shared API client, so no other call
  is affected). I have not been able to build/run the Flutter app locally, so
  the mobile side is unverified beyond the source change.

Before I open a PR

Per CONTRIBUTING I'm raising this first rather than dropping a PR. Two questions:

1. Is this direction something you'd accept in principle (a per-upload endpoint,
   distinct from chunked upload and from SSID switching)? Or would you rather
   keep everything behind [Feature]: Upload large files in chunks #1674?
2. If yes, any preferences on naming/placement (e.g. uploadUrl vs a nested
   upload.url, required vs optional in ServerConfigDto, and whether the web
   uploader should honour it too — currently it does not).

Disclosure

The reference implementation and this write-up were prepared with AI
assistance. I understand the change and will own, verify, and (if you're open to
it) rework it to your guidance before any PR — I'm not asking anyone to review
AI output as-is; I'm asking whether the approach is welcome.

[github-actions[bot]]

This discussion has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.