GitGuardian Architecture

The GitGuardian application is built on a flexible cloud-native architecture. It leverages Helm charts for streamlined deployment, offering two primary methods: the KOTS admin interface (KOTS-based deployment) or the Helm CLI (Helm-based deployment).

Key Features of GitGuardian Architecture

Explore the enhanced capabilities of the GitGuardian architecture below:

Scalable and Modular Architecture

GitGuardian employs a modular architecture, where each core component is deployed as an independent service. This design enhances scalability and allows for greater flexibility:

• Replica Scaling: Adjust the number of replicas for each service to meet demand.
• Resource Configurations: Fine-tune resource requests and limits. These settings can be configured via Helm during installation or within the KOTS UI with some restrictions.
• Dedicated Workers: Create dedicated worker pods to handle high-demand queues (available in Helm-based deployments).
• Autoscaling: Leverage Horizontal Pod Autoscaling to automatically adjust worker pod counts based on load.

There are currently two deployment architecture available for exposing APIs.

• Ingress agnostic (fall-back architecture)
• Ingress aware (recommended architecture)

Architecture Recommendation

We strongly recommend using the Ingress aware architecture for most use cases, especially when service autoscaling is required. Note that this architecture is only available for Helm-based installations. For more information on this topic, please refer to the Autoscaling APIs documentation.

Ingress agnostic Architecture

The Ingress-agnostic architecture uses a single entry point for all API calls—either an Ingress or a Service of type LoadBalancer—which routes traffic through an Nginx service acting as both a frontend and a reverse proxy. Nginx is responsible for distributing incoming requests among the internal APIs, public APIs, and hook APIs. In this setup, Nginx handles all the routing logic, and there is only one Ingress or LoadBalancer resource exposing the application to the outside world.

Ingress aware Architecture

The Ingress-aware architecture introduces multiple entry points for API calls by defining four separate Ingress resources, each with its own routing rules. In this model, Nginx serves only as a frontend for the application, while the Ingress resources handle the routing and exposure of:

• Internal APIs
• Public APIs
• The frontend
• Hook APIs

This setup enables fine-grained control over traffic management and routing at the Kubernetes Ingress level, rather than relying solely on Nginx for all routing decisions.

info

Each Ingress object can be replaced by an operator-specific CRD such as an Istio VirtualService or a Traefik IngressRoute. This is available for both Ingress agnostic and Ingress aware architectures, but is only supported in the helm-based installations. For more details about supported object types, check the Ingress routes documentation page.

For more details on deployment configurations, pod types, and usage, check the GitGuardian Application Topology page. For scaling guidelines, visit Scaling GitGuardian.

Helm Command Line Support

The helm install feature enables streamlined deployment and management via the widely adopted Helm package manager. This integration simplifies installation, upgrades, and configuration as code.

Looking ahead, future releases will extend support for GitOps tools like ArgoCD and introduce more advanced configuration options, including:

• External Secrets Operator
• Istio Service Mesh & Gateway
• Certificate Manager

Learn More: Install on an Existing Cluster using Helm.

Enhanced Security with Chainguard Integration

The GitGuardian architecture incorporates Chainguard, a next-generation security tool that helps mitigate Common Vulnerabilities and Exposures (CVEs) in self-hosted container images.

With Chainguard, GitGuardian strengthens its security posture by:

• Reducing vulnerability risks in container images.
• Implementing FIPS-approved cryptographic modules for secure encryption of sensitive data both at rest and in transit.

This integration reinforces GitGuardian’s commitment to meeting the highest security and compliance standards.

Read More: Common Vulnerabilities and Exposures.