Is there any way for the optimizer to work when using either immich cli or immich-go to upload?

[London-Lass]

I can't seem to make the optimizer run when using a cli, but works great when uploading through the web ui.

I have a lot bulk uploading to make images available for family/friends however limited disk space on the server that i intend to use for that. My idea had been to downsize on upload using this optimizer.

I love the idea that immich will take care of the resizing for me rather than creating some workflow to do that.

[krotname]

It should work with CLI uploads only if the CLI is pointed at the IUO proxy URL, not directly at the Immich server.

IUO is not an Immich background worker. It is an HTTP reverse proxy in front of Immich. In the code it only processes upload requests matching:

POST /api/assets
Content-Type: multipart/form-data

and it also rewrites /api/assets/bulk-upload-check so Immich can still detect duplicates correctly after optimization.

So for immich cli or immich-go, the important part is the server/base URL you configure. It needs to be the IUO listener, for example the 2284 port from the README compose example, while IUO itself has IUO_UPSTREAM=http://immich-server:2283.

If the CLI is configured with the normal Immich URL/port, it bypasses IUO completely and nothing will be optimized. A quick way to verify is to watch the IUO logs while uploading: for a matched upload you should see messages like received, then uploaded / uploaded original. If there is no IUO log line, the request is not going through the proxy. If there is a log line but it says the original was uploaded, then the request matched but no task matched the file extension or the processed result was not smaller.

One caveat: if a tool uses a newer/different Immich upload endpoint instead of POST /api/assets with multipart form data, this proxy will not catch it without a code change.

[London-Lass]

Thanks for the quick reply, much appreciated 👍

So I have setup IUO to listen on 2284

services:
  immich-upload-optimizer:
    image: ghcr.io/joojoooo/immich-upload-optimizer:latest
    tmpfs:
      - /tempfs
    ports:
      - "2284:2284"
    volumes:
      - /mnt/data01/name/immich-upload-optimizer:/etc/immich-upload-optimizer
    environment:
      - IUO_UPSTREAM=http://immich-server:2283
      - IUO_LISTEN=:2284
      - TMPDIR=/tempfs
      - IUO_TASKS_FILE=/etc/immich-upload-optimizer/config/tasks.yaml
      - IUO_ALLOW_BINARY_UPLOADS=true
    depends_on:
      - immich-server
    restart: always

With immich server listening on 2283

  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    environment:
      - UPLOAD_LOCATION="api"
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

I can interact with either 2283 or 2284 from a browser, so presumably the pass through is working fine.

My auth.yml, which controls immich cli should talk to port 2284

url: http://localhost:2284/api
key: abcd1234

When I upload using cli, I don't see any logs when using cli to indicate it's working, and the images are uploaded full size.

#Command and output
/usr/local/bin/immich upload --album-name 'Album Name' --url http://localhost:2284 --key abcd1234 --ignore '**/{mini-**,Thumbs.db,*.ZIP,print.JPG}' --recursive /run/user/1000/gvfs/smb-share:server=name.local,share=name/2004-05/2004-12-04-Event/a/
Crawling for assets...
Hashing files           | ████████████████████████████████████████ | 100% | ETA: 0s | 836.7 MB/836.7 MB
Checking for duplicates | ████████████████████████████████████████ | 100% | ETA: 0s | 836.7 MB/836.7 MB
Found 0 new files and 579 duplicates
All assets were already uploaded, nothing to do.
Creating albums | ████████████████████████████████████████ | 100% | ETA: 0s | 1/1 albums
Successfully created 1 new album
Successfully updated 579 assets
Adding assets to albums | ████████████████████████████████████████ | 100% | ETA: 0s | 579/579 assets

Which gives logs

2026/06/21 21:45:21 192.168.68.200: request URL: /api/assets
2026/06/21 21:45:27 192.168.68.200: websocket proxy: client connection upgrade
2026/06/21 21:46:14 192.168.68.200: request URL: /api/albums/e4c076bd-fc56-4e95-81b3-b0ffb2655cbc?withoutAssets=true
2026/06/21 21:46:14 192.168.68.200: request URL: /api/albums/e4c076bd-fc56-4e95-81b3-b0ffb2655cbc?withoutAssets=false
2026/06/21 21:48:11 172.18.0.1: request URL: /api/assets/bulk-upload-check
2026/06/21 21:52:33 192.168.68.200: request URL: /api/albums/18544bf8-1c83-4ec7-9b8c-dc0192c8d087?withoutAssets=true
2026/06/21 21:52:33 192.168.68.200: request URL: /api/albums/18544bf8-1c83-4ec7-9b8c-dc0192c8d087?withoutAssets=false
2026/06/21 21:53:58 192.168.68.200: request URL: /api/albums/5d214995-1476-46be-97e6-0098a2befba6?withoutAssets=true
2026/06/21 21:53:58 192.168.68.200: request URL: /api/albums/5d214995-1476-46be-97e6-0098a2befba6?withoutAssets=false
2026/06/21 21:54:04 192.168.68.200: request URL: /api/albums/61e74046-2bd6-4669-9d75-d9b0d225a306?withoutAssets=true
2026/06/21 21:54:04 192.168.68.200: request URL: /api/albums/61e74046-2bd6-4669-9d75-d9b0d225a306?withoutAssets=false
2026/06/21 21:55:43 172.18.0.1: request URL: /api/assets/bulk-upload-check

