Introduction
Papervine turns a folder of MDX into a fast, searchable documentation site — built for your readers and the AI agents they use.
Papervine turns a folder of MDX into a fast, searchable documentation site — built for your readers and the AI agents they use.
Papervine publishes documentation from your own files. Point it at a repository of MDX and a
docs.json — or start from scratch and write in the browser — and you get a complete site:
navigation, full-text search, dark mode, an API reference generated from your OpenAPI spec,
and an AI assistant grounded in your content.
Your docs stay files you own. There’s no proprietary store to get locked into, and no export step to escape.
Connect a repository and publish a site in about five minutes.
No repository? Write in the browser and publish from there.
Already using a docs.json-based platform? Most repos render unchanged.
There are three tabs at the top of this site, and they answer three different questions.
Product Guide — “how do I publish docs?” Writing pages, organizing navigation, publishing and syncing, connecting a domain, managing your team, and turning on features like search, the assistant, and reader access control. If you’re here to run a docs site, stay in this tab; everything you need is in it whether your site is hosted by us or served by the CLI.
Self-Hosting / CLI — “how do I run this myself?” The papervine CLI: serving a docs repo
from your own infrastructure, with no database and nothing to operate. Also where the model
configuration lives (the CLI has the same AI assistant), along with the renderer internals and
the contributor guide.
Control Plane — “how do I run the platform?” The multi-tenant dashboard side: platform accounts and sign-in, transactional email, the background services, and the operator view. This is a much bigger commitment than serving docs — most people who self-host want the tab above.
These docs are written in Papervine’s own format and rendered by Papervine itself. The
source lives in docs/ and is
crawled in CI as a renderer regression test. If you can read this page, the dogfood works.
Markdown with components when you need them. Unknown components degrade gracefully instead of breaking the page.
Cmd/Ctrl-K across every page, heading and code block. No separate service to run.
Drop in an OpenAPI spec for per-endpoint pages with a live “Try it” panel.
Answers grounded in your docs, with citations — and embeddable in your own product.
Studio, with real-time collaboration and an AI editing agent. No Git required.
Three rules shape most of how Papervine behaves. They’re worth knowing because they explain why the system fails softly.
Unknown components render their contents; a page that can’t compile shows an inline notice. A single bad page never breaks the site around it.
An unexpected docs.json field is passed through with a warning rather than rejected —
which is what lets a config written for another tool render unchanged.
Papervine follows the established docs.json schema and behavior so real repositories
migrate without edits.
These pages describe how the system works, in the present tense. For design decisions,
dated status notes, and roadmap rationale, see
SPEC.md.
Gate pages to reader groups; hidden pages don’t even appear in the navigation.