Socket for GitLab (Beta)
Run the Socket GitLab app in your own infrastructure to scan every project in a GitLab group and comment on merge requests.
Socket for GitLab is in beta. Behavior may change between releases.
Socket for GitLab is an app you run in your own infrastructure, as one Docker container and a PostgreSQL database. It connects to one GitLab group on GitLab.com or on a self-managed GitLab instance, scans every project in that group on each push, and comments on merge requests with dependency changes and alerts.
Get started
These pages take you from installation to daily use:
- Install Socket for GitLab with Docker and connect it to a GitLab group.
- Learn how merge request scanning works, including push scans and merge request comments.
- Require the Socket check before merging so merge requests with blocked alerts can't be merged.
- Decide what to do when you receive an alert.
- Set per-project options in socket.yml for GitLab.
- Review the permissions Socket for GitLab uses.
- Open the network paths in Socket for GitLab network and certificates, and fix problems with Troubleshoot Socket for GitLab.
Requirements
Line up the following before you install the app:
- A host that runs Linux containers, such as Docker. The
socketdev/gitlabimage is published for amd64 and arm64. - PostgreSQL 15 or newer with an empty database. The installation guide starts one in a container.
- A Socket organization used only by this app, and a Socket API token with every
full-scans,diff-scans, andreposcope. - A GitLab access token for the group. See Socket for GitLab permissions.
- GitLab 17.4 or newer, if you run self-managed GitLab. Older versions don't send a webhook header the app requires.
- A network path from GitLab to the app on TCP port 5050, and outbound HTTPS from the app to GitLab and api.socket.dev.
We recommend a dedicated Socket organization because the app reuses any existing Socket repository that has the same name as a GitLab project. In a shared organization, GitLab scans could land in a repository that another integration created.
Differences between GitLab.com and self-managed GitLab
How the app sets up webhooks and picks up new projects depends on where your GitLab runs:
| Your GitLab | Webhooks the app creates | Token for the app | Projects created after setup |
|---|---|---|---|
| Self-managed GitLab, any tier | One per project | Group access token, Maintainer | Scanned after the next app restart |
| GitLab.com Premium or Ultimate | One group webhook | Group access token, Owner | Added automatically |
| GitLab.com Free | One per project | Personal access token, Maintainer on each project | Scanned after the next app restart |
On self-managed GitLab, the GitLab API reports every group's plan as default, so the app creates one webhook per project even on Premium or Ultimate. On GitLab.com Premium or Ultimate, the group webhook also reports deleted projects, and the app deletes the matching Socket repository.
Related topics
- Socket for GitLab Pipeline: run Socket in GitLab CI with the Socket CLI instead of running the app.
- Socket for GitHub
- Socket for Origin
Updated about 5 hours ago