Features
Pull Request Generation Code Review Refinements Admin UI Project Scanners
Pricing Docs Blog
Contact Us

Documentation

Installation

Overview

Installing Snapr requires a Kubernetes environment and a few setup steps to connect it with your development workflow. Snapr is distributed as a Helm chart and runs fully inside your cluster, ensuring that your code and data never leave your infrastructure.

This guide explains the infrastructure prerequisites, Snapr configuration requirements, and how to deploy it.

Prerequisites

Before setting up your cluster or installing Snapr, make sure you have the following tools installed locally:

Snapr runs as a set of pods within your Kubernetes cluster, so make sure your cluster is up and running.

Snapr License

A valid Snapr license is required to deploy and operate the platform. The license validates your installation and unlocks access to Snapr’s core features. Contact us in order to get your license.

You’ll receive your license key from the Snapr team during onboarding or evaluation. If your license is missing or invalid, the installation will not complete successfully.

Once you have your license, you must provide it in your Helm configuration:

license:
  key: "<your-license-key>"

Public Access and DNS Configuration

Snapr provides a web-based interface and integrates with GitHub through webhooks and authentication callbacks. To make all these components work correctly, your Snapr instance must be accessible through a public HTTPS hostname.

This hostname will be used for:

  • Accessing the Snapr frontend (admin panel).
  • Receiving GitHub webhooks.
  • Handling OAuth and GitHub App callbacks.
Note: You’re responsible for providing a valid public domain that resolves to your cluster. This domain can point to your ingress controller via DNS, a load balancer, or a tunneling service (such as ngrok) for testing purposes.

The FQDN will be supplied later in the Helm values during deployment, as Snapr will use it to configure ingress rules, callback URLs, and webhook endpoints.

ingress:
  host: "<your-fqdn>"
  tls:
    - hosts:
      - "<your-fqdn>"
github:
  oauthCallbackURL: "https://<your-fqdn>/api/auth/callback"

When configuring the GitHub OAuth App, the Authorization Callback URL must point to your provided domain using the following path:

https://<your-fqdn>/api/auth/callback

This endpoint is required for Snapr to complete the OAuth authentication flow.

Github Integration

Oauth Authentication

Snapr uses OAuth authentication to allow users to securely log in to the admin panel using their GitHub accounts. This ensures that only authorized members of your organization can access Snapr’s configuration and activity data.

You’ll need to create a GitHub OAuth App in your organization or personal account before deployment. Once created, make sure to keep the following information handy, you’ll need it when configuring Snapr:

  • Client ID
  • Client Secret
  • Callback URL

You’ll provide these values later in your Snapr configuration:

auth:
  github:
    clientId: "<your-client-id>"
    clientSecret: "<your-client-secret>"
    callbackUrl: "https://<your-fqdn>/api/auth/callback"

Github App Setup

Snapr integrates with GitHub through a dedicated GitHub App that acts as the bridge between your repositories and Snapr’s automation engine. This app enables Snapr to receive repository events (such as issues, pull requests, and comments) and to perform actions securely on behalf of your organization.

Why a GitHub App?

Unlike a personal access token or OAuth app, a GitHub App provides fine-grained permissions, improved security, and better auditability. Each installation of the Snapr App is tied to a specific organization or user account, giving you full control over which repositories Snapr can access.

GitHub App installation

Snapr requires a GitHub App to be created and installed in order to interact with your repositories.

Follow the steps in Github documentation about creating Github Apps. This Github App requires the following Repository permissions granted:

  • Checks: Read and write.
  • Contents: Read and write.
  • Issues: Read and write.
  • Pull requests: Read and write.
  • Workflows: Read and write.

These permissions allow Snapr to perform actions such as creating and updating Issues, opening Pull Requests, posting comments, and participating in discussions as part of your development workflow. All interactions are performed strictly through the permissions granted to the GitHub App.

Once the GitHub App is created and installed, its credentials (App ID and Private Key) must be configured in Snapr during installation. These credentials allow Snapr to authenticate securely and generate short-lived installation tokens for each repository it works with.

GitHub App identity configuration

Snapr must be configured with the GitHub App name and the associated bot user ID. These values are required to correctly identify Snapr when interacting with GitHub Issues and Pull Requests, and to determine whether a given GitHub event was generated by Snapr itself or by another actor.

