Direct Upload Architecture to Cloudflare R2 with S3 Presigned URLs, Go, and Next.js in Multi-Tenant SaaS

1. Why Funneling File Uploads Through Application Servers Inevitably Cripples Your Backend

Have you ever experienced that nightmare scenario where your backend server process suddenly suffers an out-of-memory crash (Linux Kernel OOM Killerℹ) right as several users upload video assets or multi-megabyte PDF files simultaneously? Or opened your monthly cloud hosting bill only to be blindsided by hundreds of dollars in unexpected egressℹ bandwidth charges?

That exact nerve-wracking ordeal is what my engineering team and I encountered when we first deployed our collaborative document management SaaS platform. Early on, we adopted the most intuitive, common approach:

On paper, our controller code looked simple, and manual tests with 2 MB files on developer laptops passed without a hitch. But the moment the platform was released to enterprise customers uploading files ranging from 50 MB to 500 MB, the traditional multipart proxy architecture collapsed:

• Cascading Server Crashes (Out-Of-Memory Panic): When dozens of enterprise users uploaded large archives over saturated office networks, backend worker threads held raw binary chunks in RAM buffers. Server memory surged from 150 MB to 7.8 GB in under 45 seconds, triggering the Linux OOM Killerℹ and plunging our podsℹ into continuous restart loops.
• Slow Client Network Starvation: Users on sluggish cellular networks tied up HTTP connection sockets for minutes just to stream one file. As a result, other users attempting simple logins or record updates were locked out with 502 Bad Gateway errors.
• Dual Bandwidth Egressℹ Invoicing: Our backend paid double for bandwidth: ingressℹ when bytes entered our API, and egressℹ when our server pushed those same bytes into object storage.
• Catastrophic Tenant Quota Leakage (Storage Double-Spend): Because storage counters were only updated after files finished uploading, a tenant opened 5 browser tabs simultaneously to upload large archives, accumulating 1.8 TB of storage on a subscription plan capped at 250 GB!

From this series of painful failures, we established an inviolable architectural rule: large binary data streams must never touch application server process memory. The backend server acts strictly as an Identity & Quota Gatekeeper, while raw binary streams flow directly from the client's browser to object storage using S3 Presigned URLsℹ.

2. Ingestion Paradigms: Server Proxy vs Direct Presigned URL Matrix

Before walking through the code implementation, let us contrast the trade-offs between legacy server multipart proxies and modern direct-to-storage presigned uploads:

3. Three Critical Problems Behind Traditional Upload Systems

Problem 1: Concurrent Burst Attacks Exploiting Quota Checks (Storage Double-Spend)

If a system simply checks remaining quota without an atomicℹ reservation mechanism:

• A user on a Free Plan (500 MB limit) with 100 MB remaining opens 5 browser tabs simultaneously.
• In each tab, the user initiates an upload of a 90 MB file.
• If the backend checks if (used + 90MB > 500MB), all 5 requests pass because at that moment, remaining quota is still 100 MB!
• Consequently, the tenant uploads 450 MB of new files, causing a 350 MB over-quotaℹ leak.

Solution 1: Atomic Two-Phase Quota Reservation & Reconciliation

We enforced a Three-Way Handshake:

1. 1Phase 1 (Soft Reservation): Lock the tenant subscription record atomically using SELECT current_storage_bytes, reserved_storage_bytes FROM tenant_subscriptions FOR UPDATE. Add file bytes to reserved_storage_bytes. If total exceeds limits, reject immediately with HTTP 403 Forbidden.
2. 2Phase 2 (Direct Upload): The client streams directly to Cloudflare R2.
3. 3Phase 3 (Hard Commit): The client triggers the confirmation endpoint. The backend validates real object size via HeadObject, transitions bytes from reserved to current, and completes the ticket. A background cron reconciles expired abandoned reservations.

Problem 2: Binary Size Spoofing (Content-Length Exploitation)

A malicious actor could request a presigned URLℹ declaring a 1 MB file, but stream a 2 GB payload directly to R2 to bypass quota restrictions.

Solution 2: Cryptographic Header Sealing on Presign Creation

When generating the presigned PUT URL with the AWS SDK for Go v2, we bind ContentLength and ContentType directly into the cryptographic signature. Cloudflare R2 automatically rejects any request whose payload fails to match the exact byte size declared in the signature.

Problem 3: Explosive Egress Bandwidth Bills on Conventional Storage

On conventional object storage providers like AWS S3, outbound data transfer is charged around $0.09 per gigabyte. For SaaS platforms with thousands of active tenants reading and downloading documents daily, egressℹ fees frequently dwarf the cost of raw storage.

Solution 3: Cloudflare R2 Zero-Egress Architecture

Cloudflare R2 provides an S3-compatible API with a revolutionary guarantee: $0 Data Transfer Out Fees. This policy eliminated over 70% of our ongoing cloud storage operational costs.

4. Production War Stories: The OOM Crash & 1.8 TB Quota Leak Incident

During our third quarter in production, our engineering team experienced one of our most severe infrastructure alerts:

Following this crisis, we dismantled our multipart proxy pipeline entirely and replaced it with direct Cloudflare R2 presigned PUT streaming backed by atomicℹ two-phase reservations. Since rolling out this architecture, our backend RAM utilization has remained flat below 32 MB, even when hundreds of enterprise users upload gigabytes concurrently.

5. Production Go & Next.js Implementation

Here is our modular production implementation cleanly decoupling Go quota management from Next.js browser streaming:

A. Cloudflare R2 Client Configuration in Go (AWS SDK v2)

B. Atomic Quota Reservation & Presigned URL Handler (Go)

C. Confirmation Handler & HeadObject Verification (Go)

D. Frontend Client Uploader in Next.js (TypeScript)

A React client component handling direct binary PUT streams with XMLHttpRequest for continuous upload telemetry:

6. Real Production Metrics: Before vs After

We evaluated this architecture via load tests simulating 500 concurrentℹ users streaming 50 MB media assets simultaneously:

7. 5 Golden Security Rules for Direct Storage Uploads

1. 1Strict CORS Configurations: Ensure your R2 bucket only accepts PUT and HEAD requests from your official SaaS application domains (https://app.yourdomain.com). Never leave CORS set to wildcards *.
2. 2Bind Content-Type and Content-Length to the Signature: Always sign exact byte lengths and MIME types so malicious actors cannot substitute multi-gigabyte binaries under a 1 MB ticket.
3. 3Keep Expiration Windows Tight: Enforce a maximum URL lifetime of 15 minutes. Treat presigned URLsℹ as single-use transactionalℹ credentials.
4. 4Validate Magic Bytes in Asynchronous Workers: Use background worker routines to inspect the initial 512 bytes (magic numbers) of stored assets to confirm authentic file signatures before assets become publicly accessible.
5. 5Run Scheduled Quota Reconciliationℹ Workers: Schedule a cron routine every 30 minutes to release unconfirmed reserved_storage_bytes from abandoned uploads, ensuring tenant quotas never remain locked.