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:- 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
- 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:- Go to the correct GitLab group
- Navigate to Settings
- Open Service Accounts
- Create a new service account

Step 2: Add the Service Account as a Group Member
Still in GitLab:- Go to the group’s Members page

- Add the service account as a member of the group
- 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)
Step 3: Generate a Personal Access Token for the Service Account
After creating the service account:- Locate the newly created service account
- Click on the three dots > Manage access tokens > Generate a new personal access token > Select api under access scopes
- 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:- Go to Enterprise Settings
- Open Connections
- Add a new connection
- Enter:
- Your self-hosted GitLab URL (if applicable)

- The personal access token created for the service account
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:- In Devin, go to Settings > Connections > GitLab and click the GitLab connection you just added to open its details panel
- On the General tab, click Configure in the Webhook row
- Copy the webhook URL and Secret Token from the dialog
- 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.
Step 6: Verify Repository Access
After adding the connection:- Confirm that the service account has access to the repositories you want to use
- In Devin, if repositories do not appear immediately, manually refresh the repository list
- Go to Enterprise Repositories
- Select the correct organization

- Open Manage Permissions
- Add the relevant repositories with the appropriate read/write 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:- Go to the enterprise GitLab connection area
- Open Advanced
- Go to the self-hosted GitLab section
- Start the flow to register an 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:- Set the Name and Redirect URI exactly as shown in the Devin modal
- Enable the Confidential checkbox
- Select the api scope
- Click Save application

- Copy the Application ID and Application Secret from GitLab
- Return to Devin and paste those values into the registration modal
- Click Register
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:- Go to the organization membership area
- Confirm the user is part of a Devin organization with GitLab repository permissions
- 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:- Go to Personal Connections
- Look for the self-hosted GitLab integration
Step 11: Link the User’s GitLab Account
Once the integration appears:- Select the self-hosted GitLab connection
- Complete the linking flow
- Link the user’s GitLab account to their Devin account
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.

