> ## Documentation Index
> Fetch the complete documentation index at: https://learn.mintlify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Preview deployments

> How Mintlify generates a live preview of your changes for every pull request, and how to use it effectively.

export const Quiz = ({question, answers, correctFeedback, incorrectFeedback}) => {
  const [selected, setSelected] = React.useState(null);
  const [checked, setChecked] = React.useState(false);
  const quizId = React.useId();
  const isCorrect = checked && answers[selected]?.correct;
  const reset = () => {
    setSelected(null);
    setChecked(false);
  };
  return <div className={"quiz-container" + (checked ? " quiz-checked" : "")}>
      <Badge color="green">Quiz</Badge>
      <p className="quiz-question" id={quizId + "-question"}>{question}</p>
      <div className="quiz-options" role="radiogroup" aria-labelledby={quizId + "-question"} aria-disabled={checked}>
        {answers.map((answer, i) => <label key={i} className={["quiz-option", !checked && selected === i ? "quiz-option-selected" : "", checked && answer.correct ? "quiz-option-correct" : "", checked && selected === i && !answer.correct ? "quiz-option-incorrect" : ""].filter(Boolean).join(" ")}>
            <input type="radio" name={"quiz-" + quizId} checked={selected === i} onChange={() => !checked && setSelected(i)} disabled={checked} />
            <span className="quiz-radio" />
            <span className="quiz-option-label">{answer.text}</span>
          </label>)}
      </div>
      {checked && <div className={"quiz-feedback " + (isCorrect ? "quiz-feedback-correct" : "quiz-feedback-incorrect")} role="status" aria-live="polite" aria-atomic="true">
          <span className="quiz-feedback-icon">{isCorrect ? "✓" : "✗"}</span>
          {isCorrect ? correctFeedback : incorrectFeedback}
        </div>}
      <div className="quiz-actions">
        {!checked ? <button className="quiz-btn quiz-btn-check" type="button" onClick={() => selected !== null && setChecked(true)} disabled={selected === null}>
            Check answer
          </button> : <button className="quiz-btn quiz-btn-reset" type="button" onClick={reset}>
            Try again
          </button>}
      </div>
    </div>;
};

<iframe className="w-full aspect-video rounded-xl" src="https://www.youtube.com/embed/GYzXpmN_--8" title="Preview deployments" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen />

Every pull request opened against your documentation repository gets its own preview deployment. Preview deployments are fully functional versions of your docs site with the proposed changes applied. They're live on the web, they look exactly like your production site, and anyone with the link can view them.

Before a single change goes live, you can see exactly what it looks like published.

## Where to find the preview link

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. You're looking at the actual rendered output: navigation, styling, component rendering, and page layout.

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. Review your changes thoroughly and make sure 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 from 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 to see 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.

<Quiz
  question="A product manager needs to review your documentation changes before they go live but doesn't have a GitHub account. How can they review?"
  answers={[
{ text: "Export the changed pages as PDFs", correct: false },
{ text: "Ask them to create a GitHub account", correct: false },
{ text: "Share the preview deployment link from the pull request", correct: true },
{ text: "Screenshot each changed page and send them over", correct: false },
]}
  correctFeedback="Right. The preview link is public to anyone who has it — no GitHub account required. Share it directly and they can review the exact published result, navigate between pages, and give feedback in context."
  incorrectFeedback="The preview deployment link is the cleanest solution here. It's public to anyone with the link, shows the exact published result, and requires no GitHub account or technical setup. Share it directly and they can review immediately."
/>

Next up: [Collaborating with your team](/courses/git-github/collaborating-with-your-team) — pull request reviews, working alongside engineers, handling merge conflicts, and keeping your branch protection rules intact.