Issue with downloading large files (40GB) in Appwrite 1.8.0

Hi everyone! I am using the latest Appwrite 1.8.0 version on my self-hosted server.

I successfully uploaded a large ZIP archive (~40GB) using the chunked upload method via the SDK. The file is marked as 'Available' in the console and I can see the full file size on my server's disk.

However, I am having trouble downloading it:

Using the 'download' link from the console (or the API endpoint) results in a perpetual loading state in the browser, eventually showing 0 Byte/s or a 504 Gateway Timeout.
I've tried multiple browsers and even download managers, but with no success.
I have already adjusted _APP_STORAGE_LIMIT, _APP_STORAGE_PREVIEW_LIMIT and _APP_STORAGE_ANTIVIRUS=disabled in my .env.
My proxy setup (Nginx Proxy Manager + Traefik) has Range Requests enabled (verified with curl -I returning HTTP 206), yet the stream never actually starts.

Thanks for any help! ❤️

TL;DR

Issue with downloading a large file (40GB) in Appwrite 1.8.0. Logs show no activity when trying to download the file. Logs suggest that the connection is being dropped or held in a buffer before it reaches the Appwrite application logic. The direct access via IP results in the same issue. The server might be struggling to initialize the stream for such a large file. Possible solution is to connect Appwrite to an S3 Minio bucket or check for internal environment variables or resource limits. Bug report opened on GitHub.

What are the logs for the Appwrite container? You can check them by running: docker compose logs appwrite

Also what's the endpoint that you're using to download the file? For example: https://yourappwriteinstance/v1/storage/buckets/example/files

(Feel free to censor all the sensitive data like the domain, IDs, etc. Specially if it's private data)

Are you using any proxy in front of Appwrite ? that might be causing this ?

Here is the link generated by the console: https://[DOMAN]/v1/storage/buckets/68ffcec3002969215501/files/ea6898c0e1-41057216360-1766218067798/view?project=68fa08c50006106a26b9&mode=admin

The most confusing part is that docker compose logs appwrite remains completely silent. When I trigger the download, not a single line of log data is generated in the container. It seems the request is stalled or dropped before it even reaches the Appwrite application logic.

Interestingly, curl -I returns a 206 Partial Content immediately, but the actual data stream never starts (0 bytes/s). Any idea why the logs wouldn't even register the attempt?

I also tested accessing the file directly via http://[SERVER_IP]:[PORT] to bypass Nginx Proxy Manager and go straight to Traefik, but I encountered the same result: the connection hangs and no logs are generated in the Appwrite container

I've tested the download via wget and curl:

TypeScript

--2025-12-23 13:14:24--  https://[DOMAIN]/v1/storage/buckets/[BUCKET_ID]/files/[FILE_ID]/download?project=[PROJECT_ID]&mode=admin
Resolving [DOMAIN] ([DOMAIN])... [IP_ADDRESS]
Connecting to [DOMAIN] ([DOMAIN])|[IP_ADDRESS]|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: ‘archive.zip’

archive.zip                             [<=>                                                                                           ]       0  --.-KB/s   ^C

➜  ~ curl -I -H "Range: bytes=0-100" https://[DOMAIN]/v1/storage/buckets/[BUCKET_ID]/files/[FILE_ID]/download?project=[PROJECT_ID]
HTTP/2 404
server: openresty
date: Tue, 23 Dec 2025 13:15:00 GMT
content-type: application/json; charset=UTF-8
access-control-allow-credentials: true
...
x-debug-speed: 0.010032892227173
strict-transport-security: max-age=63072000;includeSubDomains; preload```

Are you using some proxy in front?

If not, check the logs for the traefik container

I’ve followed up on the Traefik logs. While the request arrives at the Traefik layer, it seems to stall or time out during the hand-off to the main Appwrite service.

The fact that the appwrite container logs remain completely silent is the most telling part. It suggests the connection is being dropped or held in a buffer before the application logic can even process or log the request.

Since direct access via IP:PORT results in the same 0 bytes/s behavior, I suspect there might be a bottleneck in the underlying server configuration regarding output buffering or maximum response sizes for extremely large files.

It feels like the server is struggling to initialize the stream for a 40GB file, causing a 'silent fail' where the headers (like the 206 Partial Content) are sent, but the payload never follows. Are there any internal environment variables or resource limits (beyond the standard storage ones) that control how the server handles these massive outbound streams?

I have a similar problem

I was trying to chunk my files, a file that is just 5 gb long

i couldn't manage to make it wokr for x size of a file

i had to know exactly how many bytes each file had which is really annoying

and when i tried to download it, i had the same behavior as vanilla fish, 0 bytes - 0 bytes downloading, and when it finished downloading 0 bytes downloaded