CLI

papervine is a local development tool. You run it inside a folder of MDX + a docs.json and it boots the Papervine renderer pointed at that folder, with live reload — the same renderer that powers hosted Papervine sites, so what you see locally is what you ship.

npx papervine dev          # preview ./ (must contain docs.json)
npx papervine dev ./docs   # preview a subfolder
npx papervine dev -p 4000  # preview on a specific port

What ships in the CLI

The CLI is just the renderer. It depends on @papervine/renderer (the shared render engine — MDX compilation, docs.json parsing, navigation, the component set, OpenAPI endpoint pages) plus Next.js and React. It deliberately carries none of the hosted control plane — no authentication, database, object storage, realtime, or AI assistant. Those are services of the hosted product, not things a local previewer needs, so they’re absent from the package entirely rather than disabled at runtime.

A practical consequence: the navbar’s search palette and “Ask AI” button are control-plane features supplied by the host app as optional slots. The CLI leaves them empty, so a local preview shows the docs chrome (logo, navigation, sidebar, table of contents) without them.

Trust and execution

papervine dev compiles and runs the repo’s MDX, which is arbitrary JSX/JavaScript. That’s expected for your own docs, but it means you should only run the CLI on docs repos you trust, the same way you’d only run npm install in a project you trust.

How it relates to the renderer package

Papervine is one repository that produces two products from a shared core:

The hosted control plane consumes the same @papervine/renderer, then adds multi-tenancy, Git sync, auth, analytics, and the assistant on top. Because the renderer is one shared engine, a docs repo renders identically whether you preview it locally with the CLI or deploy it to a hosted site.