Files
mintlify__docs/deploy/gitlab-self-hosted.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

108 lines
7.3 KiB
Plaintext

---
title: "Self-hosted GitLab OAuth"
description: "Connect a self-hosted GitLab instance to Mintlify via OAuth so automations can clone repositories, push commits, and open merge requests on your behalf."
keywords: ["GitLab", "self-hosted", "OAuth", "automations", "enterprise"]
---
Mintlify supports OAuth-based authorization for self-hosted GitLab instances, in addition to gitlab.com. OAuth lets the Mintlify agent act as a GitLab user during automation runs: cloning repositories, pushing commits, opening merge requests, and registering project webhooks.
You must configure OAuth authorization for self-hosted GitLab instances to support [automations](/automations).
Unlike gitlab.com, where Mintlify ships a single OAuth application that every customer authorizes against, each self-hosted instance must register its own OAuth application. Create the application on your GitLab instance, share its credentials with Mintlify, and then go through an OAuth authorization to connect a user.
<Note>
This guide is only for the **OAuth** integration that powers automations. You must configure the deployment-side connection (used for content sync and previews) separately with a deploy token, see the [GitLab guide](/deploy/gitlab). The OAuth integration depends on the deployment-side connection.
</Note>
## Prerequisites
- Admin access to your self-hosted GitLab instance.
- Your GitLab instance must be reachable from `https://app.mintlify.com`. Instances behind a VPN or behind a firewall that blocks public ingress do not work.
- A Mintlify organization that has the self-hosted GitLab feature enabled. Contact support if you don't see the **Self-hosted GitLab** section in your [Git settings](https://app.mintlify.com/settings/deployment/git-settings) dashboard page.
## Set up the connection
<Steps>
<Step title="Register an OAuth application on your GitLab instance">
In your self-hosted GitLab, sign in as an admin and navigate to **Admin Area** \> **Applications** \> **Add new application**.
Configure the application with these values:
- **Name**: `Mintlify`
- **Redirect URI**: `https://app.mintlify.com/api/gitlab-oauth/callback`
- **Trusted**: leave **unchecked**. Trusting the application skips the consent screen for every user; leaving it unchecked surfaces a normal authorization prompt the first time each user connects.
- **Confidential**: **checked**. Mintlify is a server-side client and keeps the secret confidential.
- **Scopes**: select `api`, `read_repository`, and `write_repository`. The agent uses these to read project metadata, clone repositories, and push commits.
Click **Save application**.
<Tip>
Editing an OAuth application on GitLab can rotate the client secret silently. If you make changes later, click **Renew secret** and update the new value in Mintlify.
</Tip>
</Step>
<Step title="Copy the application credentials">
After saving, GitLab displays the application's **Application ID** and **Secret**. Keep this page open—the secret is only shown once.
</Step>
<Step title="Register the instance in Mintlify">
In your Mintlify dashboard, open **Settings** \> **Git settings** and find the **Self-hosted GitLab** section under **GitLab OAuth**.
Click **Connect Self-Hosted GitLab** and enter:
- **GitLab instance URL**: the public URL of your GitLab instance, for example `https://gitlab.your-company.com`. Mintlify reaches your instance through this URL when exchanging tokens and calling the GitLab API.
- **OAuth application client ID**: the **Application ID** from the previous step.
- **OAuth application client secret**: the **Secret** from the previous step.
Click **Save instance**. Mintlify encrypts the secret at rest and never returns it to the browser after saving.
</Step>
<Step title="Authorize">
Click **Authorize self-hosted GitLab**. GitLab redirects you to your instance, prompts you to sign in if needed, and shows a consent screen listing the requested scopes.
After you click **Authorize** on GitLab, you'll be redirected back to Mintlify and the new connection appears in the installations list, badged with your instance hostname.
</Step>
<Step title="Choose projects">
Expand the connection in the dashboard. Mintlify lists every group your authorizing user has Maintainer or higher access to, plus a **Personal projects** entry for projects in the user's personal namespace.
Check the box next to each project that should participate in automations. Mintlify registers a webhook on the project, generates a secret token, and stores it encrypted. From then on, Mintlify receives push and merge-request events from your instance for that project.
<Note>
The connecting user must have **Maintainer** role on a project for Mintlify to mint short-lived project access tokens during automation runs. Without Maintainer, the agent can read but cannot push commits or open merge requests.
</Note>
</Step>
</Steps>
## Rotate credentials
If you need to change the registered application's client secret—for example after renewing it on GitLab—remove the saved instance in Mintlify and add it again with the new values. You must revoke active OAuth connections first. Otherwise, Mintlify blocks the removal.
<Steps>
<Step title="Revoke each connection">
Click **Revoke** on every installation listed under the self-hosted instance. This removes the webhook on every connected project and revokes the OAuth token on GitLab.
</Step>
<Step title="Remove the instance">
In the **Self-hosted GitLab** card, click **Remove instance**.
</Step>
<Step title="Re-add with new credentials">
Follow the **Set up the connection** steps described earlier with the new client secret.
</Step>
</Steps>
## Troubleshooting
### Authorization fails with `invalid_client`
GitLab rejected the token-exchange step because the client secret Mintlify sent doesn't match what's registered on the application. The most common cause is that a secret rotated on GitLab—by an explicit **Renew secret**, or silently when someone edited the application—and the value in Mintlify is stale.
Fix: rotate credentials following the [Rotate credentials](#rotate-credentials) steps with the current secret.
### Webhook registration failed: `Invalid url given`
GitLab refused to register the webhook because its outbound-request allowlist rejected the URL Mintlify sent (`https://app.mintlify.com/gitlab-oauth-webhook`). Self-hosted instances reject "local" URLs unless the admin explicitly allows them.
Fix: in your GitLab admin area, go to **Settings** \> **Network** \> **Outbound requests** and enable **Allow requests to the local network from webhooks and integrations**. If your network policy blocks `app.mintlify.com`, contact your network admin to allow outbound HTTPS to that host.
### No consent screen on authorize
If you don't see GitLab's consent dialog when authorizing, either:
- The application carries the **Trusted** flag on GitLab. Trusted applications skip consent for all users. Uncheck **Trusted** in the application settings if you want users to see and confirm scopes.
- Your GitLab user has previously authorized the application with the same scopes. GitLab remembers prior grants and skips consent on subsequent authorizes. Revoke the application authorization in **User settings** \> **Applications** \> **Authorized applications** to see consent again.