Docsheaf
Blog

Introducing Docsheaf

A docs platform that treats documentation changes like code changes — branched, reviewed and merged — and publishes sites that people and AI tools can both read.

The Docsheaf team · · 3 min read

Most documentation goes wrong slowly. A default changes, a flag is renamed, a step is added to the setup — and the page that was right last month is now quietly wrong. Readers notice before the team does.

Docsheaf is our answer to that problem: a docs platform where every change can be reviewed before it goes live, and where the published site tells you what readers could not find.

Write in a block editor#

Pages are built from blocks. Type / to insert headings, lists, code blocks with a title and syntax highlighting, tables, images, embeds, and the structured blocks technical docs need: hints in four styles, tabs, steppers and expandable sections. Markdown shortcuts work while you type.

What you see in the editor is what readers see. The editor and the published renderer emit the same markup, so there is no preview step to forget.

Review changes like pull requests#

Every space has a main branch. Teams that want every edit reviewed can lock it, so changes only arrive through change requests:

  1. Open a change request. Docsheaf branches the space and records the revision it started from.

  2. Edit freely. Main is untouched until you merge.

  3. Ask for review. Reviewers see a side-by-side or inline diff and approve or request changes.

  4. Merge. Docsheaf runs a three-way merge, so edits to different parts of the same page combine cleanly.

Merge rules are enforced by the API, not just the UI: when a space requires approval, a change request needs at least one approval and no outstanding "changes requested" review before it can merge.

We wrote more about how the merge works in How change requests merge block by block.

Publish sites, not just pages#

A docs site holds one or more spaces and publishes them as tabs of one branded site. Sites can live under a path, on a subdomain or on your own domain, and can be public or unlisted behind a share link. Readers get:

  • Fast, server-rendered pages with an outline and previous/next navigation

  • Full-text search with ⌘K

  • A "Was this helpful?" prompt on every page

  • Light and dark themes that follow your brand color

Built for readers that aren't people#

AI assistants and coding agents increasingly read docs on your readers' behalf. Every published page has a Markdown twin at the same URL with .md appended, and every site serves llms.txt and llms-full.txt, along with sitemap.xml and robots.txt. More on that in Making docs LLM-ready.

Learn what's missing#

Site insights show page views, visitors, feedback and the searches readers ran — including the ones that returned nothing. Zero-result searches are the most honest list of pages you haven't written yet.

Open by design#

Everything in the app is available over a REST API described with OpenAPI, using personal API tokens. Content can be imported from Markdown, including GitBook's {% hint %}, {% tabs %} and {% stepper %} tags, and every page can be read back as Markdown. Your content is never locked in.

What's next#

Real-time co-editing, two-way Git Sync with GitHub and GitLab, and an AI assistant grounded in your docs are next on the roadmap, followed by an MCP server for every site. We'll write about each one here as it ships.

Start for free, or sign in with the demo account and explore a published example site.

Accurate docs. Better answers.

Start writing for free, or talk to us about bringing your team and your existing docs.