Why I Built Capsule

Moving files between devices should not be this hard

I built Capsule because I wanted a fast, simple, private way to move files between platforms. That sounds like it should already exist. It mostly does not. Why is it so hard to move a photo?

Emailing yourself a file to get it from your Android phone to your Mac is embarrassing. Uploading a photo to Google Drive just to download it on another device a minute later is the same. There is no good reason a simple file handoff should require signing into an account, syncing a library, or navigating a cloud storage dashboard.

Quick Share and AirDrop now have cross-platform support, which is progress. But they are still unreliable in practice, require both devices to be on the same network or nearby, and offer exactly zero support for anyone running Linux. A curl command works everywhere, needs nothing installed, and takes about three seconds.

Files shouldn't live forever

Persistent cloud storage is the default, but it's the wrong model for quick transfers. When you send a coworker a config file or drop a script to a server, that file has no business sitting in someone else's cloud indefinitely. Capsule files auto-delete after 60 minutes. The 60-minute limit is a deliberate privacy boundary for ephemeral handoffs, not a storage cost optimization.

Most services require an account, store your data, and serve ads

WeTransfer shows ads next to your files and sends data to tracking companies like Google and Facebook. Dropbox requires your full name, email, and other personal information. Google Drive ties every upload to a Google account. Capsule requires nothing: no email, no name, no account. Upload, share, done. Or, a service can just be down entirely. Then what? Capsule's entire architecture is fully open source, allowing anyone to run the service themselves.

Zero-knowledge encryption, not a promise

When you choose to encrypt, the file is transformed on your device before it ever touches the network. This happens in the browser, the CLI, and the Android app alike. Capsule uses the age v1 format with a 12-word BIP39 mnemonic passphrase. The mnemonic is generated locally, stays on your device, and is never transmitted. The server receives ciphertext and nothing else. If you lose the key, nothing can save that file. This is architecture, not a policy commitment.

Works across all clients

A file encrypted on the web can be decrypted in the CLI, and vice versa. The web UI, CLI, and Android app all produce compatible age ciphertext with no proprietary format. If you encrypt with one client, any other can decrypt. Read more about the technical security design →

People deserve better tools

Most file-sharing services assume you have a browser open. Or come with other sorts of issues. Capsule is curl-native: one command, one link, done. Designed to be simple with a "just works" philosophy.

curl -F "f=@photo.jpg" https://send.withcapsule.dev/upload

The CLI adds encrypted transfers, local transfer history, and self-hosting. The same API the web interface uses is what your scripts use. There is no hidden layer or separate tier. See the API reference ↗ for direct integration.

Self-hostable, fully open source

The Capsule server is published under AGPL-3.0 on GitHub ↗. You can audit every line of code that handles your upload, run your own instance, and point the CLI at it. Nothing about using Capsule requires trusting Capsule specifically.

How Capsule compares

1. No account required. WeTransfer requires one for large files; Google Drive and Dropbox always do.

2. No ads and no upsell tiers. Free to use.

3. Files deleted in 60 minutes, not "eventually" or "when storage is full".

4. Server is fully open source (AGPL-3.0) ↗. Google's and Dropbox's servers are proprietary; WeTransfer is closed source.

5. Self-hostable. None of the above support running your own instance.

6. curl compatibility. Browser-only alternatives offer no scriptable API without a paid plan or unofficial hacks.

Sean Singh

Capsule was built by Sean Singh ↗. Read about the motivation and design decisions on the blog ↗. Contributions are welcome. The server and CLI are both on GitHub ↗.