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.Visit CodeRabbit login page
Enter your GitLab instance URL

Connect to Self-Managed GitLab page with the GitLab instance URL field
Choose onboarding method
automated (recommended) or manual onboarding based on your security preferences and administrative access.Onboarding options
Automated onboarding (recommended)

Automatic installation selected, with the Admin Access token field
Manual onboarding
For the manual onboarding process, you need to create the CodeRabbit user and the OAuth2 GitLab application.
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.@coderabbitai — or the username of the user you create here, if it differs.Create the user
Retrieve user information
Generate access token
- 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
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.- 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.Login to your instance
Access user settings
Navigate to Access Tokens
Create new token
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
Generate and save token
Enter the token in CodeRabbit
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.
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.Open Webhook Secret settings
Copy the webhook URL
Save or change the webhook secret
Configure the GitLab webhook
- Merge request events
- Comments
- Issues events
- SSL verification enabled
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.
Login to CodeRabbit UI
Copy the webhook URL and secret
Run script to install webhooks
- 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
gitlab-webhook.sh script
gitlab-webhook.sh script
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 themigrate command of gitlab-webhook.sh above to move existing webhooks to a new URL. Project mode updates project hooks in place. Group mode updates an existing matching group hook, verifies its URL and visible settings, then removes matching project hooks within the selected scope. Groups without a matching group hook are left unchanged. Migration never creates a group hook and defaults to a dry run. It requires Python 3 in addition to Bash, jq and curl; 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.
Inputs
GITLAB_TOKEN to a GitLab API token with permission to manage the selected hooks. Group hooks require GitLab Premium or Ultimate and the group Owner role or instance administrator access. 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 or group IDs, URLs and event settings.
For example, enter credentials using hidden prompts in Bash:
--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 to include nested projects in cleanup. The script first updates and verifies the selected groups’ existing matching hooks, then deletes project hooks whose URLs exactly match --from-url or --to-url. Other integrations are untouched. Confirm that the group hook’s event selections and filters provide the coverage you need before applying. The group hook’s ID, event selections, filters and SSL verification setting are preserved. Project mode preserves project hooks in place.
For a batch, pass --project ./projects.csv or --group ./groups.csv. Prefix local filenames with ./, ../, / or @ (for example, @projects.csv) to distinguish them from GitLab paths ending in .csv. Use a UTF-8 CSV with one value per row and no header; the flag selects the input type. Every row with a value is treated as an input, including the first row. Names must be full namespace paths, such as team/service-a, rather than display names. You can mix IDs, paths and URLs from the configured GitLab host. Blank rows and surrounding whitespace are ignored; quoted fields, Windows line endings and a UTF-8 byte order mark are supported.
For example, projects.csv can contain:
groups.csv can contain:
--group ./groups.csv; --include-subgroups applies to every listed group’s projects. Duplicate groups and overlapping projects are processed once. The script validates the entire input file and discovers every selected group and project before planning updates. An invalid file or unreadable scope stops the run before any webhook changes. A group with no projects can still have its own hooks migrated.
A group hook must match either the old or destination URL to qualify. If none matches, that group and projects not covered by another selected matching group are skipped. A group already at the destination has its supplied secret refreshed and its visible settings verified before cleanup. Group mode needs the group secret, not the secrets of project hooks being removed.
If hooks have different destination secrets, pass --secret-map webhook-secrets.json with a file like this, and export each named variable using hidden prompts. Group keys use group:ID to distinguish them from project IDs:
Results and recovery
Each JSON line describes a plan or progress record. An illustrative successful update emits:group_id instead of project_id. Actual records also include available event settings and filters. In project mode, ALREADY_TARGET_AUTH_UNVERIFIED means no URL update was needed, not that the secret is correct. NO_MATCH leaves the project’s hooks untouched; CONFLICT requires choosing the correct group or project hook before retrying. SKIPPED_NO_GROUP_WEBHOOK marks a group without a matching hook; SKIPPED_GROUP_NOT_READY marks a project without a qualifying selected group. Errors return a nonzero exit code. A failure during apply stops later writes, but earlier successful writes remain applied.
Group cleanup reports WOULD_REMOVE, REMOVING, then REMOVED after confirming the project hook is absent. REMOVE_OUTCOME_UNKNOWN requires inspecting the hook before retrying. REMOVE_VERIFY_FAILED means removal could not be confirmed; CLEANUP_INCOMPLETE means another matching project hook remains. Cleanup never removes unplanned hooks.
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.
Deleted project hooks must be recreated manually using their recorded settings and separately retained secrets. Recreated hooks receive new IDs. A verified URL and visible settings do not prove destination authentication or successful CodeRabbit delivery.
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 an SSH clone credential in the CodeRabbit web app.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 an SSH clone credential
Log in to CodeRabbit
Open account settings
Navigate to SSH Clone Credentials
Enter your SSH credentials
pbcopy (macOS) or xclip (Linux) to copy each key file to your clipboard, then paste directly into the corresponding field.Save your credentials
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.known_hosts record and other server-verification data without re-entering the private key. Entering a new SSH Private Key replaces the stored key.Troubleshooting
SSH cloning fails at setup
SSH cloning fails at setup
known_hosts record in the known_hosts field, then save the SSH clone credential again. If the credential already exists, an organization admin can add or correct the known_hosts record and save without re-entering the SSH Private Key; leaving the field blank retains the stored encrypted key.SSH clone succeeds but a later fetch fails
SSH clone succeeds but a later fetch fails
SSH does not connect on a non-default port
SSH does not connect on a non-default port