Start free
Early accessRun DocFit on your real repos free while you help shape itFree for design partners

Documentation CI for GitHub

Your docs, updated the moment code merges.

When a PR merges, DocFit finds the docs pages it made wrong, makes the smallest edit that fixes them, checks the result and opens a pull request. Your team reviews and merges it.

Deterministic signals first. AI judgement second. Verification last.

Try it on your last 5 mergesSee how it works

Free for public repos 14-day Team trial No card

Example run: payments-api #482 → developer-docs #91, 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
  • Linear

< 5min

to your first docs PR, run on merges you already made

4checks

build, lint, links and spec, before a human looks

0merges

made by DocFit. Your team decides what ships

∞teammates

No per-seat pricing. Invite the whole team

The problem

Code ships daily. Docs drift quietly.

Every merge can make a page wrong. Nobody owns the update, and the first person to notice is usually a customer, reading about a field that no longer exists.

  • Nobody owns the update

    The docs task sits in a ticket nobody picks up. Writers find out about the change from a support thread.

  • Nothing connects the merge to the page

    Your docs host renders pages. Your code reviewer reads diffs. Neither knows which page a merged diff made wrong.

  • Catch-up never catches up

    A docs sprint fixes last quarter. By the time it merges, this week's changes have already drifted.

Every time docs fall behind, someone pays for it: an engineer gets interrupted, support answers the same question again, or a customer follows instructions that no longer match the product.

One merge, two workflows

  1. Code merged

    A field is added to POST /v2/refunds

  2. Nobody notices

    The docs still describe the old request

  3. A customer does

    Support gets the question, days or weeks later

  4. A docs ticket is filed

    It waits behind feature work

  5. An engineer rebuilds the context

    Finds the PR, the ticket, the pages

  6. Docs updated later, or never

    Meanwhile, the next merge has drifted

  1. Code merged

    A field is added to POST /v2/refunds

  2. Docs impact found

    From the diff, the API spec and the ticket

  3. Pages edited

    The smallest change that makes them right

  4. Checks run

    Build, lint, links and spec

  5. Docs PR opened

    With a reason for every page

  6. Your team reviews and merges

    In GitHub, like any other PR

The docs work never disappears. It just arrives late, from a customer.No docs ticket, no context-gathering, no sprint. One PR to review.

Why engineering teams care

Stop assigning engineers to documentation drift.

No new docs platform, no docs sprint, no extra task after every merge. DocFit turns docs upkeep into a normal engineering workflow your team already knows how to review.

  • Engineering leads

    Get engineers back. Docs maintenance stops depending on someone remembering that a code change also changed a page.

  • Maintainers

    Stale pages stop piling up. Every merge is checked, and changes with no docs impact stop on their own.

  • Developers

    No docs task to remember after the merge. The context is read from your PR and ticket, not your memory.

  • Reviewers

    A normal pull request, already checked, with a reason for every page it touches.

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, Linear 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 docs build, markdownlint and Vale with your config, internal and external links, Redocly or Spectral on the spec.

  • 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.
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.

Docs frameworks

Edits follow each framework's components, nav and build.

  • Mintlify
  • Docusaurus
  • Redocly
  • OpenAPIspec as docs
  • Scalar
  • Swagger UI
  • MkDocs
  • Markdownany docs/ folder
  • Nextra
  • VitePress

Code and tickets

Where changes come from, and why they were made.

  • GitHub
  • GitHub Issues
  • Jira Cloud
  • Linear

Notifications

Where DocFit reports back.

  • Slack
  • Email+ Monday digest
  • Discord
  • WebhooksHMAC-signed

Models

Routed per step. Bring your own key if you like.

  • Gemini
  • Claude
  • Vertex AIyour key
  • Anthropicyour key
  • OpenRouteryour key
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 stored per page and 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.

Choose speed or depth

Three presets route each step to the right model. Bigger changes use more credits on every preset.

  • FastGemini Flash throughout~1 credit
  • BalancedClaude Sonnet for bigger edits~2 credits
  • Best qualityOpus for breaking changes~4 credits

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 runs, failed runs and the install backfill are free. Out of credits, new merges wait. They're never lost.

Built for teams where docs live close to code

  • API teams

    Every endpoint change makes reference pages, examples and integration guides stale. DocFit catches them at merge.

  • Developer platforms

    SDKs, examples and how-to guides change with the product. DocFit keeps them in step with the code that changed them.

  • Open-source maintainers

    Keep docs aligned without adding another recurring chore. Free for public repos.

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

  • 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.

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

First docs PR in under 5 minutes

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

Usage-based. No per-seat fees.

Start free. Upgrade when DocFit becomes part of the team. Every plan includes your whole team, and runs that change no docs are free.

Free

For open-source projects and single repos

$0forever
Start free

No card, no time limit

  • Unlimited public repos
  • 1 private repo
  • 25 credits a month
  • 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
  • 200 credits a month
  • 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 with Growth

Cancel any time from the billing portal

  • Everything in Team
  • Unlimited private repos
  • 700 credits a month
  • 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 own build and lint commands first, then link checks and OpenAPI lint. 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, Nextra, VitePress 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.
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?
Not natively yet: DocFit runs on GitHub today. The DocFit CLI (docfit check) runs the same verifier in any CI, including GitLab CI, Jenkins and GoCD.

Your next merge shouldn't create a docs ticket.

Install the GitHub App, point it at your docs and see what DocFit would have changed in your last 5 merged PRs. Free for public repos; private repos get 14 days of Team, no card.

Try it on your last 5 mergesBook a 20-minute demo