Start free

Documentation CI for GitHub

Your docs, updated the moment code merges.

When a PR merges, DocFit reads the diff and linked ticket, finds the exact docs pages affected, runs your docs build and checks, and opens a pull request for your team to review.

Dry-run on 5 PRs, freeSee a real docs PR ↗

Free for public repos + 1 private 14-day Team trial No card

100% read-only dry run during setup. It opens zero PRs and sends zero alerts until you turn a repo on. Why each permission is needed

Real example on GitHub: example-payments-api #1 → example-payments-docs #1, one merge in, one checked docs PR out

Works with the docs and GitHub workflow you already have

  • Mintlify
  • Docusaurus
  • Redocly
  • Scalar
  • Swagger UI
  • OpenAPI
  • MkDocs
  • Markdown
  • GitHub
  • Jira
  • Slack

5PRs

dry-run automatically at setup so you can inspect real output before enabling a repo

4checks

build, link check, OpenAPI lint and your repo scripts run before a human looks

0merges

made by DocFit. Your team decides what ships

∞teammates

No per-seat pricing. Invite the whole team

Why DocFit is different

Deterministic signals first. AI judgement second. Verification last.

DocFit isn't an AI with access to your repo, guessing which pages look related. It works out what a merge actually affected, makes the smallest edit, proves it, and hands the decision to your team.

01 Knows what changed

A diff says what changed. The ticket says why.

DocFit reads the PR the way a reviewer would, and the ticket behind it, so the docs explain intent, not just the new field, and a ticket's acceptance criteria end up on the page.

Pull request

Add refund reason to POST /v2/refunds

#482 · 3 commits · 2 review comments

Diff

src/refunds/create.ts+18 −2

openapi/spec.yaml+9

src/events/RefundEvent.ts+3

Ticket · API-1234

Refund reason on create refund

3 acceptance criteria · fix version 2.14

Skip check · fast model, under a cent

Docs affected public endpoint and webhook payload changed

Change record

Endpoint
POST /v2/refunds
New param
reason enum · optional
Event
refund.created carries reason
Breaking
No
Audience
API users, support

  • The whole change, not just the diff

    PR title and body, commits, review comments, and the linked ticket's description and acceptance criteria.

  • Jira Cloud and GitHub Issues

    The ticket is found from the branch, title, commits and body, limited to the projects you allow.

  • Skips cheaply, and says why

    A fast first pass decides whether docs can be affected at all. If not, one comment on the PR, and no credits used.

  • Technical details
    • Every run starts from a structured change record: endpoints, parameters, behaviour, config flags, a breaking flag and who it affects. Everything after works from this.
    • Ticket keys match [A-Z][A-Z0-9]+-\d+ in the branch, title, commits and body, in that order; GitHub Issues links like Fixes #123 count too.
02 Knows what matters

Finds the pages that are now wrong. With reasons.

Not every changed file means a docs change, and DocFit doesn't treat semantic similarity as proof. It combines the change itself, the API spec, code symbols, repo history and your rules to decide what's affected.

What changedDocs pages · confidencePOST /v2/refundsopenapi/spec.yamlREFUND_REASONSsrc/refunds/create.tsRefundEvent.tspayload + reasonAPI-1234Jira acceptance criteriapayments/refunds.mdxwill be edited0.94webhooks/refund-events.mdxwill be edited0.88changelog/2026-10.mdxwill be edited0.71payments/overview.mdxbelow threshold · left alone0.32
  • API spec diff
  • Code symbols
  • Semantic search
  • History & rules

  • Deterministic signals first

    An OpenAPI diff of the changed operations, and code symbols from the diff (routes, exports, enums, env vars, CLI flags) matched word for word against your pages.

  • What your team did before

    Pages that similar changes touched in past runs and reviewer-merged PRs, plus your rules that name paths.

  • Every page has a reason

    Pages are ranked with the signal that found them. Weak matches are left alone, not guessed at.

  • Technical details
    • Semantic search runs over your docs indexed by heading, refreshed on every push to the docs target, so it reflects today's pages.
    • When the signals agree, confidence is high. When only one fires, DocFit says so in the PR, and low confidence opens a draft.
03 Proves the result

Edits like your team writes. Then proves it.

The difference between a docs PR you can merge and one you have to rewrite is proof. Every docs PR ships with the result of your own build and lint, not a model's word for it.

