Open-source file storage you run yourself: drop in 100 GB, walk away, and come back to done. No babysitting, no broken uploads, no "finalizing" freeze.
mountain-backup.jpg
lake-trip.heic
leaf-macro.jpg
spring-blossom.jpg
castle-raw.jpg
02:14walkthrough.movCotton Cloud ships real clients: an Android app and a Cotton Sync desktop agent for Windows and Linux. Install once, keep your files in sync.
The details that usually hide in a backlog. The developer wrote them anyway. Each one is a real product surface, not a screenshot from a pitch deck.
Pick the link you run on at home or at work. Cotton compares that network to the slowest measured local write-path stage, so the table reads like deployment capacity instead of a synthetic headline.
Pick the network you actually run. The comparison uses the slowest measured local write stage, because isolated crypto speed does not matter if hashing, compression, or filesystem I/O is slower.
These rows are real machine-standard runs from the Cotton benchmark harness, not hand-entered hero numbers. The public baseline JSON files live on GitHub, and the site revalidates them every five minutes.
Common home NAS and small office baseline. Compression, crypto, and disk only need low hundreds of MB/s to stay ahead.
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Estimated write-path processing limit versus 1 GbE practical ceiling of 112 MB/s. Uses the slowest measured local stage: SHA-256, Zstd compression, AES-GCM encryption, or filesystem I/O.
Cotton Cloud separates who owns a file from where the bytes live. The same file from ten users does not need ten physical copies. Each user keeps their own visible file, versions, shares and permissions; the chunks live once.
What most file clouds do. Easy to picture, expensive to grow, and you pay for every duplicate forever.
Some self-hosted clouds add encryption on top of naive storage. Security goes up, dedup goes to zero, disk bill stays the same.
Each user keeps their own file, versions, shares, permissions. The bytes live once. Hash identity, compression, encryption and manifests work together by design.
Upload, encrypt, store, preview, seek, share, verify, reclaim - all of it through one pipeline, same chunks, same model. A 10 KB note and a 100 GB folder follow the same code.
Seven things Cotton Cloud treats as table stakes. Most self-hosted clouds treat them as roadmap items, plugins, or someone-else's problem.
Next.js on the front, .NET on the back, Postgres underneath. New releases ship every few weeks. The product feels fast because the stack is fast, and the git log is public if you want to watch the work happen.
Streaming AES-GCM with per-chunk auth tags. Wrapped per-file keys. Selected folders go full client-side E2E with a vault key the server never sees. You don't toggle a setting to get security.
Content-addressed chunks (SHA-256). Each user still gets their own file, versions, shares, permissions -- but the storage cost is paid once. Dedup is the engine, not a plugin you install.
Background jobs randomly re-hash stored chunks and compare against the manifest. Silent disk corruption gets caught before users notice. Most self-hosted clouds learn about a dying disk from a bug report -- this one tells you first.
The master key never has to live in env vars -- unlock through the browser, key stays in process memory only. Sensitive database rows carry signatures derived from that key, so tampered users, tokens, or manifests get flagged on read. Admin Security Checkup reads 15+ container hardening signals (.NET diagnostics, seccomp, ptrace, dumpability, AppArmor) and gives you a score, not a 'skill issue'.
No Redis to keep alive, no plugin marketplace to babysit, no extra worker fleet. One Docker image runs the web UI, API, background jobs, previews, and storage pipeline. Start it behind your normal TLS edge, back it up, and leave the app shape boring.
Every detail you'll bump into -- restore UX, share lifecycle, mobile PDF, audio waveform, 3D preview, integrity signatures -- exists because the author got annoyed once and fixed it. Not because a roadmap PM scored it for backlog.
Product details that usually become roadmap tickets, plugins, or hidden admin chores. Cotton Cloud keeps them in the file workflow.
Three places where Cotton bites hardest. Twelve honest comparisons on the full table.
Generate a password. Paste it once. Mount a volume. That's it.
services:
postgres:
image: postgres:18
environment:
POSTGRES_DB: cotton
POSTGRES_USER: cotton
POSTGRES_PASSWORD: "replace with output of: openssl rand -base64 32"
cotton:
image: bvdcode/cotton:latest
security_opt:
- no-new-privileges:true
ports:
- "8080:8080"
volumes:
- /data/cotton:/app/files
environment:
COTTON_PG_HOST: postgres
COTTON_PG_DATABASE: cotton
COTTON_PG_USERNAME: cotton
COTTON_PG_PASSWORD: "same value as POSTGRES_PASSWORD"
# Optional unattended restarts; otherwise unlock in browser:
# COTTON_MASTER_KEY: "replace with output of: openssl rand -base64 24"Short, direct answers. The long version lives in the docs and in the deep-dive pages.
Yes. Cotton Cloud is self-hosted cloud storage for files, media, backups, sharing, WebDAV clients, snapshots, previews, and encrypted storage. You run it on infrastructure you control with Docker and Postgres.
Two layers. Storage chunks are encrypted with AES-GCM by default -- that's the standard. Selected folders can also use client-side encryption with a vault key that never leaves your browser. We don't call the whole thing "E2E" because that would be marketing fiction -- only the client-side folders are.
Different products. Most "personal cloud" platforms are kitchen-sink suites: calendar, contacts, chat, office, federation, 200+ apps. Cotton Cloud is a file cloud -- focused on storing, previewing, sharing, and recovering files at scale. If you live inside a suite, stay there. If files are the main job, switch.
Yes. Open the live demo -- it generates per-browser credentials and seeds a fresh account with default content. It's the real Cotton. Every click hits a real instance.
Named up front: client-side E2E is capped at 512 MB per file today (browser Blob pipeline), and the benchmarks are machine-mode baselines rather than live upload math. The storage crypto is by-the-book AES-GCM with no third-party audit yet.
Or run it yourself: docker compose up -d. Full source on GitHub, MIT-licensed. No signup, no upsell.