Skip to main content
For an overview of how CodeRabbit integrates with Git platforms, see Add CodeRabbit to your repository.
Version RequirementsCodeRabbit supports GitLab 16.x and above. Version 15.x may experience unexpected issues such as review comments not being posted or the sign-up process not working at all. We recommend upgrading your GitLab instance to obtain the intended experience.

Getting started

To integrate your self-managed GitLab with CodeRabbit, we require specific information for the initial setup within your domain. Once this setup is complete, you can log in directly using the OAuth2 flow.
1

Visit CodeRabbit login page

Navigate to the CodeRabbit login page and select Self-Hosted GitLab.
2

Enter your GitLab instance URL

Enter the URL of your self-managed GitLab instance and click Continue. We’ll check our database for an existing record of your organization and start the login process if found.
Connect to Self-Managed GitLab page with the GitLab instance URL field

Connect to Self-Managed GitLab page with the GitLab instance URL field

If your self-managed GitLab instance is not found, we’ll initiate the onboarding process.
3

Choose onboarding method

You can choose between automated (recommended) or manual onboarding based on your security preferences and administrative access.

Onboarding options

Connect to Self-Managed GitLab page with the Automatic install option selected and the Admin Access token field

Automatic installation selected, with the Admin Access token field

Why do we need the Admin Access Token?The admin access token is required to set up a new CodeRabbit bot user within your self-managed instance. The token is needed only once during the initial setup process. Once generated, you can set its minimum expiration period. This is the standard approach used by other products in this category.This admin-token step configures the self-managed GitLab instance but does not select which projects or groups CodeRabbit can access. After onboarding, use Repository installation to install CodeRabbit on individual projects or across a group.

Manual onboarding

For the manual onboarding process, you need to create the CodeRabbit user and the OAuth2 GitLab application.
Install CodeRabbit form with the Manual option selected, showing the Access Token, Client ID, and Client secret fields

Manual installation selected, with fields for the CodeRabbit user access token and OAuth application credentials

Creating CodeRabbit user

This feature will work with any user from your organization, but we strongly recommend creating a dedicated user called CodeRabbitAI. This ensures clarity about which user is used for our application and allows for better fine-grained access control.
To interact with CodeRabbit in merge request comments, use @coderabbitai — or the username of the user you create here, if it differs.
1

Create the user

Log in with an instance admin account and follow the steps provided in the GitLab documentation to create a new user.
2

Retrieve user information

After the user is created, retrieve the User ID from that user’s profile.
3

Generate access token

Generate an access token for this user. The access token is used to post reviews on merge requests.
Recommendations for the CodeRabbit user:
  • Use “CodeRabbitAI” as the username for easy identification
  • Use the CodeRabbit logo as the profile picture for easy recognition
  • Ensure the user has appropriate permissions for the repositories you want to integrate
If you prefer, you can create a Group Access Token which will create a dedicated user on your behalf. For more information, see Group Access Token.

Creating OAuth2 application

For self-managed GitLab, we recommend creating an instance-wide application unless you want the reviews to be limited to a single group or user. Follow the steps outlined in the GitLab documentation for creating the application.
OAuth2 Application Requirements:
  • Scopes: api read_user email openid
  • Callback URL: https://app.coderabbit.ai/login

Generating personal access token

GitLab offers an option to generate a personal access token for adding a new user and setting up the application in the self-managed instance.
1

Login to your instance

Login to your self-hosted instance. For automated onboarding, ensure you have admin rights.
2

Access user settings

On the left sidebar, select your avatar, then select Edit profile.
3

Navigate to Access Tokens

On the left sidebar, select Access Tokens.
4

Create new token

Select Add new token.
5

Configure token settings

  • Enter a name and expiry date for the token
  • We need this for the initial setup, so the minimum expiry time is sufficient
  • If you do not enter an expiry date, it defaults to 365 days from the current date
  • Select the required scopes: api, read_api, read_user GitLab personal access token configuration page
6

Generate and save token

Select Create personal access token and note down the token as it will only be displayed once.
7

Enter the token in CodeRabbit

To provide the personal access token, open the CodeRabbit web application, open Account in the left sidebar, then under Provider settings, click GitLab User. Once you enter the token, CodeRabbit validates it and saves it for future use.

Submit the details

After you have the CodeRabbit user, access token and OAuth2 application, paste the details into the manual onboarding form and submit it. We will handle the setup process for you. On subsequent visits, your setup will be automatically detected, allowing for direct login. CodeRabbit authentication options page

Allow list CodeRabbit IP address

Use these CodeRabbit IP addresses if your instance requires IP allow listing.

Webhooks

