Introduction

docs.page is a docs-as-code platform with no hosting setup: documentation for humans + agents, served from any public GitHub branch. Push updates and the live site refreshes instantly. It is free and open-source.

docs.page is for teams who want professional, developer-focused documentation without the infrastructure tax. Docs live next to your code in the repository. Easy for humans and agents to author. Easy for humans and agents to consume.

It is a strong fit for:

• Open-source maintainers and SDK authors who want docs that stay in sync with source code, without static site generation, deploy pipelines, or hosting to maintain.
• Product and content teams who want Mintlify-level polish without paying for a SaaS docs platform.
• AI-forward integrators who need documentation optimized for human reading and LLM ingestion from day one.

docs.page uses Git publishing: it fetches your repository content, caches rendered pages at the edge, and serves a complete documentation site from any branch, tag, or release. You do not run a local build or upload artifacts to a host. See Public GitHub hosting for URL patterns, caching, and branch previews.

Every docs.page site needs two things in a public GitHub repository:

• docs.json at the repository root: site name, navigation, theme, and other configuration
• docs/**/*.mdx or docs/**/*.md: your documentation pages as Markdown or MDX (with optional subdirectories)

Push to GitHub and the site is live. There is no dashboard deploy step and no hosting account to configure.

Documentation is served at:

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

For example, a repository at https://github.com/acme/my-project is available at https://docs.page/acme/my-project. Individual pages follow the path of their file under docs/; docs/usage.md or docs/usage.mdx becomes /usage.

Use branches & versions to serve a branch, tag, or release at a distinct URL, for example https://docs.page/acme/my-project~v2. See Branch preview.

Because docs.page handles rendering and hosting, you can skip the usual documentation infrastructure:

• No build pipelines: no webpack, static site generator builds, or static export in CI
• No hosting configuration: no storage buckets, CDNs, or DNS to set up per site
• No docs dashboard: configuration is a file in Git, not a web UI

You still use Git for versioning, branches, and pull requests, the same workflow you already use for code.

docs.page works well when most of your documentation is Markdown-based, you want instant publishing from GitHub, and your content can live in a public repository.

It is a strong default for open-source libraries, SDK docs sites, and product docs that teams are comfortable publishing publicly. If you need a heavily customized documentation experience (bespoke routing, proprietary auth gates, or a private-only docs site), a self-hosted static generator or custom app may be a better fit.

For side-by-side comparisons with Docusaurus, Mintlify, GitHub Pages, and similar tools, see Comparisons.