Large File Upload¶
Upload thousands of files, any size — reliably and securely.
Lenzeye's large file upload system is built on S3 Multipart Upload — the same protocol used by Amazon, Dropbox, and Google Drive internally. Every file, regardless of size, is split into 10 MB chunks and uploaded independently. The result is a system that is fast, resumable, and resistant to network failures.
How It Works¶
flowchart LR
A[Select files\nin browser] --> B[Split into\n10 MB chunks]
B --> C[Upload each\nchunk independently]
C --> D[Wasabi S3\nassembles file]
D --> E[File available\nin storage]
- File is split — the browser splits each file into 10 MB parts before any data is sent.
- Parts uploaded independently — each part goes to Wasabi S3 directly via a presigned URL (time-limited, cryptographically signed). The Lenzeye server is not in the data path.
- S3 assembles — once all parts are confirmed, Wasabi S3 assembles the final file from the parts server-side.
- Failure recovery — if a single part fails, only that part is retried. The rest of the file is not affected.
Key Properties¶
| Property | Value |
|---|---|
| Chunk size | 10 MB per part |
| Max file size | No hard limit — tested beyond 50 GB single file |
| Max session size | Tested to 250 GB+ (2,630 files in one session) |
| Session duration | Tested to 6 hours 56 minutes sustained |
| Resumability | Parts are independent — failed parts can be retried |
| Server RAM cost | Zero for plain uploads — data goes browser → S3 direct |
| Concurrent uploads | Multiple files upload in parallel |
Why Not Just Send the Whole File?¶
Standard HTTP file uploads break for large files because:
- Network timeouts kill the connection mid-transfer
- Server memory must hold the entire file before writing
- A single network hiccup restarts the entire upload
Multipart upload solves all three: each chunk is small enough to survive any network condition, server never buffers the full file, and only failed chunks are retried.
Encrypted Upload Path¶
When the receiver has encryption enabled, the upload path changes slightly:
- Chunks are sent to the Lenzeye server (not directly to S3)
- The server encrypts each chunk with AES-256-CTR at the correct stream offset
- The encrypted chunk is then pushed to Wasabi S3
- An HMAC-SHA256 tag is accumulated across all chunks and stored on completion
The encryption is transparent — the sender's experience is identical regardless of whether encryption is on or off.
Validated Performance¶
| Metric | Result |
|---|---|
| Files in single session | 2,630+ |
| Session duration | 6h 56min |
| Peak server RAM (encrypted path) | 398 MB on 512 MB plan |
| File corruption | Zero |
| Upload failures (network) | Retried automatically per chunk |
Comparison¶
| Lenzeye | Google Drive | WeTransfer | ||
|---|---|---|---|---|
| Max file size | No limit | 5 TB (paid) | 2 GB (free) | 2 GB |
| Bulk upload (1000+ files) | ✅ Validated | ✅ (slow) | ❌ | ❌ |
| Resumable on failure | ✅ Per chunk | ❌ | ❌ | ❌ |
| No compression | ✅ | ✅ | ✅ | ❌ |
| Encryption at rest | ✅ | ❌ | ❌ | ❌ |
| No receiver account needed | ✅ | ❌ | ✅ | ❌ |