CodeRabbit receives merge request, comment and issue events from your instance through webhooks. Install them manually, in bulk with a script, or update existing webhooks after changing the secret or destination.

Manual webhook installation

Use this flow when you need to install a webhook manually or configure an organization-specific secret. To rotate an existing instance-wide shared secret, use Workspace Git credentials. The Webhook Secret page is available in CodeRabbit for supported Git providers, including GitLab.com and self-managed GitLab.
1

Open Webhook Secret settings

In the CodeRabbit app, open Account and select Webhook Secret from the sidebar.
2

Copy the webhook URL

Use the Webhook URL field on that page to copy the exact endpoint that your GitLab instance should call.
3

Save or change the webhook secret

Enter the secret that GitLab should send with webhook deliveries and save it in CodeRabbit.
4

Configure the GitLab webhook

When creating or editing the webhook in GitLab, use the copied webhook URL and enable these settings:
  • Merge request events
  • Comments
  • Issues events
  • SSL verification enabled
If you change an organization-specific webhook secret, CodeRabbit attempts to update existing CodeRabbit-managed GitLab project and group webhooks automatically. If a webhook was created manually, or if an automatic refresh fails, update the secret directly in GitLab.

Bulk webhook installation

For administrators managing many GitLab projects, you can use a script to bulk-install webhooks across all projects. To update existing webhooks instead, use its migration mode. The script requires Bash 4 or later, jq 1.6 or later, and curl 7.55 or later.
1

Login to CodeRabbit UI

Login to CodeRabbit UI through your GitLab self-managed instance.
2

Copy the webhook URL and secret

Follow the Manual webhook installation steps above to get your webhook URL and save a webhook secret in CodeRabbit.
3

Run script to install webhooks

Use a script to install webhooks across your GitLab projects or groups. Below is a sample script that requires:
  • Your GitLab host URL
  • The webhook URL you copied in the previous step
  • The webhook secret you saved in the previous step
  • A GitLab access token with API permissions

Example: Install webhook on a single project

Example: Install webhooks on all projects in a group (including subgroups)

Rotate the instance-wide shared secret

A workspace administrator can rotate an existing shared secret from Workspace → Git credentials. Select the GitLab instance, choose Rotate webhook secret, and enter the new secret and an active GitLab instance administrator token with API access. The administrator token is used for this rotation and is not saved. CodeRabbit automatically refreshes all group and project hooks across the instance whose URL exactly matches the CodeRabbit webhook URL before saving the shared secret, regardless of how they were created. Only hooks whose URL differs from the CodeRabbit webhook URL require manual updates. If rotation reports a recovery failure, check the affected hooks before retrying. The Account → Webhook Secret page directs shared-secret rotations to Git credentials. Organization-specific secrets continue to use the Account page.

Migrate existing webhooks

Use the migrate command of gitlab-webhook.sh above to change existing project webhook URLs without deleting or recreating the hooks. Migration mode defaults to a dry run; the existing installation commands are unchanged. Before applying changes, configure the destination CodeRabbit instance, workspace, bot access and webhook secret. For reverse-tunnel deployments, validate the route and GitLab access first. This script does not create a bot, change OAuth credentials, configure a tunnel or write to the CodeRabbit database. Existing repository records are not repaired simply by changing a webhook URL.
GitLab clears the secret when a webhook URL changes unless the update also supplies a token. Provide the secret expected by the destination CodeRabbit configuration. Reuse the old secret only if the destination expects that same value. GitLab does not return the existing secret through its API.

Inputs

Set GITLAB_TOKEN to a GitLab API token with permission to manage the selected project hooks. Migration mode reads credentials from environment variables, not command-line arguments. Do not place secrets in either URL. Treat reports as internal operational data because they contain project IDs, URLs and event settings. For example, enter credentials using hidden prompts in Bash:
Preview one project first:
After checking the plan, repeat the command with --apply and a new report filename, such as pilot-results.jsonl. To migrate a group, replace --project team/service-a with --group team; add --include-subgroups only when needed. The script discovers the current state again on every run, checks for changes immediately before each update, and sends the new URL and secret in the same PUT request. The hook ID, event selections, filters and SSL verification setting are preserved. It does not create or delete hooks. If projects have different destination secrets, pass --secret-map project-secrets.json with a file like this, and export each named variable using hidden prompts:
The script lists all pages of projects and webhooks before changing anything. Ambiguous matches or missing secrets stop the entire apply phase before any updates. Check for overlapping group-level hooks separately before migration; this command only manages project hooks. Avoid concurrent webhook edits during the change window because GitLab does not provide a conditional-update guarantee.

Results and recovery

