Skip to main content

System requirements

The self-hosted version of GitGuardian is a Kubernetes application.

Hardware requirements

For both installation types:
  • If you want to initiate the historical scan on large repositories, consider temporarily increasing available root disk space.
  • If you want to add additional workers, provision 1 CPU core per additional worker.

Embedded Kubernetes cluster installation

For more details, refer to the New GitGuardian Architecture page.

New GitGuardian application

ComponentRequired Capacity
CPU8 cores
Memory32GB
Root disk space300GB

Legacy GitGuardian application

ComponentRequired Capacity
CPU8 cores
Memory32GB
Root disk space100GB
Second disk space200GB

Existing Kubernetes cluster installation

Minimal configuration

This configuration is the minimum requirement you need to install and use GitGuardian. Depending on the size of the perimeter you want to monitor, you may need to adjust your environment.

ComponentRequired Capacity
CPU8 cores
Memory32 GB
Ephemeral disk space50GB
Persistent disk space200GB

This minimal configuration can be upgraded depending on the perimeter you want to monitor. Please read our Scaling GitGuardian section for more information.

Software requirements

Operating System

Please be careful to follow Replicated and kURL requirements.

note

We highly recommend that you install the latest patches available for your distribution before starting the installation.

PostgreSQL

GitGuardian currently supports PostgreSQL 13 to 16.

You'll need to install the following extensions to improve your text search performances:

ExtensionUsageMinimal Version
btree_ginProvides GIN capability to base datatypes (int, timestamp, ...) so all columns can be used in GIN indexes1.3
pg_trgmProvides functions and operators enabling fast searching for similar strings using GiST and GIN indexes1.5
plpgsqlAllows the creation of stored procedures and triggers using the procedural programming language PL/pgSQL1.0

Depending on your installation, extensions may already be installed. To install these extensions, you must run the following commands while connected as a superuser on the database instance:

CREATE EXTENSION IF NOT EXISTS btree_gin;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS plpgsql;

For more on databases, see Configure your database.

For large-scale deployment, we highly recommend using an external PostgreSQL. It is a better configuration when you have 2 000 developers and/or 10 000 repositories or more.

You should use the replication mechanism your provider offers. We recommend an instance with at least 2 vCPU, 8GB RAM and 200GB disk.

High Availability usage and databases

We recommend using external databases for GitGuardian as the embedded ones are not configured for High Availability and performance.

Redis

GitGuardian currently supports Redis 6 and 7.

note

GitGuardian will function with Redis 5, but we strongly advise using version 6 or 7 as our support of the former is deprecated.

For large-scale deployment, we highly recommend using an external Redis. It is a better configuration when you have 2 000 developers and/or 10 000 repositories or more.

We recommend an instance with at least 2 vCPU, 4GB RAM and 20GB disk.

For High Availability, we support Redis Sentinel for Existing cluster using KOTS only.

Kubernetes for Existing Clusters

For Existing Cluster installations, GitGuardian supports the following Kubernetes versions: 1.25 to 1.29 (we recommend upgrading to 1.29).

GitGuardian needs a dedicated namespace.

note

If you plan to install GitGuardian on an OpenShift cluster, please refer to the detailed guidelines for OpenShift cluster installation.

KOTS

The "Existing cluster with KOTS" installation method is using KOTS. We use the latest KOTS version available to validate our releases. You can find version compatibility on the KOTS compatibility page.

The KOTS Admin Console will have full control over this namespace. The following role needs to be created:

Name:         kotsadm-role
Labels: kots.io/kotsadm=true
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
*.* [] [] [*]

We are using the following objects:

  • PersistentVolumeClaims: we are using persistent volume claims for KOTS, workers and the embedded databases.
  • IngressController: we can provide a default ingress, an Ingress Controller is needed to handle it.

You need to have the appropriate controllers and operators to handle them.

Helm

The Existing Cluster with KOTS installation method requires Helm 3 and above.

Use a Helm version that aligns with your Kubernetes version to avoid compatibility issues. Refer to the Helm version support policy for the list of compatible versions.

Helm installation also supports some optional custom resources. If you wish to use them, you must have the appropriate controllers and operators:

  • IngressController: we provide an example of an ingress controller. You can also configure any other Ingress Controller class. Read our Ingress Configuration topic.
  • Istio: we support Istio for traffic routing and end-to-end encryption (sidecars).
  • Prometheus Operator: we can deploy ServiceMonitors to expose observability metrics on our application.
  • Vault: we allow the use of Vault through external-secrets SecretStore.
  • CertManager: we allow certificate management through cert-manager ClusterIssuer.

Domain Name requirements

You will need a Fully Qualified Domain Name (FQDN) to install the application (ex: gitguardian.mycorp.local). This cannot be an IP. You will also need a TLS certificate for HTTPS access or use the default self-signed certificates.

How can I help you ?