Cotton is designed so safety features stay enabled during real transfers. Uploads, encryption, compression, previews, and range reads all use the same storage pipeline instead of bouncing through temporary whole-file workflows.
The frontend splits files into chunks, hashes them in a worker, uploads multiple chunks in parallel, and retries only missing pieces. The goal is stable throughput across the whole transfer, not a fast-looking first burst that collapses during finalization.
Cotton's upload and storage path is designed around small streaming buffers, ArrayPool-style reuse, and pipeline stages that work continuously. A 500 MB file and a much larger file have the same shape: more chunks, not a fundamentally different memory problem.
Reviewed machine baselines publish local stage numbers instead of only broad crypto claims. The conservative read is whether the slowest write-path stage - SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O - stays ahead of the network link.
Cotton compresses before encryption, so storage savings happen during ingest. Zstd compression is tuned for cloud-storage throughput rather than archival maximum ratio. Deduplication still works because identity is content-addressed before encrypted blob bytes are written.
Weak NAS hardware, cloud VMs, and high-end desktops will hit different ceilings. Cotton's performance story is tracked as a growing table of device baselines, with raw 100 MbE, 1 GbE, 2.5 GbE, and 10 GbE ceilings shown beside the measured MB/s values.
Large downloads, video seeking, preview extraction, and HTTP range responses can read from chunked encrypted storage without reassembling an entire file into a temp object first.
Images, SVG, HEIC, PDF, text, audio, video, and 3D model previews exist because the storage engine can expose the right streams without making the UI wait on full-file rebuilds.
The deployment shape stays deliberately small: one Cotton Docker image plus Postgres, with EF migrations on startup and a setup wizard for storage, email, timezone, and telemetry choices.
The public performance story is tied to measured stages and visible network ceilings. Cotton compares SHA-256, Zstd compression, AES-GCM encryption, filesystem I/O, and synthetic pipeline numbers instead of pretending one isolated crypto number explains deployment throughput.
Cotton's performance pitch is simple: safety features belong in the fast path. Cotton does not ask admins to choose between encryption, previews, resumability, and throughput for normal file cloud work.
Benchmarks are local baselines, not a promise that every deployment saturates a link. Browser behavior, HTTP/TLS overhead, databases, disks, VM noise, file types, and concurrent users can all move the real ceiling.
Cotton is not chasing a synthetic number at the cost of the product path. The same model that enables encryption, compression, previews, sharing, restore, and range reads is the path users hit during normal file work.
The browser hashes chunks outside the main UI path, uploads several chunks at once, and retries only missing pieces.
Zstd compression runs before streaming AES-GCM, so storage savings and encryption happen during ingest instead of later.
Seekable chunk streams can serve downloads, previews, video seeking, ETags, and Range responses without temp-file reassembly.
Public network-fit claims use the slowest measured local write stage, not isolated crypto speed or a vague hero number.
Cotton performance copy now separates local processing evidence from live deployment behavior. That keeps the marketing sharp without pretending a machine-mode benchmark includes every HTTP and database step.
Cotton is built for sustained file-cloud behavior: chunk upload, inline compression, streaming encryption, seekable reads, and benchmark baselines that make hardware fit easy to discuss.
Real throughput still depends on CPU, file type, disk, S3 latency, Docker settings, TLS, database work, and client concurrency. Cotton exposes the path instead of hiding that complexity behind one inflated number.
They explain why encryption can stay enabled by default. The point is not to promise every server will hit the same number; it is to show that the crypto path is not meant to be the bottleneck.
No. The same chunk and manifest model also helps normal folders, previews, deduplication, snapshots, resume behavior, and background integrity checks stay predictable.
It is the safer baseline for many home NAS and small-office deployments. Faster links still matter, but 1 GbE avoids defaulting to a network most visitors do not actually run.