A cloud project can be sealed so that the server stores it but can never read it — not the text, not the titles, not the figures. This guide explains what that buys you, what it costs, and how to use it without locking yourself out.
When you turn on end-to-end encryption for a project, your device generates a 256-bit key and encrypts every document, resource and the binder manifest with AES-256-GCM before anything is uploaded. The server receives ciphertext and stores ciphertext. It can tell that a project exists and how large it is; it cannot see a title, a sentence, or a figure.
The key travels in one place only: the fragment of the share link, after the # — …/p/‹id›#‹token›.‹key›. Browsers never send a URL fragment to a server, and the Mac and iOS apps keep it in the same place, so the key reaches your devices and the people you share the link with, and no one else.
Everything that happens on a device works as before, because the device holds the key: editing on the Mac, iPhone, iPad and in the browser; sync between them; live co-editing, where the updates are relayed through the server still sealed and opened only on the other end; version history, which is merged on your device rather than on the server; and sharing — send the full link, key included, to a co-author and they have the project.
Password-protected sharing is a different, lighter thing: the server checks the password, and the server can read the project. Use it for convenience; use a sealed project when the content itself must stay private.
Some features exist precisely because the server can read your project, and those stop for a sealed one. The server cannot compile its own copy, so a PDF from the iPhone or iPad goes a different route (below). A sealed project can't be made a community template or moved to the public space, and there is no published read-only view of it — a reader would have to be given the key. Server-side search and the browser's typeset preview also need a readable copy.
On the Mac none of this matters much: the Mac app compiles locally with its own pandoc, LaTeX and Typst, and the file never leaves your computer.
The phone has no typesetter, so Compile normally runs on the Folio Cloud server. For a sealed project the app explains what it is about to do and asks first: one readable copy is sent to the server for the duration of the compile and deleted the moment it finishes — never stored, logged or used for anything else. Decline, and nothing is sent. The on-device Preview Manuscript ▸ Share as PDF never uploads anything at all, sealed or not.
Because the server never has the key, it also can't give it back. If you lose every device and every copy of the link, the project is unrecoverable — by design. Two safeguards: keep the share link somewhere safe (a password manager is ideal), and set a recovery passphrase. The passphrase wraps the key on your device (PBKDF2 then AES-GCM) and the wrapped box is kept with the project; the server holds an opaque blob it cannot open, and hands it back to the owner to be unlocked with the passphrase on a device.
If a link has been exposed, the owner can rotate the key: every document and resource is re-sealed under a new key on the device, open sessions are fenced out, old links stop working, and the project is shared again with a new link.