Enterprise edition - Chainloop Documentation

This documentation is for the proprietary Chainloop Enterprise. If you are looking for the Open Source Evidence Store documentation, please refer to the Chainloop Evidence Store guide

Introduction

The Chainloop platform has two top-level components: Chainloop Evidence Store and Chainloop Platform. Both components are deployed using one unified Helm Chart called chainloop-ee (Chainloop Enterprise Edition). Once deployed, for example in an AWS Kubernetes cluster, it could look like this:

Chainloop Enterprise Edition deployment architecture on a Kubernetes cluster

Retrieve Private OCI Registry credentials.

To pull the Helm Charts and container images you’ll need to authenticate with a private OCI registry managed. If you don’t have them yet, please contact the Chainloop team. Once you get the creds, you can give it a try by authenticating locally and pulling the latest version of both Helm Charts.

# Authenticate locally
$ docker login -u [username] -p [creds] chainloop.azurecr.io
# Chainloop Enterprise Edition Chart
$ helm fetch oci://chainloop.azurecr.io/chart/chainloop-ee
$ ls chainloop-*
  chainloop-ee-0.326.0.tgz

Configure credentials for deployment

You have two options to consume the provided Helm Charts and container images in your Kubernetes cluster:

Option 1: Pull images and Chart directly from Private Azure Registry

To pull the images, you’ll need to store these credentials as a K8s secret in the cluster where you will deploy the Helm Charts. Later, they will be referenced in the Helm charts as imagePullSecrets.

$ kubectl create secret docker-registry regcred-azure \
    --docker-server=https://chainloop.azurecr.io \
    --docker-username=[your-username] \
    --docker-password=[your credentials]

Option 2: Relocate Helm Chart and images to your own registry

Both charts are compatible with relocation processes performed by the Helm Relocation Plugin. This means that you can easily import the Helm Charts and Container images provided by the Chainloop team into your registry, even behind the firewall. This is a two-step process (wrap -> unwrap)

Pull all the container images and Helm chart and wrap them in an intermediate tarball.
If needed, transfer that tarball to your air-gap environment via an offline medium
Unwrap the tarball and push container images, update the Helm Chart with new image references, and push it to the target registry.

For example, to relocate from Azure to your own Harbor registry.

helm dt wrap oci://chainloop.azurecr.io/chart/chainloop-ee

# 🎉  Helm chart wrapped into "chainloop-ee-0.326.0.wrap.tgz"
# Now you can take the tarball to an air-gapped environment and unwrap it like this

helm dt unwrap chainloop-ee-0.326.0.wrap.tgz oci://my-repo.harbor.io --yes

#  Unwrapping Helm chart "chainloop-ee-0.326.0.wrap.tgz"
#    ✔  All images pushed successfully
#    ✔  Helm chart successfully pushed
#
# 🎉  Helm chart unwrapped successfully: You can use it now by running "helm install oci://my-repo.harbor.io/chainloop-platform --generate-name"

The relocated Helm Charts will be ready to be used, pointing to the images also relocated to the end registry.

Deploy and Configure in Kubernetes

Step 1 - Deploy Platform Chart

Please refer to the Chart README file that can be found in the chart tarball, which can be pulled like this.

# Pull the chart tarball
helm fetch oci://chainloop.azurecr.io/chart/chainloop-ee

# Print the README from the tarball
tar -xzOf chainloop-ee-*.tgz chainloop-ee/README.md

The README includes examples of how to deploy the chart in both development and production modes. Next steps:

Do an end-to-end run of our getting started guide to test the platform
Optionally, configure the platform to enhance it with additional features following the steps below

Step 2 (optional) - Setup SMTP configuration

To enable email notifications, you need to configure the SMTP settings in the Chainloop Platform backend Helm chart values.yaml file like this:

Platform Chart values.yaml

backend:
  smtp:
    host: smtp.example.com # SMTP server hostname
    port: 587 # SMTP server port
    user: the-user # SMTP server username
    password: REDACTED # SMTP server password
    from: "Chainloop Notifications <[email protected]>" # From email address

Without this configuration, the Chainloop platform will not be able to send email notifications for events such as weekly summaries, or org invitations.

Step 3 (optional) - Configure users auto-onboarding

This step allows automatically onboarding users to specific organizations and user groups. Follow this guide to configure Chainloop Platform for auto-provisioning.

Step 4 (optional) - Restrict organization creation

This step allows restricting organization creation to specific users. Follow this guide to configure Chainloop Platform for restricting organization creation.

Step 5 (optional) - Configure integrations

The platform backend can integrate with external providers to onboard repositories, run SCM checks, support keyless attestation, and power AI-assisted Q&A. Configure the provider(s) you use below.

Configure a GitHub App

Chainloop can onboard repositories and run SCM checks through a GitHub App, using App installation tokens instead of user OAuth. It also supports GitHub keyless attestation. See the GitHub permissions reference for the full cumulative permission set.

Create a GitHub App (GitHub → Settings → Developer settings → GitHub Apps → New). At a minimum it needs the Metadata: Read permission. For the full feature set also grant Contents (Read & Write), Pull requests (Read & Write), Issues (Write), Checks (Read & Write), Administration (Read) and Members (Read).
Set the Webhook URL to https://[your-backend-hostname]/github/events (the backend serves the receiver under /github/events), for example https://api.app.chainloop.dev/github/events. Set the Webhook secret to the same value you put in backend.githubApp.webhookSecret below, and subscribe to the events pull_request, issue_comment, pull_request_review and pull_request_review_comment.
Generate a private key (downloads a .pem) and note the App ID and the App slug (the slug in the App’s public URL).
Configure the chart:

Platform Chart values.yaml

backend:
  githubApp:
    appId: 123456
    privateKey: |
      -----BEGIN RSA PRIVATE KEY-----
      ...
      -----END RSA PRIVATE KEY-----
    appSlug: my-chainloop-app       # slug from the GitHub App's public URL
    baseUrl: https://github.com     # optional; set to your GHES host for GitHub Enterprise Server
    webhookSecret: ""               # shared secret to verify webhook payloads (enables webhook processing)

Repositories are then installed per organization from the Chainloop web UI (Repositories → Add Repositories → GitHub).

Configure GitLab

GitLab (gitlab.com or self-hosted) needs no chart configuration. Org admins register a GitLab connection at runtime with an access token from the Chainloop web UI — see Connect GitHub & GitLab. The backend trusts each connection’s OIDC issuer automatically, so GitLab keyless attestation works without a static machine-identity issuer or a redeploy. The only optional setting is the shared webhook secret, which the chart auto-generates and persists across upgrades. Set it explicitly only if you want to manage the value yourself:

Platform Chart values.yaml

backend:
  gitlab:
    webhookSecret: ""             # optional; auto-generated when left unset

Configure a Slack App

Chainloop can install a Slack App per organization to power AI-assisted Q&A (Chainloop Ask) from Slack. Create a Slack App at api.slack.com/apps.

Create a Slack App and note its Client ID, Client Secret and Signing Secret (Basic Information → App Credentials), those would be used for the chart.
Go to “App Manifest” in the Slack App settings and setup the manifest with the appropriate URLs (note the backend URL):

display_information:
  name: Chainloop
  description: Supply chain governance, answerable in Slack
  background_color: "#1A1A2E"
  long_description: Connect your Slack workspace directly to Chainloop with the new native Slack App integration. Once connected, you can pick specific channels for notifications, ask Chainloop directly from your workspace and more.
features:
  bot_user:
    display_name: Chainloop
    always_online: true
oauth_config:
  redirect_urls:
    - https://[your-backend-hostname]/slack/oauth/callback
  scopes:
    bot:
      - app_mentions:read
      - channels:history
      - channels:join
      - channels:read
      - chat:write
      - groups:history
      - groups:read
      - im:history
      - im:write
      - users:read
      - users:read.email
  pkce_enabled: false
settings:
  event_subscriptions:
    request_url: https://[your-backend-hostname]/slack/events
    bot_events:
      - app_mention
      - message.im
      - app_uninstalled
      - tokens_revoked
  interactivity:
    is_enabled: true
    request_url: https://[your-backend-hostname]/slack/interactivity
  org_deploy_enabled: false
  socket_mode_enabled: false
  token_rotation_enabled: true
  is_mcp_enabled: false

Configure the chart:

Platform Chart values.yaml

backend:
  slackApp:
    enabled: true
    clientId: ""
    clientSecret: ""
    signingSecret: ""

This Slack App (AI-powered Q&A) is separate from Slack incoming-webhook notifications. Those are set up at runtime in the Chainloop web UI under the organization and product notification settings, not in the chart.

Configure Linear

Chainloop integrates with Linear so that issues it creates are attributed to your own Linear app. Each organization installs it through OAuth.

Create a Linear OAuth application at linear.app/settings/api/applications/new.
Note its Client ID and Client Secret.
Configure the chart:

Platform Chart values.yaml

backend:
  linearApp:
    enabled: true
    clientId: ""
    clientSecret: ""

Step 6 (optional) - Test MCP server

The Chainloop Model Context Protocol (MCP) server is enabled by default. It is served by the backend under the /mcp path, so it is exposed through the existing backend domain. This means the MCP server is available at https://[your-backend-hostname]/mcp, for example https://api.app.chainloop.dev/mcp. Refer to the Chainloop MCP server guide to learn how to connect to it from your AI clients and agents.

Step 7 (optional) - Enable Managed CAS

Auto-provision a per-organization S3 Access Point for every org in your installation, backed by a single shared bucket. Removes the need for users to bring their own CAS backend. Follow this guide to provision the AWS prerequisites and enable the feature.

​Introduction

​Retrieve Private OCI Registry credentials.

​Configure credentials for deployment

​Option 1: Pull images and Chart directly from Private Azure Registry

​Option 2: Relocate Helm Chart and images to your own registry

​Deploy and Configure in Kubernetes

​Step 1 - Deploy Platform Chart

​Step 2 (optional) - Setup SMTP configuration

​Step 3 (optional) - Configure users auto-onboarding

​Step 4 (optional) - Restrict organization creation

​Step 5 (optional) - Configure integrations

​Configure a GitHub App

​Configure GitLab

​Configure a Slack App

​Configure Linear

​Step 6 (optional) - Test MCP server

​Step 7 (optional) - Enable Managed CAS

Introduction

Retrieve Private OCI Registry credentials.

Configure credentials for deployment

Option 1: Pull images and Chart directly from Private Azure Registry

Option 2: Relocate Helm Chart and images to your own registry

Deploy and Configure in Kubernetes

Step 1 - Deploy Platform Chart

Step 2 (optional) - Setup SMTP configuration

Step 3 (optional) - Configure users auto-onboarding

Step 4 (optional) - Restrict organization creation

Step 5 (optional) - Configure integrations

Configure a GitHub App

Configure GitLab

Configure a Slack App

Configure Linear

Step 6 (optional) - Test MCP server

Step 7 (optional) - Enable Managed CAS