docker-compose.yml for immich with WAF, DDoS protection, image resizing and without port forwarding

immich-docker-config.md

Setup Immich via Docker Compose with WAF, CDN, DDoS protection, no port forwarding and automated image resizing

In this guide, we are using the docker compose setup that is recommended by the Immich team. Once everything is configured and running in your local network, we can expand on it.

The first recommended step is to use Cloudflare Tunnel to make your local instance globally available. This is free and you benefit from the native DDoS protection, WAF and CDN from Cloudflare. The cloudflared daemon basically makes an outgoing connection to Cloudflare and makes the designed interfaces available on the internet, without granting access to undesired parts of the network.

Start off by creating a Cloudflare account, going into the "Zero Trust" portion of the account and add a new tunnel. Give it a name and choose a domain that you want your instance to be available on. You can use the "Access" components (SSO/VPN) to lock down the access, if you want. Once you have to choose a local agent, select "Docker" and copy the token from the instructions. Add the following command into your docker-compose.yml and add your valid tunnel token.

  cloudflared:
    container_name: cloudflared
    image: cloudflare/cloudflared:latest
    depends_on:
      - immich-server
    restart: always
    command: 'tunnel --no-autoupdate run --token YOUR-TOKEN'

Use docker compose to start this container, the UI should show your node being online now. Now switch to "Public hostname" , add the desires subdomain for your immich instance, leave path empty and for the service you configure HTTP with immich_proxy:8080 as destination. Once saved, your cloudflared daemon will automatically update and your immich is now available on the internet.

If you would like your pictures to be automatically resized - a feature which the Immich maintainers have declined - you can add the following code to your docker-compose.yml. Feel free to change the dimensions you are looking for.

  upload-proxy:
    container_name: upload_proxy
    image: ghcr.io/jamescullum/multipart-upload-proxy:main
    environment:
      - IMG_MAX_WIDTH=1920
      - IMG_MAX_HEIGHT=1080
      - FORWARD_DESTINATION=http://immich-server:3001/api/assets
      - FILE_UPLOAD_FIELD=assetData
      - LISTEN_PATH=/api/assets
    restart: always

You need to route uploads to this container now, which is easy to do via Cloudflare tunnel. Create a new public hostname, use api/asset/upload as path and direct it via HTTP to upload_proxy:6743. Submit and move this public hostname above the previous one.

Now all file uploads will be proxied and images automatically resized before being uploaded to Immich.

Hi @JamesCullum ,
this has been working for me very well.
Since there were the changes in the immich version 1.88, when they removed the proxy and web containers I tried to update the file myself.
Immich is working, but I can't access it via cloudflare tunnel.

What I did in the file I changed:
cloudflared: container_name: cloudflared image: cloudflare/cloudflared:latest depends_on: - immich-proxy

to

cloudflared: container_name: cloudflared image: cloudflare/cloudflared:latest depends_on: - immich-server

Is that correct?
And in the cloudflare tunnel config, do I need to change http://upload_proxy:6743 and http://upload_proxy:8080 to sth. else?

Couldn't figure it out myself.

Your help is much appreciated!
Best
Stigg

EDIT: Found it. Logically I used the port from the server (immich_server:3001), instead of http://upload_proxy:8080.
Didn't find anything regarding upload proxy, but uploads seem to be working

Hey @Stiggler thank you for letting me know that 1.88.0 dropped. It is indeed necessary to update the Cloudflare tunnel configuration and the dependency in the compose file. I've updated the guide above to represent this - it's working fine for me like this.

Hey @Stiggler thank you for letting me know that 1.88.0 dropped. It is indeed necessary to update the Cloudflare tunnel configuration and the dependency in the compose file. I've updated the guide above to represent this - it's working fine for me like this.

Perfect, many many thanks!

This needs to be updated to use cloudflared's TUNNEL_TOKEN environment variable. Currently, you're exposing the token to anyone/thing that can list processes.

Also, more compose file updates for the newest version.

@telgareith I'm not sure if I understand the threat scenario you mean - any user with access to Docker on the same instance will have access to any secrets in a container, no matter how it's managed. It's not a good idea to share a Docker server with people you don't trust.

Yes, docker compose file was updated again. There was no change needed here, but I noticed that I didn't update one part of the documentation last time and fixed it now (FORWARD_DESTINATION was missing the /api part)

it's not even a "threat scenario" - It's about doing things correctly, and not teaching people bad habits. You use Environment Variables in your own container...

Just need to change cloudflared to:

  cloudflared:
    container_name: cloudflared
    image: cloudflare/cloudflared:latest
    depends_on:
      - immich-server
    environment:
      - TUNNEL_TOKEN = YOUR-TOKEN
    restart: always
    command: 'tunnel --no-autoupdate run'