Whilst if i upload through the ui I see resizing working ...

2026/06/21 21:45:18 192.168.68.200: job 1: received: "Screenshot 2024-05-19 191938.png" (deviceAssetId: web-Screenshot 2024-05-19 191938.png-1716142779304)
2026/06/21 21:45:18 192.168.68.200: job 2: received: "Screenshot 2024-05-19 220631.png" (deviceAssetId: web-Screenshot 2024-05-19 220631.png-1716152791930)
2026/06/21 21:45:19 192.168.68.200: job 1: downloaded: "Screenshot 2024-05-19 191938.png" (4.68 MB)
2026/06/21 21:45:19 192.168.68.200: job 1: running task: caesium: caesiumclt --verbose 3 --keep-dates --exif --quality=85 --no-upscale --long-edge 1600 --output=/tempfs/processing-1791838620 /tempfs/upload-2202052533.png
2026/06/21 21:45:19 192.168.68.200: job 2: downloaded: "Screenshot 2024-05-19 220631.png" (4.22 MB)
2026/06/21 21:45:19 192.168.68.200: job 2: running task: caesium: caesiumclt --verbose 3 --keep-dates --exif --quality=85 --no-upscale --long-edge 1600 --output=/tempfs/processing-4231249720 /tempfs/upload-1802126522.png
2026/06/21 21:45:20 192.168.68.200: job 1: uploaded: "Screenshot 2024-05-19 191938.png" (683.09 KB) <- (4.68 MB) "Screenshot 2024-05-19 191938.png"
2026/06/21 21:45:20 192.168.68.200: request URL: /api/assets
2026/06/21 21:45:20 192.168.68.200: job 3: received: "Screenshot 2024-05-20 083645.png" (deviceAssetId: web-Screenshot 2024-05-20 083645.png-1716190605489)
2026/06/21 21:45:20 192.168.68.200: job 2: uploaded: "Screenshot 2024-05-19 220631.png" (995.54 KB) <- (4.22 MB) "Screenshot 2024-05-19 220631.png"
2026/06/21 21:45:20 192.168.68.200: request URL: /api/assets
2026/06/21 21:45:20 192.168.68.200: job 4: received: "Screenshot 2024-05-20 084010.png" (deviceAssetId: web-Screenshot 2024-05-20 084010.png-1716190811109)
2026/06/21 21:45:20 192.168.68.200: job 3: downloaded: "Screenshot 2024-05-20 083645.png" (3.94 MB)
2026/06/21 21:45:20 192.168.68.200: job 3: running task: caesium: caesiumclt --verbose 3 --keep-dates --exif --quality=85 --no-upscale --long-edge 1600 --output=/tempfs/processing-2566674383 /tempfs/upload-3708479934.png
2026/06/21 21:45:20 192.168.68.200: job 4: downloaded: "Screenshot 2024-05-20 084010.png" (3.94 MB)
2026/06/21 21:45:20 192.168.68.200: job 4: running task: caesium: caesiumclt --verbose 3 --keep-dates --exif --quality=85 --no-upscale --long-edge 1600 --output=/tempfs/processing-3557670384 /tempfs/upload-3230076928.png
2026/06/21 21:45:21 192.168.68.200: job 3: uploaded: "Screenshot 2024-05-20 083645.png" (555.34 KB) <- (3.94 MB) "Screenshot 2024-05-20 083645.png"
2026/06/21 21:45:21 192.168.68.200: request URL: /api/assets
2026/06/21 21:45:21 192.168.68.200: job 4: uploaded: "Screenshot 2024-05-20 084010.png" (1.10 MB) <- (3.94 MB) "Screenshot 2024-05-20 084010.png"
2026/06/21 21:45:21 192.168.68.200: request URL: /api/assets
2026/06/21 21:45:27 192.168.68.200: websocket proxy: client connection upgrade

So ... it seems to work through UI on 2284 (IUO) but not when using the CLI?

[krotname]

In the CLI run you pasted, I do not think there was an actual upload for IUO to optimize.

The key line is:

Found 0 new files and 579 duplicates

After that the CLI only created/updated albums and added existing assets to albums. Your IUO log matches that: it sees /api/assets/bulk-upload-check and album requests, but no job received: lines from the CLI run. The UI test has received / downloaded / running task / uploaded, because that test actually sent new files to POST /api/assets.

So the proxy path looks OK. To test CLI optimization, use one new file that Immich has never seen before, then run:

immich upload --url http://localhost:2284 --key ... /path/to/new-file.jpg

If IUO receives a real upload, you should see the same job ... received log line. If you only see bulk-upload-check and then "duplicates", IUO is being bypassed by duplicate detection, not by the CLI connection.

[London-Lass]

Amazing! Thank you! I totally didn't get that when I deleted the album I was trying to resize that the images in the album were not fully gone. I've now discovered I can empty the trash, and after that when I use the cli it is resizing. Thanks!