Integrations
An integration is the connection between KvantumCI and one of your development platforms. It is what lets KvantumCI read your repositories, branches, commits, pipeline definitions and cloud configuration so that verification runs have something to scan.
Everything KvantumCI reads through an integration is read-only. KvantumCI does not push commits, open pull requests, change pipeline definitions or modify cloud resources.
To access and operate KvantumCI itself in a programmatic or agentic way, see Access options.
Integration types
| Integration | What it connects to | Credential |
|---|---|---|
| GitHub | github.com and GitHub Enterprise Server | GitHub App or personal access token |
| GitLab | gitlab.com and self-managed GitLab | Access token |
| Bitbucket | Bitbucket Cloud workspaces | OAuth client, workspace access token or Atlassian API token |
| Azure DevOps | Azure DevOps organizations (Azure Repos) | Service principal or personal access token |
| Jenkins | A Jenkins controller | Username plus API token |
| AWS | An AWS account | Cross-account IAM role |
JFrog and Nexus appear in the platform as future integration types. They are not available yet, and connecting them is not supported.
Named Configuration
Every integration you create is a Named Configuration: a single saved connection with its own identifier and a name that you choose.
The name matters because you are not limited to one connection per platform. You can add several integrations of the same type, each with its own credential, base URL and name. Typical reasons to do that:
- A separate token per team, so that revoking one team's access does not stop everyone else's scans.
- Two GitLab instances, for example gitlab.com alongside a self-managed server.
- Different token lifetimes or rotation schedules for different sets of repositories.
When you add a repository to a project, you pick which Named Configuration it should be read through, so a descriptive name (for example "Platform team, read-only") saves a lot of guessing later.
Each provider page linked in the table above covers the credential it needs and the minimum permissions to grant.
Connecting an integration
Every integration follows the same shape: create a credential on the platform side, then add it in KvantumCI under Integrations in the left sidebar menu, give it a name, and let KvantumCI validate it before you save.
Step-by-step instructions with screenshots are in the getting started guide:
Validation and active state
KvantumCI validates a credential when you create an integration and can re-check it afterwards. Validation results fall into three groups:
- Valid. The credential works and the integration can be used.
- Rejected. The credential is wrong, has been revoked, or lacks the permissions KvantumCI needs. The integration will not become usable until you fix it.
- Temporary failure. The platform was rate limiting, timing out or returning a server error. This is retryable, and the result says nothing about whether your credential is correct.
An integration that is not usable is shown as inactive. While it is inactive, verification runs for every project item that depends on it fail to complete. Reactivation is automatic: save a new credential and KvantumCI revalidates it, switching the integration back on for you if it works. AWS is the exception, because there is no credential to replace; you fix the role in your own AWS account and switch the integration back on yourself. For the full list of causes, fixes and what happens to individual project items, see Inactive integrations and project items.
Related pages
- Projects covers how integrations are attached to project items and scanned.
- Workflow Scanning covers what KvantumCI reads from CI/CD pipeline definitions across GitHub, GitLab, Azure DevOps and Jenkins.