Skip to main content

Overview

This guide walks through the full setup for integrating a GitLab instance with Devin, including both the admin setup and the end-user setup. Devin supports GitLab Self-Managed versions 15.0 and later. There are two parts to the integration:
  1. Admin setup
    • Connect the organization’s self-hosted GitLab instance to Devin
    • Set up a service account
    • Configure repository access
    • Register OAuth so users can link their personal GitLab identities
  2. User setup
    • Link an individual user’s GitLab account to their Devin account
The admin setup must be completed before any user can link their GitLab account. Only Enterprise Admins can perform the admin setup steps.

Part 1: Admin Setup

Step 1: Create a Service Account in GitLab

In GitLab:
  1. Go to the correct GitLab group
  2. Navigate to Settings
  3. Open Service Accounts
  4. Create a new service account
This service account is what Devin will use to access repositories in GitLab.
Create service account in GitLab

Step 2: Add the Service Account as a Group Member

Still in GitLab:
  1. Go to the group’s Members page
GitLab group members page
  1. Add the service account as a member of the group
  2. Grant it a role based on what Devin should do:
    • Developer is enough to connect Devin and read repositories
    • Maintainer where Devin should set up project webhooks automatically
    • Owner for group-level webhooks (group webhooks require GitLab Premium or Ultimate)
This is necessary so the service account can access repositories appropriately. Group membership covers all of the group’s projects.

Step 3: Generate a Personal Access Token for the Service Account

After creating the service account:
  1. Locate the newly created service account
  2. Click on the three dots > Manage access tokens > Generate a new personal access token > Select api under access scopes
  3. Copy and store that token securely
Ensure you are selecting the service account’s token, and not your personal access token found in your user’s preferences. You want Devin to act as the service account, not as you. You will use this token when adding the GitLab connection in Devin.

Step 4: Add the GitLab Connection in Devin

In Devin:
  1. Go to Enterprise Settings
  2. Open Connections
  3. Add a new connection
  4. Enter:
    • Your self-hosted GitLab URL (if applicable)
Add GitLab connection URL
  • The personal access token created for the service account
This creates the enterprise-level GitLab connection.

Step 5: Configure Webhook

Configuring a webhook allows Devin to automatically receive real-time notifications when specific events occur in GitLab (such as opening or updating merge requests and commenting on merge requests). To configure the webhook:
  1. In Devin, go to Settings > Connections > GitLab and click the GitLab connection you just added to open its details panel
  2. On the General tab, click Configure in the Webhook row
  3. Copy the webhook URL and Secret Token from the dialog
  4. Follow the dialog’s Group (recommended) or Project steps to add the webhook in GitLab, selecting the Comments, Merge request events, Push events, Issues events, and Pipeline events triggers
Adding a webhook in GitLab requires the Maintainer role on the project, or the Owner role on the group for group webhooks (Premium or Ultimate). When automatic webhook setup is available for your organization, the dialog notes that Devin sets up webhooks on every project and group the service account can administer; this only works where the service account has those roles (see Step 2). If you can’t grant the service account Maintainer or Owner, a GitLab user who has that access can add the webhook manually using the URL and secret token from the dialog.
Once configured, Devin will be able to respond to GitLab events in real time rather than relying on periodic polling.

Step 6: Verify Repository Access

After adding the connection:
  1. Confirm that the service account has access to the repositories you want to use
  2. In Devin, if repositories do not appear immediately, manually refresh the repository list
  3. Go to Enterprise Repositories
  4. Select the correct organization
Enterprise Repositories
  1. Open Manage Permissions
  2. Add the relevant repositories with the appropriate read/write permissions
Manage repository permissions
If repos are missing, it may be because Devin refreshes the repository list periodically rather than instantly.

Part 2: Enable User Linking for Self-Hosted GitLab

Step 7: Register an OAuth Application on the Self-Hosted GitLab Instance

To allow individual users to link their GitLab identity to Devin, the admin must register an OAuth app for the self-hosted GitLab instance. In Devin:
  1. Go to the enterprise GitLab connection area
  2. Open Advanced
  3. Go to the self-hosted GitLab section
  4. Start the flow to register an OAuth application
Register OAuth application

Step 8: Complete OAuth App Registration in GitLab

Follow the link in the registration modal to open the GitLab application form. Fill in the fields as shown:
  1. Set the Name and Redirect URI exactly as shown in the Devin modal
  2. Enable the Confidential checkbox
  3. Select the api scope
  4. Click Save application
GitLab OAuth app settings
  1. Copy the Application ID and Application Secret from GitLab
  2. Return to Devin and paste those values into the registration modal
  3. Click Register
This completes the admin-side setup needed for user identity linking.

Part 3: Organization Membership Requirement

Step 9: Make Sure the User Belongs to the Correct Devin Organization

Before a user can link their GitLab account, they must be a member of a Devin organization with GitLab repository permissions. In Devin:
  1. Go to the organization membership area
  2. Confirm the user is part of a Devin organization with GitLab repository permissions
  3. If they are not, add them first
Personal Connections only shows integrations for organizations the user belongs to. If a user is not in a Devin organization with GitLab repository permissions, the GitLab integration may not appear at all.

Part 4: End-User Setup

Step 10: Open Personal Connections

As the end user in Devin:
  1. Go to Personal Connections
  2. Look for the self-hosted GitLab integration
If it does not appear, check organization membership first.
Once the integration appears:
  1. Select the self-hosted GitLab connection
  2. Complete the linking flow
  3. Link the user’s GitLab account to their Devin account
After this, Devin should be able to act as that user for GitLab operations.

Security Considerations

  • Encrypted credentials — All tokens are encrypted and securely stored. This includes the service account’s personal access token, the OAuth application secret, and the OAuth tokens created when users link their GitLab accounts.
  • Encrypted in transit — All data transmission is encrypted in transit and at rest. Devin connects to your GitLab instance over HTTPS, and webhook deliveries are verified against the secret token generated when the webhook is configured.
  • Explicit authorization — Adding the connection alone grants no repository access. Repositories must be explicitly granted to a Devin organization with read/write permissions in Enterprise Repositories > Manage Permissions.
  • Scoped access — Devin acts through the service account, so its role in GitLab (Developer, Maintainer, or Owner) and that account’s project membership bound what Devin can reach.
  • Auditability — Using a dedicated service account makes it easier to attribute Devin’s activity in GitLab.
  • Branch protections respected — Devin’s merge requests are subject to the same branch protection rules and approval requirements as any other contributor.