verificationisolated container · no network for the agent
  1. docfit verify · acme/developer-docs · docs/payments · attempt 1
  2. $pnpm docs:build✓ 38.2s
  3. $markdownlint docs/payments✓ 0 issues
  4. $vale docs/payments✗ 1 error
  5. refunds.mdx:42:18 Use 'API key' instead of 'api-key'. Acme.Terms
  6. ↻repair 1 of 3 · edited payments/refunds.mdx:42
  7. $vale docs/payments✓ 0 issues
  8. $docfit links docs/✓ 214 links · 0 broken
  9. $spectral lint openapi/spec.yaml✓ 0 problems
  10. ✓All checks passed · confidence Medium (1 repair)

Framework defaults, when you have no commands

  • Mintlifymint broken-links
  • Docusaurusnpm run build
  • Redoclyredocly lint
  • MkDocsmkdocs build --strict

Hard limits on every edit

  • Never changes OpenAPI paths, schemas or types
  • Never deletes a page or reorders your nav
  • Writes only inside the docs target

  • Minimal edits in your framework's idiom

    MDX components like <ParamField>, frontmatter, nav files, OpenAPI descriptions and examples. Your rules apply on every run.

  • Build, lint, links, spec

    Your repo's configured scripts run first (checks.commands / package.json), then framework defaults fill the gaps: mint broken-links, npm run build, redocly lint, mkdocs build --strict.

  • Code samples that actually run

    curl, JS, Python and PHP samples run against a mock built from your spec (Team), or your own sandbox (Growth).

  • The AI is boxed in

    It only touches your docs, has no network access, and the final diff is checked before the PR opens.

  • Technical details
    • Your own commands run first: checks.commands, then package.json scripts, Makefile targets and CI steps. Framework defaults only fill the gaps.
    • Failures go back to the agent, up to 3 attempts. Still failing? The PR opens as a draft with the failures listed.
    • Diffs, tickets and docs are treated as untrusted input and fenced, so text inside them can't pose as instructions.
04 Leaves it to you

Opens a PR a human merges. DocFit never does.

Human-controlled by design: DocFit opens the PR, your team decides what ships. It never changes a ticket's status or writes outside its own docfit/ branches.

payments-api #482 · merged PR

docfit bot commented

Docs updated. developer-docs #91 changes 3 pages and is waiting for @docs-team.

API-1234 · comment

DocFit · 2 min ago

DocFit: docs PR developer-docs #91 opened. 3 pages updated, checks passed.

docs-updated status unchanged

#docs

DocFit APP

Docs PR ready for review · developer-docs #91
payments-api #482 · 3 pages · checks passed · High

ViewSkip

Monday digest · example

Your docs kept up with 11 merges last week

9docs PRs
8merged
~6hsaved

New rule learned: "Write API key, never api-key or token." Approve

  • A PR body you can scan in ten seconds

    A one-line verdict, a table of pages and why, check results, confidence and the rules it used.

  • Drafts when it isn't sure

    Low confidence or failed checks open a draft instead of a ready PR.

  • Reports back where you work

    One comment on the merged PR, one on the ticket, a Slack ping with View and Skip, and a Monday digest.

  • Steer it from the PRTeam

    @docfit regenerate, explain, include <path> and skip, right in the conversation.

  • Technical details
    • Same repo: DocFit branches from the new HEAD of your trigger branch. Separate docs repo: from its default branch, with a link back to the source PR.
    • Re-runs update the same docfit/<repo>-pr-<n> branch and PR instead of opening a duplicate.
Security

Your source code is never stored.

DocFit reads your change to write your docs. It doesn't keep your code, train on it, or touch anything outside your docs.

See the full security model

    One run, start to finish

  1. 00:00

    Shallow clone

    Just the merge commit, limited to your docs folder where there is one

  2. 00:06

    Read diff, PR and ticket

    Untrusted text is fenced; nothing in it is ever executed

  3. 01:54

    Edit and verify

    Writes only inside the docs target; the agent has no network

  4. 02:15

    Docs PR opened

    One commit on a docfit/ branch. Never merged by DocFit

  5. 02:16

    Clone gone

    The run ends and the container goes with it. Your source code is never saved

