Encrypted File Storage

Honest security copy matters more than marketing adjectives, so here is precisely what files.link does and does not do. Every stored object is encrypted at rest, and every upload, download, and signed-URL fetch travels over TLS — so the bytes are protected on disk and on the wire by default, with no configuration on your part. That is server-managed encryption: the keys for the at-rest layer are held by the storage infrastructure, not by you.

We deliberately do not claim end-to-end or zero-knowledge encryption, because that is not how the default path works, and pretending otherwise would be dishonest. What actually keeps a sensitive file from being read by the wrong person is the access model layered on top: private files. A private file has no public URL and cannot be reached by guessing a path.

Each download requires a fresh signed URL that your backend mints on demand — the URL carries a cryptographic signature and a short expiry (10-minute default), and the storage layer rejects any request whose signature is missing, altered, or expired. So even if a signed link is forwarded or logged, it stops working within minutes. Mint the URL server-side, per request, so the signing path never touches the client.

If your threat model requires that even the storage provider cannot read the contents — true confidentiality against the host — the right pattern is client-side encryption before upload. Encrypt the bytes in your application with the Web Crypto API or libsodium, for example const enc = await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, data), then run the ciphertext through the standard three-call upload (POST /v1/files/{folderId}, PUT the encrypted bytes, POST /v1/files/confirm-upload). files.link stores and serves opaque bytes; decryption happens only in your client with a key we never hold.

In that model there is no customer-managed-key or BYOK feature to configure — the key you control is one we simply never possess. One caveat worth stating plainly: a public file is meant to be readable by anyone with the link, so encryption at rest protects it on disk but does not make a public URL a secret. If a file is sensitive, mark it private and serve it through signed URLs, or encrypt it client-side first.