Skip to content
DocumentationKnowledge
Knowledge
Integrations
GitLab (self-hosted)

GitLab (self-hosted)

GitLab self-managed instances can connect to Altertable through an OAuth application. Because a self-hosted instance runs on your own domain, you register the OAuth application yourself and provide its credentials to Altertable.

The connection is set up in two stages: you create an OAuth application in GitLab, then go to Altertable with the application credentials finish configuring and authorizing.

Prerequisites

  • A self-hosted GitLab instance reachable from Altertable (for example https://gitlab.your-company.com).
  • Permission to create an OAuth application on that instance (user, group, or admin application depending on your setup).
  • Access to create connections in your Altertable environment.

1. Create the OAuth application on GitLab

Register an OAuth application on your GitLab instance so it can authorize Altertable.

  1. In GitLab, go to your group's SettingsApplications
  2. Choose Add new application.
  3. Set a Name, such as Altertable Knowledge.
  4. Set https://app.altertable.ai/gitlab-app/callback as a Redirect URI.
  5. Enable Confidential.
  6. Select the required Scopes:
    • read_api — read access to the GitLab API.
    • read_user — read the authenticating user's profile.
    • read_repository — read-only access to repository contents.
  7. Save the application.
  8. Copy the generated Application ID and Secret. The secret is shown only once.

2. Complete the connection on Altertable

Go to the Altertable connection screen to complete authorization.

  1. In Altertable, open SettingsIntegrations, find the GitLab row, then choose Connect GitLabSelf-hosted GitLab.
  2. Enter your Instance URL, then paste the Application ID and Secret from GitLab.
  3. Choose Connect to start the OAuth authorization flow.
  4. Approve the authorization request on your GitLab instance when prompted.
  5. Altertable confirms the connection once authorization succeeds.

Troubleshooting

  • 404 after clicking Connect: double-check the Instance URL for typos, and — unless a reverse proxy serves GitLab under a subpath — enter the plain origin (for example https://gitlab.example.com), not a full page URL such as https://gitlab.example.com/dashboard/projects.
  • Redirect URI mismatch: the URI registered in GitLab must match the one Altertable provides exactly, including scheme and trailing path.
  • Authorization fails: confirm the application scopes include read_api, read_user, and read_repository, and that the instance is reachable from Altertable.
  • Instance not reachable: verify the instance URL and that any firewall or network policy allows access from Altertable.