Multipart Upload Planner for Large Files

A multipart upload is not one big request — it is a file cut into numbered parts, each uploaded on its own, then reassembled server-side into a single object. That buys you three things a single PUT cannot: parallel upload of several parts at once so a slow uplink is not idle waiting on latency, a retry that re-sends one part instead of the whole file, and a resumable upload that survives a laptop lid closing mid-transfer.

The planner above turns that into numbers for your file: how many parts, how big the last one is, how many parallel rounds it takes, roughly how long it runs, and exactly what one failed part costs you to send again.

Chunk sizing is the decision people get wrong. Every part except the final one must be at least 5 MB, and no upload may exceed 10,000 parts, so the part size sets a hard ceiling on the file size you can move. Small parts mean more round-trips, more presigned URLs, and more bookkeeping in your client; large parts mean a single network blip re-sends more bytes. cdn22.net does not make you guess — the multipart endpoint presigns fixed 100MB parts, which puts a 10GB upload at 103 parts and keeps a 1TB file inside the 10,000-part ceiling.

Set the planner to 100MB to see what our API will actually do with your file, or change it to plan a client against any other S3-compatible large file upload API.

Retries, resumability, and integrity are the rest of the job. Retry an individual part with exponential backoff rather than restarting the transfer; hold on to the upload id and the part numbers you have already completed and the session is resumable. Each part carries an ETag, and the completion call validates the assembled object, so a truncated part fails the commit instead of landing as a silently corrupt file — but if the bytes genuinely matter, checksum the source before upload and verify after download, because that is the only end-to-end guarantee.

And abort what you abandon: an orphaned multipart session leaves parts in storage that still cost money. cdn22.net presigns part URLs for 24 hours, exposes an explicit abort endpoint, and sweeps sessions that can no longer be resumed.

The API is three calls with your raw API key in the Authorization header, no SDK: POST /v1/files/multipart/{folderId}/initiate returns an upload id, a file id, and one presigned URL per part; you PUT the part bytes yourself, in parallel, straight to storage; POST /v1/files/multipart/complete commits it, and POST /v1/files/multipart/abort cancels it. If your files are small enough not to need any of this, the simpler three-call flow on the file upload API page is the one to build against, and the cloud file storage API page covers the full endpoint surface.

What happens after the last part lands is the part most upload guides skip. The assembled file is stored as one object, and in a public folder it already has its permanent CDN link — no publish step, no separate copy into a delivery bucket. Private files stay private and are read through short-lived signed URLs your backend mints.

So the same pipeline that ingests a 40GB master or a nightly build artifact also serves it globally, which is the whole reason to put large-file ingestion and CDN delivery behind one API instead of stitching a bucket to a distribution yourself. For sending those files onward see large file transfer; to allow clients to upload files to you without building an uploader, see file request links.