Skip to main content
Every pull request opened against your documentation repository gets its own preview deployment — a fully functional version of your docs site with the proposed changes applied. It’s live on the web, it looks exactly like your production site, and anyone with the link can view it. This is one of the most practical parts of the Mintlify workflow. Before a single change goes live, you can see exactly what it looks like published. When you open a pull request, the Mintlify GitHub app posts a comment with the preview link. You’ll also see it in the PR’s checks section at the bottom of the page. The preview is ready within a minute or two of the PR being opened, and it updates automatically every time you push new commits to the branch. You don’t need to do anything to trigger it — as long as the Mintlify GitHub app is installed on your repository, previews happen automatically on every PR.

What the preview shows

The preview is a complete deployment of your docs site — not a diff view, not a staging approximation. You’re looking at the actual rendered output: navigation, styling, component rendering, page layout, everything. This means you can catch things that are invisible in a text diff:
  • Navigation entries that are broken or out of order
  • Pages that are missing from the sidebar
  • Formatting that didn’t render as expected
  • Broken images or links that resolve incorrectly
  • MDX components that fail silently
Reading a diff tells you what changed. The preview tells you whether it looks right.

Using the preview effectively

Open the preview and navigate to the pages that changed. Don’t just check that the changes are there — check that the surrounding context still makes sense. A heading change that looks fine in isolation might create a confusing flow when you read the section start to finish. A few things worth checking on every PR:
  • The changed pages render correctly and the content reads as intended
  • The navigation reflects any structural changes accurately
  • Internal links on the affected pages resolve correctly
  • The page looks right on a smaller screen if your readers use mobile

Sharing previews with stakeholders

The preview link is public to anyone who has it, which makes it easy to share with people outside your immediate team. Product managers, engineers, and subject matter experts can review documentation changes in context — seeing the actual page rather than reviewing a raw markdown diff in GitHub. This is particularly useful when the content requires sign-off from someone who doesn’t work in GitHub day to day. Send them the preview link, ask them to review the specific pages that changed, and they can give feedback without needing a GitHub account or any familiarity with pull requests. Once a PR is merged and the branch is deleted, the preview link stops working. The changes are now live on your production site. Next up: Collaborating with your team — pull request reviews, working alongside engineers, handling merge conflicts, and keeping your branch protection rules intact.