And I said "anyone/thing that can list processes," for a reason: non admin users and logging. OOM kill, container start, container stop, process fault, too many to name... All result in TUNNEL_TOKEN in the logs.

Finally: Storing compose files somewhere every user on the machine can access them is bad practice.

Just a quick question, how could I automatically resize the pictures I upload over mobile app without using cloudflare tunnel? (ie, connecting over local network)
Does simply adding the following to docker-compose file make that work?

    upload-proxy:
    container_name: upload_proxy
    image: ghcr.io/jamescullum/multipart-upload-proxy:main
    environment:
      - IMG_MAX_WIDTH=1920
      - IMG_MAX_HEIGHT=1080
      - FORWARD_DESTINATION=http://immich-server:3001/api/asset/upload
      - FILE_UPLOAD_FIELD=assetData
      - LISTEN_PATH=/api/asset/upload
    restart: always

NB: I'm still in my early phase of using docker 😅

@telgareith Thank you for providing an alternative version for the Tunnel using an environment variable.

@Ranger-NF Sadly not. You need all requests to go to Immich with the exception of the file upload API, which should go to the resizing proxy. If you really don't want to use the Cloudflare tunnel (really try to give it a shot - it's free and has many great benefits), then you will need another container as reverse proxy in front of your application.

@telgareith Thank you for providing an alternative version for the Tunnel using an environment variable.

@Ranger-NF Sadly not. You need all requests to go to Immich with the exception of the file upload API, which should go to the resizing proxy. If you really don't want to use the Cloudflare tunnel (really try to give it a shot - it's free and has many great benefits), then you will need another container as reverse proxy in front of your application.

I would love to use cloudflare tunnels, but I don't own any domain. So that option is out of the question...

Let me know if there are any solutions for this!

Hmm so you only want Immich available via home wifi and static IP? A DynDNS provider might help you out and solve two problems at once.

Cloudflare tunnel does not require a domain and will generate you a free one: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/

The use of multipart in the image name gives me hope that this does chunked uploads to get around Cloudflare's 100mb limit, is that the case or am I suffering from wishful thinking?

Multipart is a subcomponent of the HTTP form protocol to allow file uploads - the proxy does not circumvent any limitations. I did not find the limitation you mentioned in tunnel documentation.

OK, thanks for the info, I'm using Traefik2 as my reverse proxy and Cloudflare as my DNS provider, and Cloudflare has the limitation.

Your DNS provider has nothing to do with filesize limits. Check your reverse proxy or client for that.

I didn't find such a limitation for the Cloudflare tunnel either, so it looks like your problem is somewhere else.

https://community.cloudflare.com/t/limit-on-file-uploads-via-cloudflare-access/435226

The limit is also discussed in relation to immich here
immich-app/immich#1674

Hello, Immich have changed quite a few and the upload proxy code is right now not working as expected.

Since v1.106.1 Immich uses a POST on /api/assets to upload files, but also a PUT to update them and a DELETE to delete them. So for example right now if you try to delete an image you get a 400 Bad Request. That's mainly because this upload proxy procces everything on the listen path so it now breaks some features of the Immich website.

I will be modifying the code on a fork I made to directly forward anything that is not POST on the "/api/assets" path to only proccess the uploads and that should solve it 😄 .

Ah I see - my setup kept running smoothly, so I didn't notice these API changes. Thanks for the hint - and we can't filter for that via Cloudflare tunnel? Let's work on this on the upload proxy repo 👍

Hello @JamesCullum thank you for the quick answer.

It might work smoothly but it's because images are not being resized, as the new url path for the uploads is /api/assets and not /api/asset/upload the file uploads goes against the entry number 2 in the tunnel and dont get through the upload proxy. I've already played a little bit with the tunnel configuration but it's quite imposible because the code itself does not distinguish a POST from a PUT or a DELETE so everything gets treated the same way and for example the DELETE fails on when the code tries to get a field from a request that does not have it.

I have a rough sketch in my mind on how we could get around this with a golang code snippet I found on how to make a simple requests forwarder.

Will keep you updated on the repo as you suggested and try to have a PR ready tomorrow.

New version is available and I updated the paths in the gist above to reflect the API change - thanks a lot for your help @hamzab70 👍

Thanks for this!
I wanted to use Caesium for image optimization, so I created an alternative version that supports external programs based on this idea.
It also removes the need for Cloudflare or reverse proxy path redirection:
https://github.com/miguelangel-nubla/immich-upload-optimizer.