Vellum
Paste an HTML or Markdown document and get a private link that shows it as a finished, readable page, with the document scrambled in your own browser first so the server only ever holds unreadable text.
- Zero-knowledge
- a sealed page is encrypted in your browser, not readable by the server
- HTML or Markdown
- posted once, rendered as a finished page
- Collections
- many pages become one navigable docs site under one key
The problem
Sharing a nicely formatted document usually forces a bad trade. Hand it to a typical host and that host can read it. Send the raw file and the reader gets a wall of markup instead of a page. Neither option is private and readable at once. And letting a link render someone's arbitrary page markup is its own hazard: their scripts running loose in your page.
What it does
Vellum turns a document into a link that renders. You paste or drop in an HTML or Markdown document and get back a share link plus a private manage link. Opening the share link shows the document as a finished page: Markdown as a clean typeset reader, HTML running live but safely walled off. Pages stay re-readable until they expire (anywhere from a day to a year, 30 days by default) and can be revoked at any time. This is hosting, not a one-time reveal.
The whole thing is zero-knowledge by default. The document is encrypted in your browser before it's sent, and the key travels only in the link's fragment, which browsers never transmit. The server stores scrambled text and nothing else, not the words, the key, the passphrase, or even the title, and wraps every stored blob in a second layer of encryption at rest.
Beyond single pages, Vellum builds navigable documentation sites. A collection is one encrypted table of contents (folders, page order, titles) plus its pages, all under one key. Open one link and it becomes a sidebar-and-reader docs site, with folders that nest and an optional step-by-step flow. There's also an opt-in public mode that stores a collection in the clear so it can be keyless and search-indexable.
Accounts are optional. You can post and read anonymously, or sign in to own, list and share pages within an organization. The underlying chassis (accounts, encryption, storage) is shared with its sibling Tockermail; the rendered-document offering is what's new.
Key features
Links that render, not download
Recipients see a real page, typeset Markdown or live HTML, instead of a raw dump of markup.
Zero-knowledge by default
The host can't read a sealed document, because it's encrypted in your browser and the key never reaches the server.
HTML that runs but stays contained
An author's own styling and scripts work, but inside a walled-off frame with no access to Vellum, your cookies, or the surrounding page.
Whole docs sites from one link
Many pages become one navigable site, with a sidebar, nested folders and an optional ordered flow, all behind a single link and a single key.
Link, or link plus passphrase
Share just the link, or add a separately-sent passphrase so a leaked link on its own stays sealed, with expiry and one-click revoke.
Anonymous or account-owned
No signup needed to post or read; sign in only when you want to manage or share pages inside an organization.
Where it stands
Vellum is a working first version: anonymous posting, link-based viewing, sandboxed HTML and public docs sites are all verified in production. Web sign-in by email code is currently unreliable, so the signed-in account area and the drag-and-drop collection builder are tested at the code level rather than fully exercised live, and roadmap items (a programmatic create interface, more document kinds, image and file attachments, paid tiers) aren't built yet.
Under the hood: for the technically-minded
How it's built
Encryption happens in the author's and reader's browsers, never on the server. The browser makes a random 256-bit key, optionally mixes in a passphrase, stretches it with 600,000 rounds of PBKDF2, and encrypts the document with AES-256-GCM, tying it to the page's id so a blob can't be swapped between pages. The key lives in the link fragment. The server receives only the ciphertext and wraps it again under a server key before storing it. To open a page, the reader fetches the encrypted blob and decrypts it locally; the server hands over only non-secret details like the salt, never the content.
Rendering takes two safe paths. Markdown is converted and then run through a strict allowlist sanitizer into a clean in-app reader. Author HTML is dropped into a sandboxed frame with its own opaque origin and no same-origin access, so the author's scripts and styles run but are fully contained. Those two render modes are the security boundary.
Collections apply the same encryption to structure: the table of contents is sealed under one collection key, so the server can hold a docs site without reading its shape or its pages. The opt-in public mode is the deliberate exception, storing a collection in the clear so it can be keyless and indexable, guarded by rate limits rather than a login wall. Vellum was forked from Tockermail's chassis and shares its accounts, encryption and storage; only the offering differs.
The hard problems
Rendering untrusted page markup without opening a hole
Author documents can carry their own scripts, so HTML is confined to a sandboxed frame with an opaque origin and no same-origin access, while Markdown takes a separate sanitized path. Keeping those two modes cleanly apart is what makes rendering anyone's page safe.
Hosting documents while staying blind to them
The key rides in the link fragment and the server stores only doubly-wrapped ciphertext, so even a user's own list of their pages can't reconstruct a share link, because the key never reached the server in the first place.
Letting some pages be public without weakening the sealed default
Public docs sites intentionally store their contents in the clear so they can be keyless and searchable, so the plaintext and zero-knowledge modes had to coexist cleanly, with the keyless surface protected by per-visitor rate limits and quotas instead of a sign-in.
Built with
- React Router 8
- Web Crypto (AES-256-GCM)
- marked + DOMPurify
- better-sqlite3
- Sandboxed iframes
Building something in this space?
Work with us →