Skip to main content

Source Control Integrations

Source control integrations enable code repository management, version control, and collaboration.

The following source control integrations are available:

Azure DevOps

Use the Azure DevOps integration to read Azure DevOps work items linked from your changes.

To configure the integration:

  1. In Azure, create a service account and a personal access token with only the Work Items (Read) scope.

  2. Grant project access so Biggy can see what the service account can see. 

  3. In the web app, populate the following fields:

    Field

    Description

    Instance Name

    Display name of the Azure DevOps instance.

    Organization URL

    Azure organization URL. (Example, https://dev.azure.com/your-organization.)

    Personal Access Token

    Personal access token generated in step 1.

  4. Click Verify Connection to confirm that the connection to Azure DevOps is established.

  5. Click Create Instance.

Bitbucket

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Use the Bitbucket integration to investigate recent code changes, pull requests, commits, diffs, and CI. Biggy connects to the Bitbucket Cloud or Bitbucket Data Center REST API, and the agent behaves the same on both products.

Configure the Bitbucket integration

Multi-integration configuration

You can configure multiple instances of Bitbucket.

To add an additional integration, click + New instance on the integration configuration page.

To configure the integration:

  1. In Bitbucket, create a read-only access token. Instructions differ depending on whether your organization has a Bitbucket Cloud or Bitbucket Data Center deployment:

    1. Bitbucket Cloud:  Go to Workspace settings > Access tokens. Create a token with repository and pullrequest read scopes; add pipeline read if you want pipeline results. Optionally enter the workspace slug so Biggy can resolve bare repository names and search code without asking which workspace.

    2. Bitbucket Data Center: Go to Manage account > HTTP access tokens. Create a token with Read permission and enter the server base URL including any context path. (For example, https://bitbucket.company.com.)

  2. In the web app Bitbucket integration page, configure the following fields:

    Field

    Description

    Instance Name

    A name that identifies this Bitbucket instance across Biggy. For example, Production Bitbucket.

    Routing Instructions (Optional)

    Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and becomes required once a second instance exists.

    Workspace/Project Nuances (Optional)

    List any Bitbucket nuances that help investigations. 

    We highly recommend configuring this field, as it lets you enter organization-specific information that helps Biggy provide more accurate and consistent results. 

    For example, you can enter key workspaces, projects, and repositories to prioritize, repository naming conventions, default branches, CI setup (Pipelines, Bamboo, Jenkins), monorepo layout notes, where deployments happen, and any investigation playbooks Biggy should follow.

    Deployment Type

    Select where the Bitbucket instance is hosted: 

    Bitbucket Cloud: Atlassian-hosted at bitbucket.org. Uses a workspace, project, or repository access token. 

    Bitbucket Data Center: Self-hosted Data Center or Server on your own URL. Uses an HTTP access token.

    Default Workspace (Optional)

    Available when Deployment Type is Bitbucket Cloud. 

    The workspace slug Biggy uses to resolve bare repository names and to run code search. Questions can still name any workspace explicitly.

    Bitbucket Data Center URL

    Available when Deployment Type is Bitbucket Data Center. 

    The server base URL, including any context path. For example, https://bitbucket.company.com.

    Access Token

    Enter your Bitbucket access token.

     For Bitbucket Cloud, use a workspace, project, or repository access token with repository and pullrequest read scopes.

     For Bitbucket Data Center, use an HTTP access token (personal, project, or repository) with Read permission.

    Custom Headers (Optional)

    Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

    These are commonly needed for Data Center behind a reverse proxy or single sign-on (SSO) gateway.

    On-premises instance

    Enable this toggle when the Bitbucket instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page. Bitbucket Cloud needs no relay.

  3. In the Connectivity section, click Verify Connection to test the credentials before you save.

  4. Click Create Instance.

GitHub

Use the Biggy GitHub integration to add code context or investigate recent code changes, pull requests, commits, and diffs.

Required Permissions

In GitHub, ensure the following personal access token (PAT) repository permissions are enabled:

  • Metadata 

  • Commit statuses 

  • Contents 

  • Issues 

  • Pull requests 

  • Checks 

Configure the GitHub Integration

To configure the integration, populate the following fields:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • Token (PAT) - Authenticate using a GitHub token (classic PAT or fine-grained PAT)

  • OAuth Access Token - Authenticate using a secure OAuth access token

  • GitHub App (Installation token) - Server-to-server auth via GitHub App JWT + installation access tokens

GitHub API Base URL

Enter the base URL of your GitHub instance. (for example, https://api.github.com)

Credentials

If you selected Token (PAT) as your authentication method, enter your Access Token.

If you selected OAuth Access Token as your authentication method, enter your OAuth Access Token.

If you selected GitHub App (Installation token) as your authentication method, enter your GitHub App ID, GitHub App Installation ID, and GitHub App Private Key (PEM).

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Deployment Type

Select whether your GitHub integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

GitHub System/Schema Nuances

List any special repo nuances, naming conventions, or other knowledge that helps Biggy more effectively interact with your tool.

We highly recommend configuring this field, as it lets you enter organization-specific information that helps Biggy provide more accurate and consistent results.

For example, you can enter key repos to prioritize, repo naming conventions, default branches, CI nuances, monorepo layout notes, deployment information, and any investigation playbooks that Biggy should follow.

GitLab

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested, but can be enabled by any customer. Core connectivity is stable, but the integration may receive updates based on user feedback.

Use the GitLab integration to investigate recent code changes, merge requests, commits, diffs, and CI/CD pipelines.

Required permissions

Ensure the following GitLab scopes/permissions have been enabled for Biggy to have the required system access to perform its functions:

Access Token Scopes

read_api read_repository

OAuth Application Scopes

read_api read_repository

Multi-integration configuration

You can configure multiple instances of GitLab.

To add an additional integration, click + Add Instance on the integration configuration page.

To configure the integration, populate the following fields:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • PAT / GAT: Authenticate using a GitLab Personal, Project, or Group access token.

  • OAuth Token (Static): Authenticate using a single OAuth access token. Note: GitLab OAuth access tokens expire after 2 hours; use OAuth (refresh) for long-lived sessions.

  • OAuth (refresh-capable): Authenticate via a GitLab OAuth application using clientId + clientSecret + refreshToken. Access tokens auto-refresh. Rotated refresh tokens are persisted automatically.

GitHub Base URL

Enter the GitLab Base URL (For example, GitLab.com: https://gitlab.com; Self-Managed: https://gitlab.yourcompany.com)

Credentials

If you selected PAT / GAT as your authentication method, enter your Access Token.

If you selected OAuth Token (Static) as your authentication method, enter your OAuth Access Token.

If you selected OAuth (refresh-capable) as your authentication method, enter your OAuth Application ID, OAuth Application Secret, and Initial Refresh Token.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Configuration Options

Select whether your GitLab integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Routing Instructions

Routing Instructions are only required if you are configuring multiple instances of GitLab.

Enter instructions for when this specific GitLab instance should be used.

GitLab System/Schema Nuances

List any special repo nuances, naming conventions, or other knowledge that helps Biggy more effectively interact with your tool.

We highly recommend configuring this field, as it lets you enter organization-specific information that helps Biggy provide more accurate and consistent results.

For example, you can enter key repos to prioritize, repo naming conventions, default branches, CI nuances, monorepo layout notes, deployment information, and any investigation playbooks that Biggy should follow.

Harness

Use the Biggy Harness integration to add delivery context or investigate pipelines, deployments, GitOps configurations, feature flags, and delivery governance. 

Biggy connects to a running Harness Model Context Protocol (MCP) server over Streamable HTTP, then loads the tools that the server exposes. Read-only tools are pre-selected, and write and execute tools are gated behind approval.

Required permissions

The Harness integration relies on a Harness token that you provide to the MCP server. Create a personal or service account token with read access to the pipelines, services, environments, and other resources you want Biggy to see.

When you load the server tools, Biggy pre-selects the read-only tools. Allow write and execute tools only if Biggy should be able to run them. Biggy gates every write and execute call behind approval.

Run the Harness MCP server

Biggy connects to a Harness MCP server that you host. Before you configure the integration in BigPanda, prepare the server:

  1.  Run the Harness MCP server in HTTP mode: Start the server with harness-mcp-v2 http, or run the equivalent container image, somewhere Biggy or a relay client can reach it. Local stdio and npx launches are not supported.

  2.  Note the Streamable HTTP URL: This is the URL Biggy connects to. It usually ends in /mcp, for example, https://harness-mcp.company.com/mcp.

  3.  Note the server-side transport token: If the server requires a transport token, note its value. If the server sets HARNESS_MCP_AUTH_TOKEN, you enter that value as the MCP transport token.

Local launches are not supported

Biggy connects to the Harness MCP server over streamable HTTP, so the server must be reachable by Biggy or by a relay client. stdio and npx launch methods will not connect.

Configure the Harness integration

To configure the integration, go to the web app Harness integration page and populate the following fields:

Field

Description

Instance Name

A name that identifies this Harness instance across Biggy. For example, Production Harness.

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and required for multiple instances.

Agent notes (Optional)

List any organization-specific knowledge that helps Biggy interact with Harness more effectively. We highly recommend configuring this field. For example, you can enter which organizations and projects matter, naming conventions for pipelines and services, which environments count as production, and any investigation playbooks Biggy should follow.

Harness MCP Server URL

The Streamable HTTP URL of your running Harness MCP server. It usually ends in /mcp. For example, https://harness-mcp.company.com/mcp.

MCP Transport Token (Optional)

The token Biggy uses to authenticate to the MCP server itself, if the server requires one. It is sent as Authorization: Bearer to the MCP server and is independent of the Harness token. If the server sets HARNESS_MCP_AUTH_TOKEN, enter that value here.

Harness token

A personal or service account token with read access to the pipelines, services, environments, and other resources Biggy should see.

Custom Headers (Optional)

Add custom HTTP headers to include with requests to the MCP server. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

On-premises instance

Enable this toggle when the Harness instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the credentials before you save.

Allowed tools and approvals

After configuring the integration fields, save the connection. Biggy loads the tools the server exposes, pre-selects the read-only ones, and gates writes and executions behind approval.

At least one tool is required

You cannot enable the Harness instance until at least one tool is allowed.

When you finish configuring the fields and allowing tools, click Create Instance to save the integration.

In this section: