Storage uploads return HTTP 403 HTML block page after thousands of successful uploads

[tierpinho]

I’m migrating approximately 12K files into a private Supabase Storage bucket. More than 6,000 files have been successfully uploaded and verified, but subsequent uploads repeatedly stop with an HTTP 403 HTML block page instead of a normal Storage JSON error.

Environment

• Hosted Supabase, using the default <project-ref>.supabase.co hostname
• Uploader runs locally in macOS Terminal
• Node.js 18.17.1, using built-in fetch directly—not supabase-js
• Server-side secret/service-role credential entered interactively; never logged or saved
• Private bucket; uploads use opaque, checksum-based object paths
• Raw binary request body with Content-Type: application/octet-stream
• x-upsert: false

Error

Storage file upload failed (HTTP 403; code unclassified; response HTML; block-page signature; gateway request a51b69b6ea5db795-DFW).

The uploader detects a block-page signature in the response. The Ray ID above is from one failed attempt.

What we have tried

• Retrying against the default project hostname; no custom domain or customer-managed Cloudflare proxy is involved.
• Reducing from four concurrent uploads to one file at a time.
• Processing eight-file batches with five-second pauses between batches.

The same HTML 403 persists. Database checkpoint requests continue working, and upload progress is preserved.

A Supabase support ticket is already open. We have not established whether the block is caused by particular file

[yahyakhalid]

That HTML 403 with a block-page signature and a gateway request ID isn't coming from Storage itself. It's the edge protection in front of your project rejecting the request before it reaches the Storage API. That's why you get an HTML page instead of Storage's usual JSON error, and why your database requests on the same project keep working.

With bulk migrations it usually comes down to one of these:

1. The block is on your IP, not on the request rate. After thousands of uploads in a short window from one IP, the edge can flag the client, and lowering concurrency afterwards doesn't lift it. Run the same script for a few files from a different network (a cloud VM, or a phone hotspot). If uploads work there while your machine still gets the 403, that's the cause, and it either expires or support clears it.
2. Some file contents can match a WAF rule. Request bodies are inspected, so files whose content looks like HTML, JS, SVG or SQL can trip a rule, especially when sent as application/octet-stream. Try one of the failing files alone from a clean network, and send the real MIME type in Content-Type.
3. For ~12k files, use resumable (TUS) uploads on the direct storage hostname: https://<project-ref>.storage.supabase.co/storage/v1/upload/resumable. That's the endpoint Supabase recommends for large and bulk uploads, and the TUS clients handle chunking and retries for you. supabase-js storage.from(bucket).upload() from a server is the simpler option if the files are small.
4. Back off on 403/429 (for example 30s, 60s, 120s) instead of fixed batches, and log the file name and timestamp for every failure.

In your support ticket, include the gateway request ID from the block page, the UTC time and your public IP. That's what they need to find the rule that matched and allowlist the migration.

[tierpinho]

Thank you @yahyakhalid Option number 3 worked!

[yahyakhalid]

Glad the resumable endpoint did it. One thing that trips people up with TUS on Supabase: keep chunkSize at exactly 6 MB (6 * 1024 * 1024), since that's the chunk size the endpoint expects. If a migration run gets interrupted, tus-js-client with findPreviousUploads() lets you resume the partial file instead of starting over.