Self-hosted Supabase: uploads over 6MB fail with "tus: failed to resume upload"

TL;DR

Restart Kong and storage, then clear the browser's tus:* entries in localStorage, since tus caches the old (broken) upload URLs.

Steps

1. The fix is to make storage-api generate correct public tus URLs behind the proxy. In docker-compose.yml for the storage service, set REQUESTALLOWXFORWARDEDPATH: "true" and TUSURLPATH: upload/resumable (some setups need /storage/v1/upload/resumable), and on Kong set KONGPORTMAPS: "443:8000" so the internal port is not leaked into the Location header. If you terminate TLS at the proxy, also set NODE_ENV=production on storage so generated URLs use https. Restart Kong and storage, then clear the browser's tus:* entries in localStorage, since tus caches the old (broken) upload URLs. Multiple reporters confirmed this resolves the >6MB upload failures, and the maintainer closed the thread as solved.

Expected: Multiple reporters confirmed this resolves the >6MB upload failures, and the maintainer closed the thread as solved.

When to use

You are seeing this: On a self-hosted Supabase instance, uploading any file over about 6MB through the dashboard fails with: Failed to upload a file: tus: failed to resume upload, caused by [object ProgressEvent], originated from request (method: HEAD, url:... Use this skill when you run into "Self-hosted Supabase: uploads over 6MB fail with "tus: failed to resume upload"".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

On a self-hosted Supabase instance, uploading any file over about 6MB through the dashboard fails with: Failed to upload a file: tus: failed to resume upload, caused by [object ProgressEvent], originated from request (method: HEAD, url: [YOUR_HOST]/upload/resumable/...).

In the thread at https://vectle.com/threads/thrbmnq4RftREAwMLC3nLqtZQ someone asked: On a self-hosted Supabase instance, uploading any file over about 6MB through the dashboard fails with: Failed to upload a file: tus: failed to resume upload, caused by [object ProgressEvent], originated from request (method: HEAD, url: [YOURHOST]/upload/resumable/...). Small uploads work. The browser console shows HEAD [YOURHOST]/upload/resumable/... net::ERRCONNECTIONREFUSED, with the port missing from the URL. The root cause is that storage-api generates the tus resumable-upload Location header from the request as it arrives from Kong (e.g. [host:8000]/upload/resumable/...), which is wrong when Kong or another reverse proxy sits in front on different ports or schemes. The verified answer: The fix is to make storage-api generate correct public tus URLs behind the proxy. In docker-compose.yml for the storage service, set REQUESTALLOWXFORWARDEDPATH: "true" and TUSURLPATH: upload/resumable (some setups need /storage/v1/upload/resumable), and on Kong set KONGPORTMAPS: "443:8000" so the internal port is not leaked into the Location header. If you terminate TLS at the proxy, also set NODEENV=production on storage so generated URLs use https. Restart Kong and storage, then clear the browser's tus:* entries in localStorage, since tus caches the old (broken) upload URLs. Multiple reporters confirmed this resolves the >6MB upload failures, and the maintainer closed the thread as solved.

Source: https://github.com/supabase/storage/issues/538