Each JSON line describes a plan or progress record. An illustrative successful update emits:
Actual records also include available event settings and filters. ALREADY_TARGET_AUTH_UNVERIFIED means no URL update was needed, not that the secret is correct. NO_MATCH leaves the project untouched; CONFLICT requires choosing the correct hook before retrying. Errors return a nonzero exit code. A failure during apply stops later updates, but earlier successful updates remain applied. UPDATE_OUTCOME_UNKNOWN means the request failed without confirming whether GitLab applied it. Inspect that hook before retrying; the script never automatically retries a write. VERIFY_FAILED means the update could not be confirmed by reading the hook back. Reports record the old URL and settings before the write, but never the token. Rollback requires updating the same hook with its old URL and a separately retained old secret; restoring only the URL is not sufficient. Automatic rollback is not performed. With --test, TEST_REQUESTED_DELIVERY_UNVERIFIED means GitLab accepted the test request. Check the hook’s Recent events for the actual response and CodeRabbit logs for authentication and processing. Then create or update a real pilot merge request and verify that the existing bot posts a review before continuing with the group. A successful HTTP response alone does not prove review completion.

Repository installation

After completing onboarding, install CodeRabbit on individual projects or across a GitLab group from the Repositories page in the CodeRabbit app. The permission model and steps are the same as for GitLab.com — see Repository installation for details. After a group installation, repositories later created in or added to that group and its subgroups are activated automatically when their first merge request or pull request is opened. See Automatic installation for new group repositories for the prerequisites and expected behavior. GitLab.com tier restrictions described there do not necessarily apply to self-managed GitLab; availability depends on your GitLab license and instance configuration.

SSH repository access

By default, CodeRabbit clones your GitLab projects over HTTPS. If HTTPS is not available or your organization prefers SSH for repository access, you can configure SSH clone credentials in the CodeRabbit web app.
GitLab linked-repository research cloning requires secure credential sealing and fails closed when that protection is unavailable. This requirement applies only to linked-repository clones. The primary merge-request repository clone path is unchanged. See Multi-Repo Analysis platform requirements.

Prerequisites

  • An SSH key pair generated without a passphrase. CodeRabbit cannot use passphrase-protected keys.
  • The public key must be registered on the GitLab account used by CodeRabbit under Edit profile → SSH Keys. GitLab will deny SSH access if the public key is not registered!
  • The GitLab server’s trusted SSH host-key record (known_hosts) is required. CodeRabbit rejects SSH setup without it. See the GitLab documentation on SSH keys.

Configure SSH clone credentials

1

Log in to CodeRabbit

Navigate to app.coderabbit.ai and log in with your self-managed GitLab account.
2

Open account settings

In the left navigation menu, click Account at the bottom.
3

Navigate to SSH Clone Credentials

In the left navigation of the Account page, under Developer settings, click SSH Clone Credentials.
4

Enter your SSH credentials

Fill in the fields as required for your setup:Provide the SSH Private Key and known_hosts record for every SSH setup. The SSH Public Key is recommended so CodeRabbit can verify the key pair.
To avoid common copy-paste problems, use pbcopy (macOS) or xclip (Linux) to copy each key file to your clipboard, then paste directly into the corresponding field.
5

Save your credentials

Click Save to apply the SSH clone credentials. CodeRabbit will attempt SSH cloning using these credentials for your self-managed GitLab repositories. If SSH credentials cannot be decrypted or are invalid, cloning falls back to HTTPS. A missing trusted host-key record, an invalid known_hosts record, or an unsupported GitLab hostname causes SSH cloning to fail closed instead of trusting the first connection. A missing or invalid known_hosts record never falls back to insecure host trust.CodeRabbit retains the configured GitLab host, SSH key, trusted host, and optional custom port for later fetches and cached-checkout reuse, so follow-up fetches use the same authentication as the initial clone.
After the initial setup, you can return to this page to update individual fields without re-entering all credentials.

Troubleshooting

The likely cause is a missing trusted host-key record. Add the GitLab server’s known_hosts record in the known_hosts field, then save the SSH clone credentials again.
Follow-up fetches reuse the configured SSH key, GitLab host, and optional custom port from the initial clone. Re-check the saved SSH clone credentials if the failure persists.
Set the SSH Port field to the custom SSH port used by your GitLab instance, then save the SSH clone credentials again.
For additional support, visit the support page.

What’s next

Platform overview

Overview of all Git platforms supported by CodeRabbit and how to get started.

Quickstart

Open your first merge request and see CodeRabbit post a review in minutes.

Agent for Slack on self-managed GitLab

Connect CodeRabbit Agent for Slack to this instance and choose the GitLab token that defines its repository access.