docs.page turns a public GitHub repo into a documentation site

What the service actually takes over

docs.page is described as instantly serving markdown from any GitHub branch as modern, agent-ready docs, with AI chat, MCP, and llms.txt, and the positioning line is Docs for humans + agents.

The value proposition is stated in the Should I use docs.page section: use docs.page when you want markdown from a public GitHub repository served as a modern documentation site for human readers and AI agents, without build pipelines, hosting setup, or a docs SaaS.

The Git publishing feature is the core of it. You deploy updates directly from your public GitHub repository, and the README says that eliminates build pipelines, hosting configuration, or infrastructure maintenance. That is a real reduction in moving parts, but it is also the whole design: the git repository is the source of truth and the branch is the version selector.

The interface is the modern one, styled using shadcn/ui design standards, and the components come from MDX, which the README says allows interactive components for richer experiences than standard Markdown. So the model is a static site whose content is your repository's markdown, extended with React components when a static page is not enough.

The homepage is docs.page and the documentation is at use.docs.page, with the project built and maintained by Invertase. The licence is Apache-2.0 and the last push was on 2026-10-22.

The agent-facing features, which are the differentiator

The first feature in the list is the one that distinguishes docs.page from a conventional documentation generator.

Every public site gets an MCP server and an auto-generated llms.txt. On top of that there are optional agent skills, and an Ask AI feature, marked as beta, so LLMs and readers can query the documentation without a separate mirror.

That combination is worth thinking about carefully. The MCP server means a coding agent can read and search the documentation as a first class tool rather than by fetching pages and guessing. The llms.txt file is the convention for telling a model what a site contains and how it is structured, so a model that is handed the URL knows where to look. The Ask AI chat is the human-facing counterpart, embedded in the site rather than bolted on as a third party widget.

The search feature is described in the same terms: a built-in full-text index with a Cmd+K shortcut, plus embedded AI chat, and it is positioned as locating information without third-party tracking scripts or external setup. That last point matters for a documentation site, because the usual way to add a hosted search widget is to ship a third party script to every reader.

The direction of travel here is that a documentation site now has two audiences, a person reading and a model querying, and the tooling has to serve both. docs.page treats the model as a first class consumer rather than an afterthought.

Setting it up, and where the site ends up

The quick start is unusually short, and it offers two routes.

The first is to hand the job to an agent:

Read https://use.docs.page/quickstart.md and set up docs.page in this repository.

The second is to do it yourself, with one command:

npx @docs.page/cli init

Then you push docs.json and docs/ to a public GitHub repository, and your site is live at:

https://docs.page/{owner}/{repo}

Two things are worth noting. The generated site is addressed by owner and repository, so the URL structure follows the git structure, and the initialisation produces two things: a docs.json configuration file and a docs/ directory of markdown. The CLI is published separately from the service, and the release history shows it moving fast, with cli-v2.2.0 on 2026-10-01 and cli-v2.1.0 on 2026-09-04.

The public requirement is not incidental. The README says to push docs.json and docs/ to a public GitHub repository, and the agent-ready feature is described as applying to every public site, so the whole llms.txt and MCP arrangement follows from the repository being public.