You can retrieve the bot user ID by visiting: https://api.github.com/users/<your-github-app-name>[bot]

Look for the id field in the response.

GitHub Webhook Configuration

To allow Snapr to react to activity in your repositories, GitHub must be configured to send webhook events to Snapr. These webhooks notify Snapr when relevant events occur, such as Issue updates, Pull Request activity, or comments.

You can configure the webhook at the organization level or at the repository level, depending on how broadly you want Snapr to operate. More information about type of webhooks here.

Webhook URL and payload format

When configuring the GitHub webhook, make sure to use the fully qualified domain name (FQDN) of your Snapr API and select the correct payload format.

  • Payload URL: https://<your-fqdn>/api/github
  • Content type: application/json
Select individual events

For security and clarity, Snapr should only receive the events it needs to operate. When configuring the webhook, select only the following events:

OpenAI API KEY

Snapr requires an OpenAI API key to perform AI-powered tasks such as analysis, code review, issue refinement, and Pull Request generation.

The API key is used by Snapr to communicate with the configured AI provider and must be supplied as part of the installation.

How the API key is used

  • The key is consumed only by Snapr services running inside your infrastructure
  • It is used to execute AI workflows triggered by events or comments
  • No prompts, code, or project data are sent outside your environment other than what is required to fulfill the request

Security note

The API key is never exposed to users, logged, or embedded in configuration files. It remains confined to Snapr’s execution environment and can be rotated at any time by update snapr-credentials ConfigMap in the snapr namespace.

OpenAi API KEY will be used in the Helm values file during Snapr installation:

agent:
  openai:
    apiKey: "<your-openai-api-key>"
Support for additional providers will be added in the future, but currently all AI-powered tasks in Snapr require a valid OpenAI API key.

Deploy Snapr App in your cluster

Once every requirement to run Snapr is in place, including your Kubernetes cluster, license key, public FQDN, GitHub OAuth App, and GitHub App, you can deploy Snapr using Helm.

This section walks you through preparing your Helm values file and installing the Snapr chart into your cluster.

Prepare Your values.yaml

Create a file named values.yaml and include all required configuration fields. Below is a minimal but complete example using the information gathered in previous sections:

license:
  key: "<your-license-key>"

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  host: "<your-fqdn>"
  tls:
  - secretName: tls-secret
    hosts:
      - "<your-fqdn>"

agent:
  openai:
    apiKey: "<your-openai-api-key>"

github:
  app:
    id: "<your-github-app-id>"
    privateKey: |
      -----BEGIN RSA PRIVATE KEY-----
      <your-private-key>
      -----END RSA PRIVATE KEY-----
    webhookSecret: "<your-github-app-webhook-secret>"
    name: "your-github-app-name"
    botId: "your-github-app-bot-id"
  oauthCallbackURL: "https://<your-fqdn>/api/auth/callback"
  oauthClientId: "<your-oauth-client-id>"
  oauthClientSecret: "<your-oauth-client-secret>"

Install Snapr

Deploy Snapr using your values.yaml:

helm install my-snapr oci://ghcr.io/snaprai/snapr --version 0.1.0

Helm will deploy all Snapr components into your cluster, create the required Kubernetes resources, and inject the configuration values your Snapr API will use (including GitHub integration settings, ingress parameters, and your license key).

Verify the Deployment

You can check Snapr’s pods:

kubectl get all -nsnapr

All pods should eventually reach the Running state, and all services should be created and available before you proceed.

NAME                                  READY   STATUS    RESTARTS   AGE
pod/snapr-api-5df6c89d58-5gnnt        1/1     Running   0          44m
pod/snapr-frontend-5f56cdcc54-skg4k   1/1     Running   0          55m

NAME                     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/snapr-api        ClusterIP   10.100.7.182   <none>        8080/TCP   55m
service/snapr-frontend   ClusterIP   10.100.97.1    <none>        80/TCP     55m

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/snapr-api        1/1     1            1           55m
deployment.apps/snapr-frontend   1/1     1            1           55m

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/snapr-api-5df6c89d58        1         1         1       55m
replicaset.apps/snapr-frontend-5f56cdcc54   1         1         1       55m

Access Snapr

After DNS propagation, open your configured domain:

https://<your-fqdn>

You will be redirected to GitHub to authenticate via your OAuth App.