Least-privilege GitHub App permissions, explained:

  • Contents (Read & Write):

    Required by GitHub to read diffs and push commits to docfit/* branches. Hard-blocked in code from ever writing to main or modifying files outside your configured docs path.

  • Pull Requests (Read & Write):

    Reads merged PR context and opens docs PRs.

  • Issues (Read & Write):

    Reads linked GitHub Issues for acceptance criteria and posts a single link comment when a docs PR opens (completely silent during setup dry runs).

Inspect the full permissions table and security model

  • Source code never stored

    Each run works in a short-lived container. Your source code, PR descriptions and ticket text are never kept.

  • Never used for training

    Models run under API terms that exclude training on your data. Bring your own key to keep inference in your own account.

  • Only the repos you pick

    A least-privilege GitHub App. Every repository stays off until you turn it on.

  • Never merges

    DocFit opens the PR. Your team decides what ships, and uninstalling stops access at once.

Keep your docs stack

Don't migrate your docs.

DocFit isn't your docs platform. It's the layer that keeps the docs inside it from drifting. Your docs stay in Git, your build stays in place, and DocFit contributes through normal pull requests.

acme/payments-api · .docfit.ymlsynced with dashboard
1# every key is optional; auto-detect fills the rest2trigger:3  branches: [main, release/*]4  paths_include: [src/api/**, openapi/**]5  skip_labels: [no-docs]6  skip_authors: [dependabot[bot]]7docs:8  mode: external9  repo: acme/developer-docs10  path: docs/payments11  framework: mintlify12  openapi: openapi/spec.yaml13tickets:14  provider: jira15  projects: [API, PLAT]16checks:17  commands: [pnpm docs:build, pnpm docs:lint]18  links: true19  openapi_lint: true20review:21  reviewers: [docs-team]22  min_confidence: medium23rules:24  - New endpoint pages get curl and Python examples.

Repository settings · Branches

main ×release/* ×.docfit.yml

Saving here opens a PR to .docfit.yml.

  • Runs on the merges you choose

    Branches like main and release/*, path filters, skip labels such as no-docs, and bot authors like Dependabot.

  • One config, two editors

    .docfit.yml and the dashboard stay in step. Every setting shows where it came from, and saving in the UI proposes a PR to the file.

  • Any past PR, on demand

    Run on a merged PR by URL, a list or a date range. During setup, DocFit dry-runs your last 5 merges.

  • Same repo or a separate one

    Docs next to the code, in their own repo, or rendered straight from an OpenAPI file.

Learns from every review

Review once. It remembers.

Reviewers turn corrections into rules. DocFit applies them on every later run, so nobody gives the same feedback twice, and each rule shows how often it's used and how often reviewers kept its effect.

Example

payments/refunds.mdx line 42
42Pass your api-key in the Authorization header.
M

meera reviewed · 3 weeks ago

We say "API key", never "api-key" or "token". Everywhere, please.

docfit bot replied

Fixed here. I also proposed a workspace rule so this sticks: Write "API key", never "api-key" or "token".

Write "API key", never "api-key" or "token".

Active
Used14
Kept by reviewers93%
ScopeWorkspace
The Learnings page: two proposed rules waiting for approval, and active rules with how often each was used and kept by reviewers.

  • Reply to teach

    Answer DocFit on a docs PR like you'd answer a teammate. Replies that read like instructions become proposed rules.

  • Edits count too

    The diff between DocFit's commit and what your reviewer merged is learned from.

  • Admins approve

    New rules wait for an admin. The Monday digest repeats the ask. Scope a rule to the workspace, a repo or a path.

  • Rules in code

    Rules in .docfit.yml apply on every run and every plan, and every PR lists the rules it used.

Built for real teams

The details that make it safe to turn on.

No docs yet? It starts them.

Pick a folder or a new repo and a framework. DocFit reads the code (README, manifests, OpenAPI, routes and handlers, never tests or build output), plans 4–12 pages and opens a starter docs PR with the framework's config. Then it keeps them in step.

Bring your own key

Model calls go to your own Anthropic, Vertex AI or OpenRouter account, and each docs PR uses a flat 2 credits however large the change.

Anthropic Vertex AI OpenRouter

Hear from it only when it needs you

Email or Slack when a docs PR needs you or a run fails, and a Monday digest of what DocFit did last week.

Everyone's included

No per-seat charge. Invite by email or share a link for your company domain. Admins manage repos, integrations and billing; members run, review and teach.

Pay for docs PRs, not merges

Runs that change no docs, skipped internal changes, failed runs, and your 5-PR setup dry run are free. You only use your plan allowance when DocFit opens a docs PR.

The dashboard

Your team reviews in GitHub. The dashboard is for setup and answers.

No new workflow to adopt. Use the dashboard to connect repos, see what each run did and why, and manage rules, usage and your team.

Activity: a greeting with what needs attention, four numbers with sparklines, and a table of runs with their status, docs PR and checks.
Run detail: what changed, the three pages edited with their reasons and a diff, checks, timeline and the learnings used.
Onboarding: five repositories matched to their docs, with framework and spec detected, three of them selected.

The run feed is home

  • What needs your review, first
  • Every merge with its status and checks
  • Filter by status or repository

Every decision, explained

  • The change record in plain words
  • Pages, reasons and the diff
  • Checks, timeline and rules applied

Safe, read-only setup in 3 steps

  • Repos matched to their docs automatically
  • Mintlify, Docusaurus, Redocly, MkDocs detected
  • Silent dry run on your last 5 merges
Pricing

Usage-based. No per-seat fees.

Start free. Every plan includes your whole team, and merges with no docs impact are always $0.

Free

For open-source projects and single repos

$0forever
Dry-run 5 PRs free

No card, no time limit

  • Unlimited public repos
  • 1 private repo
  • Up to ~12 docs PRs a month (25 credits; skipped merges are free)
  • Build, lint, link and spec checks
  • Jira, GitHub Issues and Slack
  • Rules from .docfit.yml, plus one workspace rule
  • Unlimited teammates
Recommended for teams

Team

For engineering teams shipping a few APIs or products

$49per month
Start 14-day trial

14-day trial on private repos, no card

  • Everything in Free
  • Up to 5 private repos
  • Up to ~100 docs PRs a month (200 credits; skipped merges are free)
  • Learnings: approve rules from reviews
  • Bring your own model key
  • Batching and pre-merge impact check
  • Code samples run against a mock

Growth

For API companies running DocFit across many repos

$149per month
Start 14-day trial

Cancel any time from the billing portal

  • Everything in Team
  • Unlimited private repos
  • Up to ~350 docs PRs a month (700 credits; skipped merges are free)
  • Insights CSV export
  • Code samples run against your sandbox
  • Nightly drift scan of all docs
  • Public API, webhooks, org-wide defaults

Compare plans and see how credits work

FAQ

Questions, answered

Does DocFit ever merge anything?
No. DocFit opens pull requests and posts comments. A person on your team reviews and merges every docs PR. It also never changes a ticket's status and never pushes outside its own docfit/ branches.
What happens when a merge doesn't need a docs change?
A fast first pass decides whether docs can be affected at all. If not, DocFit leaves one comment ("No docs impact" and the reason) on the merged PR and stops. Those runs are free.
How do you know the docs PR is right?
Every docs PR is built and checked before anyone sees it. Your repo's configured checks run first: checks.commands in .docfit.yml, then package.json scripts, so Vale, markdownlint or Spectral run when your scripts call them. Anything left uncovered falls back to framework defaults: mint broken-links, npm run build, mkdocs build --strict, and redocly lint on the spec. Failures go back to the agent for up to three repairs. If checks still fail, or confidence is low, the PR opens as a draft with the problems listed.
Do you store our code or train on it?
No. Each run works in a short-lived container that's gone when the run ends, and your source code is never written to DocFit's database. Models run under API terms that exclude training on your data. See Security.
Which docs setups does it work with?
Mintlify, Docusaurus, Redocly and other OpenAPI-rendered sites (Scalar, Swagger UI), MkDocs and plain Markdown folders. Docs can live in the same repo as the code, in a separate docs repo, or in the OpenAPI file itself. Out of the box DocFit runs the framework's own build and link checks, and redocly lint on OpenAPI specs; custom checks such as Vale, markdownlint or Spectral run when you configure them in package.json or .docfit.yml.
How does pricing work?
Plans are usage-based, with no per-seat fees. Each docs update DocFit opens uses credits: about 2 for a typical docs PR on the Balanced preset; bigger changes use more. With your own model key every docs PR is a flat 2 credits. Runs that change no docs, skipped and failed runs, and the install backfill are free.
Can we teach it our style?
Yes. Reply to DocFit on a docs PR and it proposes a rule; an admin approves it. Rules can also live in .docfit.yml. Every PR lists the rules it used, and each rule shows how often reviewers kept its effect.
We use GitLab or Bitbucket. Can we use DocFit?
Today, DocFit runs as a GitHub App. Native GitLab and Bitbucket support are next on our roadmap. Drop your work email below and select your git host to get early access when it ships.

Your next merge shouldn't create a docs ticket.

Connect the GitHub App and run a silent dry run on your last 5 merged PRs inside the dashboard. Nothing is opened or posted on your repos until you choose.

Dry-run on 5 PRs, freeSee a real docs PR ↗