Docxoft
One versioned home for every product's docs
Versioned document system for engineering teams. Publish OpenAPI specs, PRDs and runbooks once; every repo, app and AI agent reads the current version.
About Docxoft
Docxoft fixes the problem where the API spec lives in one repo, the PRD lives in a doc tool, and the runbook lives in someone's head. Publish a document once and every consumer — a backend repo, a mobile app, a coding agent — reads the current version from a single source of truth, scoped per project and versioned with semver.
Versions are immutable and every bump requires a changelog. OpenAPI documents are structurally diffed, so a breaking change is detected and forced into a major bump rather than shipped quietly. Dependency edges record which projects consume which documents at which version ranges, and full-text search returns the specific section with an anchor instead of dumping the whole file. AI agents connect through an MCP server over streamable HTTP with scoped service tokens, so they can search docs, check a changelog before upgrading and draft new ones.
Project Details
- Category
- DevTools / Documentation
- Compute
- Cloudflare Workers
- Database
- Neon Postgres
- Storage
- R2 object storage
- Formats
- Markdown, YAML, JSON, text
- License
- Apache 2.0
What Docxoft does best
Versioned Contracts
Semver on every document, immutable versions and a changelog required on each bump.
Breaking-Change Signals
OpenAPI documents are structurally diffed, so a breaking change cannot slip out as a patch.
Dependency Edges
See exactly which projects consume which document, and at which version range, before you change it.
Search By Section
Full-text search returns the matching section with a snippet and anchor — not a 400-line file.
Built For AI Agents
An MCP server with scoped service tokens lets coding agents search docs, read changelogs and draft updates.
Private By Default
Workspace, project and document-level permissions with role-based access control.
Overview
Docxoft is a versioned document system for engineering teams, built for the situation where the API spec lives in one repo, the product requirements live in a document tool, and the runbook lives in someone's head. Each of those is individually fine and collectively expensive, because there is no way to answer a basic question: which version of this contract is the mobile app actually built against?
A document is published once and every consumer reads the current version from a single source of truth, scoped per project and versioned with semver. Versions are immutable and every bump requires a changelog, which removes the common failure where a document changes underneath a team that had no reason to re-read it. OpenAPI documents are structurally diffed, so a breaking change is detected and forced into a major bump rather than shipped quietly as a patch.
Two things make it practical at team scale. Dependency edges record which projects consume which documents at which version ranges, so the blast radius of a change is visible before the change is made rather than discovered afterwards. And full-text search returns the specific matching section with an anchor instead of a 400-line file, which is the difference between documentation that gets read and documentation that gets skimmed. AI agents connect through an MCP server over streamable HTTP with scoped service tokens, so a coding agent can search docs, check a changelog before upgrading a dependency, and draft new ones.
How It Works
Publish a document to a project
Documents live under a project and carry a semver version from the first publish. Markdown, YAML, JSON and plain text are all first-class, so an OpenAPI spec, a PRD and a runbook sit in the same system rather than three tools with three permission models.
Version with an enforced changelog
Published versions are immutable and each bump requires a changelog entry. For OpenAPI documents the system diffs the structure and will not let a breaking change ship as a patch or minor bump, which turns a convention everyone agrees with into something the tooling actually enforces.
Record who depends on what
Consumers declare the documents and version ranges they build against. That produces a dependency graph you can query before making a change, so the question of who breaks is answered up front instead of during an incident.
Read it from code, or from an agent
Search returns the matching section with a snippet and an anchor rather than the whole file. AI agents connect over MCP with scoped service tokens, which lets them check a changelog before an upgrade and draft documentation, without handing them broad access to your workspace.
Common Use Cases
API contracts across teams
Backend publishes the OpenAPI spec once; web, mobile and integration partners consume a pinned version and get an explicit signal when a breaking change is coming rather than discovering it in a failing build.
Runbooks and operational docs
Incident procedures that are versioned and searchable by section, so the person on call at 3am finds the specific step rather than scrolling a long document written for a different audience.
AI-assisted development
Coding agents that need current, authoritative context. The MCP server with scoped tokens gives them the same source of truth your engineers use, which is what stops an agent confidently writing against a spec that changed two months ago.
What to Decide Early
Agree what a major bump means before you need one
The system enforces semver on structural OpenAPI changes, but plenty of breaking changes are semantic rather than structural — a field whose meaning shifts, a default that changes, an endpoint that becomes rate-limited. Teams that write down what counts as breaking for their own contracts get consistent versioning; teams that rely on the diff alone eventually ship a breaking change as a minor and lose trust in the signal.
Decide the project boundary deliberately
Projects are the unit of scoping and permission, so the way you draw them determines who can read what and how dependencies are expressed. One project per service is the common choice and usually right, but shared documents — a cross-cutting style guide, a company-wide error taxonomy — need a home that is not owned by any single service. Worth deciding before the first dozen documents exist.
Work out how much access AI agents should have
Service tokens are scoped, which makes it a design decision rather than an all-or-nothing switch. An agent that can read the current spec is straightforwardly useful; one that can draft documents needs a review path, and one with workspace-wide read access is a data exposure question. Decide this when you issue the first token, because tokens tend to get reused rather than reissued.
Frequently Asked Questions
Still have questions? Talk to our team
Need A Custom Solution?
Tailored To Your Exact Needs