For local development of the platform itself, the root package.json shows the shape: a private package with an app/ directory and packages/* workspaces, built with Bun. The scripts are dev, which changes into app and runs bun dev, check, which runs the Biome linter with --write, and test, which runs bun test with coverage. The only runtime dependency is typescript at 6.0.3, with Biome 2.5.0 as the dev dependency for linting and formatting.

Branches as versions, and the release model

The branches and versions feature is the one that changes how a team works, because it makes the version selector a git operation rather than a configuration task.

Serve any Git branch, tag, or release as a distinct documentation site. Organise versions and live staging previews on the fly.

So a branch called v2.0.0 is a documentation site, and a feature branch is a staging preview, and both exist because the service renders whatever git ref you point it at. For a project with several supported versions, that removes the usual chore of maintaining a docs directory per version, and it means a release branch's documentation is the documentation that was written on that branch.

The repository layout backs up the split between the service and the client. There is an app/ directory for the service itself, packages/ for the workspace packages including the CLI, a skills/ directory for the agent skills, a docs/ directory for the site's own documentation, and a docs.json at the root. There is also an AGENTS.md, a CONTRIBUTING.md, a CHANGELOG.md, a PREVIEW.md, a biome.json for the linter configuration, bun.lock and bunfig.toml for the Bun toolchain, and an .nvmrc pinning the Node version.

The PREVIEW.md file at the root is worth noticing for a different reason. The feature list mentions live staging previews on the fly, and a document at the root of the repository explaining the preview mechanism is how a project documents behaviour that is otherwise invisible.

How it compares to Docusaurus, Mintlify and GitHub Pages

The README points at a comparisons page for exactly this question, and the framing of the Should I use docs.page section tells you which side of the comparison it is on.

Against Docusaurus, the difference is ownership of the build. Docusaurus is a static site generator, so the build and the hosting are yours to run. docs.page takes the repository and serves it, so you have no build to run and no output to host, and in exchange the site is served from their infrastructure with their URL structure rather than your own domain and your own hosting configuration.

Against Mintlify, the difference is similar in kind. Mintlify is the kind of hosted docs SaaS the README positions docs.page against. The README's phrase without build pipelines, hosting setup, or a docs SaaS is a direct claim on that comparison, and the mention of a docs SaaS is aimed at platforms of Mintlify's kind.

Against GitHub Pages, the comparison is about capability. GitHub Pages is the cheapest option, but it lacks the features in docs.page's list, from full-text search and MDX components to MCP, llms.txt and branch-per-version sites.

The honest summary is that docs.page sits between the two extremes. If you have no need for search, components or agent access, GitHub Pages is less machinery. If you need to own the deployment, the file is the point.

Where docs.page fits, and where it stops

The comparisons above give the shape, but the constraints are worth stating on their own.

The first is public. The README asks for a public GitHub repository, and the agent features are described as applying to every public site. If your documentation covers internal architecture, security design or anything else you would not publish, this service is not available to you, and the honest alternative is a generator you host yourself.

The second is that the service owns the presentation layer. The markdown is yours and the config is yours, but the theme, the search index, the MCP endpoint and the AI chat are theirs. A team that needs to change the URL structure, host on its own domain, or run a modified front end has to move to a different tool.

The third is that this is a hosted service with an open source client, and the two halves are versioned separately. The CLI releases are frequent, cli-v2.2.0 in October 2026 and cli-v2.1.0 in September, while the site behaviour is whatever the service currently serves. That is normal for a service, but it does mean the CLI version you pin and the site you get are not the same release train, and a behaviour change in the service can affect a site whose markdown did not change.

Against a self-hosted generator the trade is entirely about who does the work. A self-hosted setup costs you a build pipeline, a hosting target and the maintenance that comes with them, and it gives you everything. docs.page removes the first three and gives up the fourth, plus the ability to keep the docs private.

The Ask AI feature is explicitly in beta, and the optional agent skills are described as optional, so the agent-facing story is a direction the project is moving in rather than a finished set of guarantees. For a team deciding today, the search, the theming and the branch-per-version behaviour are the stable parts of the value, and the MCP and llms.txt work is the part most likely to change shape.

Editorial conclusion

docs.page suits a team whose documentation already lives as markdown in a public repository and who want a hosted docs site without maintaining a build pipeline or a hosting configuration, since the branch and the config file are the whole setup. It is the wrong tool if your docs are private, because the README requires a public GitHub repository, and it is the wrong tool if you need to control the hosting and the runtime, because the site is served by docs.page. Before adopting it, read the quickstart at use.docs.page, and check that the documentation you intend to publish is genuinely something you want in a public repository.

Frequently asked questions

Official sources

1. invertase/docs.page on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases