Read the Docs alternatives

Read the Docs does a specific job extremely well: point it at a repo, and every push produces versioned, searchable, hosted documentation. For an open-source project it is close to the default answer, and deservedly.

Two situations fall outside it, and both come up constantly.

The two gaps

The docs are private. The free community service publishes open-source projects. Private documentation is a commercial-tier feature — reasonable, and often more platform than a team wants for an internal handbook that five people read.

You want to review one build, not host a site. A contractor delivering a docs set, an API reference going to a single customer, a spec that gets argued over before it ships — these want a link and a comment thread, not a hosting project with versions and a slug.

And underneath both: generated docs have no review surface. Sphinx and MkDocs emit static HTML. The only sanctioned way to object to a sentence is a pull request against the source, which is a wall for the domain expert, the lawyer or the customer whose feedback you actually needed.

The shortlist

1. Comma — publish a build, get comments on the rendered page

Docs generators produce a directory. Zip it and publish the bundle, so internal links, search assets and images resolve exactly as they did locally:

mkdocs build                       # or: sphinx-build -b html docs/ site/
cd site && zip -qr ../site.zip . && cd ..

curl -X POST https://commareports.com/api/v1/reports \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -F "title=Platform docs — v2 draft" \
  -F "visibility=link" \
  -F "bundle=@site.zip"

What that gets you that a docs host doesn't: per-report visibility (private, team, email domain, registered, unlisted link) with no project to create, and anchored comments — a reviewer selects the paragraph and leaves a thread on it, which survives re-publishing the next build to the same id. Non-engineers review the docs without ever seeing git.

Not for: being your project's permanent documentation site. Version switchers, a search index across releases, a custom domain and a redirect map are a docs platform's job.

Pricing: Free — unlimited reports, unlimited viewers and commenters.

Share a Sphinx docs build →

2. GitHub Pages — free, versioned by git, public off Enterprise

The most common self-managed answer: build in CI, push to gh-pages. Costs nothing, and private Pages needs an Enterprise plan. See GitHub Pages alternatives.

3. Cloudflare Pages / Netlify + an access policy

Build on push, and put SSO in front of the whole project. Real access control, and a project and identity policy you now maintain. See Cloudflare Access alternatives.

4. Self-hosted MkDocs / Sphinx behind your VPN

mkdocs serve on an internal box, or a static build behind your existing reverse proxy. Nothing simpler if the infrastructure already exists; nothing more annoying if it doesn't.

At a glance

Checked September 2026. Verify current plans before committing.

How to choose

• Open-source project docs with releases? Read the Docs. Still the right answer.
• An internal docs site with a permanent URL? Pages behind SSO, or the commercial tier.
• A build that needs signing off by people who don't use git? Publish it and let them comment on the sentence.

Related

• Share a Sphinx docs build · Share an MkDocs site · Share Docusaurus output
• Share OpenAPI docs · Comment on HTML
• All hosting alternatives