Files
mintlify__docs/deploy/ghes.mdx
Ethan Palm 017d7c7377 Fix Vale warnings (#6378)
* fix: reduce Vale false positives via vocab and config updates

- Make English-word vocab entries case-insensitive so sentence-start
  capitalization and normal prose usage stop flagging (agents, rest,
  cursor, setup, endpoints, etc.)
- Add vocab entries for filenames and code identifiers that appear in
  frontmatter and JSX contexts (docs.json, llms.txt, CLAUDE.md, etc.)
- Ignore openapi frontmatter lines, filenames, JSX attributes, email
  addresses, and internal link targets via TokenIgnores
- Skip inline code scope and indented code fences
- Add Headings exceptions for proper nouns (Claude Code, GitHub
  Actions, Route 53, GA4, etc.)
- Disable linting for the all-code vercel-json-generator snippet

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: resolve all Vale warnings and errors across docs

Content fixes:
- Reword sentences using 'will', first person, spaced em dashes,
  'e.g.', Latin abbreviations, and hyphenated adverbs
- Sentence-case headings that started with dotted filenames
- Backtick literal API values instead of bolding them
- Move periods inside quotation marks
- Fix Oxford comma rule misfires by restructuring sentences

False-positive suppression:
- Vale toggles around example user questions, keyboard shortcut keys
  (Cmd+I), UI labels, and code samples in JSX contexts that Vale
  misparses
- Exclude vale toggle comments from the brace Token/BlockIgnores so
  in-document commands actually reach Vale (the greedy brace pattern
  was also silently swallowing large regions; now lazy)
- Vocab entries for code identifiers (internal_id, handleSubmit, etc.)
- Per-file rule disables for component docs with dotted JSX names and
  files where link-target linting ignores in-document toggles

Result: vale --minAlertLevel warning is clean repo-wide; only
suggestion-level items (Passive, Semicolons, Acronyms) remain.
mint broken-links passes.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: correct WordList rule instead of degrading prose

- Restore sentence-start "Email" in advanced-support; the rule now
  only flags hyphenated e-mail/E-mail forms
- Restore the idiom "above all else"; the above->preceding swap now
  exempts "above all"

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: restore deliberate prose flagged by blunt rules

- Restore spatial 'above the navbar' / 'above a page title' in
  custom-scripts; the above->preceding swap now exempts 'above
  the/a/an'
- Restore the '= ...' in the react-components named-export example
  (the ellipsis is inside inline code) with an Ellipses toggle
- Restore SLA phrasing 'will use commercially reasonable efforts'
  with a Will toggle
- Restore the quoted developer question in the GEO guide intro with a
  FirstPerson toggle, matching the file's other example questions

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: remove WordList swaps that flag legitimate English

- Drop tablet->device and firewalls->firewall rules; both words are
  correct in ordinary prose
- Narrow touch->tap to UI-instruction phrasing (touch the/a) so
  'keep in touch' and 'touch devices' stop flagging

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: reposition vale toggles to wrap whole blocks

Toggle comments placed between list items split the lists (restarting
ol numbering in deployments) and comments flush against tables risked
breaking GFM table parsing. Wrap entire lists/tables with blank-line
separation instead. Verified rendering with mint dev: single ol with
two items, tables intact, no comments in visible DOM.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor: prune accept.txt to load-bearing entries

Empirically removed 166 vocab entries (575 -> 409) whose removal
causes no Vale flags across all 908 English pages: dictionary words
that never needed listing (agents, setup, endpoints, webhooks, yaml),
lowercase entries the speller already accepts, and filename entries
made redundant by inline vale toggles.

Kept every case-enforcing entry (API, JSON, GitHub, ...) so casing
policy is unchanged, plus entries that double as capitalization
exceptions for headings (mcp, md, auth, cursor, txt).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Update ai/mintlify-mcp.mdx

* Update api/agent/v2/create-agent-job.mdx

* chore: alphabetize Headings exceptions and accept.txt

Case-insensitive sort, ignoring the (?i) prefix; also drops a
duplicate Scala entry.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: re-apply OxfordComma rewrite lost in branch merge

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs: resolve Vale suggestions batch 1 (acronyms, semicolons, passive voice)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs: resolve remaining Vale suggestions (passive voice batch 2)

Rewrite ~90 passive constructions to active voice across deploy,
guides, migration-services, and organize docs. Toggle the deliberate
passive examples in the style-and-tone guide ('by zombies' test).
Add axios/lodash vocab entries for a repositioned code example.

vale . is now fully clean: 0 errors, 0 warnings, 0 suggestions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 17:17:56 -07:00

256 lines
8.7 KiB
Plaintext

---
title: "GitHub Enterprise Server"
description: "Install and configure the Mintlify GitHub App on your GitHub Enterprise Server instance for automated documentation deployments and syncing."
keywords: ["GitHub Enterprise Server", "GHES", "GitHub Enterprise"]
---
This guide walks you through setting up the Mintlify GitHub App on your GitHub Enterprise Server (GHES) installation. To connect a GHES instance to Mintlify, you must create a local version of our app within your self-hosted environment that communicates with our remote server.
If you use a cloud-hosted GitHub instance, see the [GitHub](/deploy/github) page for setup instructions.
## Prerequisites
- Admin privileges on your GitHub Enterprise Server organization where you want to install the app
- Access to your organization's repositories where you want to install the app
- Network connectivity to communicate with our external services (see [Network requirements](#network-requirements) section below)
### Network requirements
#### Outbound connectivity
Your GitHub Enterprise Server must be able to reach:
- Mintlify's API endpoints (https://leaves.mintlify.com)
- Webhook receivers (port 443)
#### Firewall configuration
Allow the following outbound connections:
- Connections from Mintlify's static IP: `54.242.90.151`
- HTTPS (port 443) to Mintlify's service domains
- DNS resolution for Mintlify's service domains
## Step 1: Register the GitHub App
See [Registering a GitHub App](https://docs.github.com/en/enterprise-server@3.18/apps/creating-github-apps/registering-a-github-app/registering-a-github-app) in the GitHub documentation for detailed instructions.
<Steps>
<Step title="Navigate to your organization settings">
1. In the upper-right corner of any page on GitHub, click your profile picture.
2. Click **Your organizations**.
3. Click **Settings** next to the organization that you want to create the app for.
</Step>
<Step title="Create a new GitHub App">
1. In the left sidebar, click **Developer settings**.
2. Click **GitHub Apps**.
3. Click **New GitHub App**.
</Step>
<Step title="Configure basic app information">
Set the following:
- **GitHub App name:** `Mintlify`
- **Description:** `Integration with Mintlify services`
- **Homepage URL:** `https://mintlify.com`
- **User authorization callback URL:** `https://your-github-server.com/` (replace with your actual GHES domain)
</Step>
</Steps>
## Step 2: Configure app permissions
<Steps>
<Step title="Set repository permissions">
Set the following permissions for the app. The app needs no Organization, Account, or Enterprise permissions:
- **Checks:** Read and write
- **Contents:** Read and write
- **Deployments:** Read and write
- **Metadata:** Read-only
- **Pull Requests:** Read and write
</Step>
<Step title="Subscribe to events">
Select the following webhook events:
- Installation
- Installation Target
- Create
- Delete
- Public
- Pull Request
- Push
- Repository
</Step>
</Steps>
## Step 3: Generate and secure credentials
<Steps>
<Step title="Create the app">
Click **Create GitHub App**.
GitHub redirects you to the app's settings page.
</Step>
<Step title="Generate private key">
1. Scroll down to the **Private keys** section.
2. Click **Generate a private key**.
3. Download the `.pem` file and securely store it.
</Step>
<Step title="Note app credentials">
Record the following:
- **App ID** (visible at the top of the settings page)
- **Client ID** (in the "About" section)
- **Client Secret** (generate and record it securely)
</Step>
</Steps>
## Step 4: Install the app
<Steps>
<Step title="Navigate to app installation">
1. From the app settings page, click **Install App** in the left sidebar.
2. Select your organization from the list.
</Step>
<Step title="Choose installation scope">
Select either:
- **All repositories** (for organization-wide access)
- **Only select repositories** (choose specific repositories)
</Step>
<Step title="Complete the installation">
1. Click **Install**.
2. Record the installation ID from the URL. For example, in `https://your-github-server.com/settings/installations/12345`, the string `12345` is the installation ID.
</Step>
</Steps>
## Step 5: Configure webhook URL
<Steps>
<Step title="Return to app settings">
1. Go back to your app's settings page.
2. Scroll to the **Webhook** section.
</Step>
<Step title="Set webhook URL">
Configure the following:
- **Webhook URL:** `https://leaves.mintlify.com/github-enterprise/:subdomain` (replace `:subdomain` with the URL that we provide you with)
- **Webhook secret:** Generate a random string (32+ characters) and record it securely. Mintlify can also generate this and provide it to you.
</Step>
</Steps>
## Share credentials with us
Share the following information with our team using your secure information transfer method of choice.
### Required credentials
- GitHub Enterprise Server base URL: https://your-github-server.com
- App ID: (from step 3)
- App client ID: (from step 3)
- App client secret: (from step 3)
- Installation ID: (from step 4)
- Private key: The entire contents of the `.pem` file (share it via secure file transfer)
- Webhook secret: (from step 5)
### Optional credentials for troubleshooting
- Organization name: Your GitHub organization name
- Repository names: Specific repositories where you installed the app
- GitHub Enterprise Server version: Found in your site admin dashboard
## Mintlify connection
We take the credentials you provide us and store them, encrypted, in a secure location. Then we work with you to either:
- Integrate your GHES environment with an existing Mintlify deployment.
- Integrate your GHES environment with a new Mintlify deployment that we provision for you.
After you integrate your GHES environment with a Mintlify deployment, you are ready to enable webhooks for your GitHub App.
<Note>
The webhook URL may change based on our configuration. We test the integration and provide you with the new URL.
</Note>
## Test the integration
<Steps>
<Step title="Verify webhook delivery">
1. Go to your GitHub App settings.
2. Click the **Advanced** tab.
3. Check "Recent Deliveries" for successful webhook deliveries.
4. Look for HTTP 200 responses.
</Step>
<Step title="Test repository access">
1. Create a test issue or pull request in an installed repository.
2. Verify that Mintlify responds appropriately.
</Step>
</Steps>
## FAQ and troubleshooting
<AccordionGroup>
<Accordion title="The app installation is failing with permission errors.">
Ensure you have:
- Site admin privileges for app creation
- Organization owner or admin rights for app installation.
- Proper repository permissions if installing on specific repositories.
</Accordion>
<Accordion title="Webhooks aren't being delivered">
- Verify the webhook URL is correct and accessible.
- Ensure your firewall allows outbound HTTPS connections.
- Check the webhook secret matches what you configured.
- Review webhook delivery logs in the "Advanced" tab of your GitHub App settings.
</Accordion>
<Accordion title="I'm getting SSL/TLS certificate errors">
Your GHES might use self-signed certificates. Our services cannot verify your server's certificate.
**Solution:** Ensure your GHES has a valid SSL certificate.
</Accordion>
<Accordion title="The app installs, but doesn't respond to events.">
- Ensure our server receives and acknowledges webhooks with response code 200.
- You granted the required permissions during installation.
</Accordion>
<Accordion title="Can I limit which repositories the app accesses?">
Yes, during installation you can select "Only select repositories" and choose specific ones. You can modify this later in your organization's installed apps settings. This is the recommended form of installation.
</Accordion>
<Accordion title="How do I update app permissions later?">
- Go to the app settings as a site admin.
- Modify permissions as needed.
- The app needs to be re-approved by organization owners.
- Notify us of any permission changes so we can advise on any additional steps you may need.
</Accordion>
<Accordion title="Our GHES is behind a corporate firewall, nginx proxy, or similar setup.">
You must:
- Add our service domains to your firewall allowlist.
- Ensure outbound HTTPS (port 443) connectivity.
- If direct internet access is not allowed, set up a proxy.
</Accordion>
<Accordion title="Can this work with GHES in air-gapped environments?">
No, your GHES must be able to communicate with our cloud-hosted server.
</Accordion>
<Accordion title="Who should I contact if I need help?">
Reach out to your customer success representative at Mintlify, or contact our support team at <a href="mailto:support@mintlify.com">support@mintlify.com</a> with:
- Your GitHub Enterprise Server version.
- Specific error messages.
- Screenshots of any issues.
- Network/firewall configuration details (if relevant).
</Accordion>
</AccordionGroup>