Skip to main content

Network requirements

Depending on the installation method, you'll have some network requirements, even for Airgap environments.

Services and components#

GitGuardian uses different components for its functioning:

  • Nginx: Web Server,
  • Celery: queue and task manager,
  • Django: framework used for the application,
  • PostgreSQL: database,
  • Redis: cache manager,
  • Replicated: management console.

Services and components

After installing the GitGuardian application, you will see different pods created on your Kubernetes cluster:

  • app: front-end workers, serving API requests and static web frontend files,
  • worker: workers handling incremental changes, new commits, etc. These workers are usually processing short-running tasks,
  • long-tasks: workers are usually processing long-running cyclic tasks, like synchronizing a VCS integration with the VCS server data,
  • scanner: workers handling historical scans,
  • beat: automated tasks scheduler,
  • exporter: metrics exporter used by Prometheus.

External access#

Domains to whitelist#

The following domains can be needed:


A list of IP addresses for this is maintained by Replicated:

Ports to open#

Ingoing ports are used to access the dashboard and the API, but also for your VCS webhooks.

Here is a list of features that will make outbound requests:

  • Secret validity checkers
  • VCS Integrations (GitHub, GitHub Enterprise, GitLab,...)
  • External notifiers (Slack, Jira,...)
  • Custom webhook notifier
  • Email notifications (either SMTP or Sendgrid)

For Embedded cluster#

For Embedded installation, you should open the following ports:

  • outgoing access on TCP 443 to download the application installer, prerequisites, application containers and to access to VCS,
  • incoming access on TCP 8800 to access the admin console,
  • incoming access on TCP 443 to access the GitGuardian dashboard.

We recommend dropping all incoming traffic except on ports TCP 80, TCP 443 and TCP 8800.

For Existing cluster#

For Existing installation, you should open the following ports:

  • outgoing access on TCP 443 to download the application installer, prerequisites and application containers, and to access your VCS,
  • incoming access for the GitGuardian dashboard.

By default, the GitGuardian application is shipped with an Ingress.

Nginx reverse proxy example for embedded installation#

If you want to set up a reverse proxy in front of your embedded installation, you need to configure and forward the SNI header properly.

Here is an example configuration for an Nginx vhost. external_gitguardian_hostname is the hostname to use in a browser to access the dashboard, and internal_gitguardian_hostname is the hostname used to reach the GitGuardian instance internally from the reverse proxy. This is also the hostname set up in the Kots admin console.

server {    listen 443 ssl http2;    listen [::]:443 ssl http2;    server_name external_gitguardian_hostname;
    ssl_certificate           /path/to/fullchain.pem;    ssl_certificate_key       /path/to/privkey.pem;
    set $target_host internal_gitguardian_hostname;
    location / {      proxy_set_header        Host $target_host;      proxy_set_header        X-Real-IP $remote_addr;      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_pass          https://$target_host;      proxy_read_timeout  60;      proxy_ssl_name $target_host;      proxy_ssl_server_name on;      proxy_ssl_protocols TLSv1.2 TLSv1.3;      proxy_ssl_session_reuse off;    }}

Architecture examples#

Here are some architecture examples that can help you install and configure your GitGuardian environment.

Internal network#

Internal network graph

If you have an internal network behind a firewall, you can easily connect to an internal VCS (eg: self-hosted GitLab).

However, if you want to connect to, therefore requiring internet access, you will need to open wide incoming access to the HTTPS port of your GitGuardian instance.


It is possible to restrict traffic to IP addresses, but this is not recommended by GitHub. You can use a Web Application Firewall (WAF) or a proxy to monitor closely the incoming traffic on the GitGuardian instance.

In this scenario, the GitGuardian instance needs an open 443 egress port to get updates.

Internal network with DMZ#

DMZ network graph

If in addition to an internal network, you have a DMZ and you want to integrate with, you can put the GitGuardian instance in the DMZ. This makes it easier to access but you will need to expose your internal VCS outside of your internal network so that the GitGuardian instance can access it.

In this scenario, GitGuardian needs an open 443 egress port to get updates.

Isolated network#

Isolated network graph

In this scenario, the GitGuardian instance is completely isolated from the Internet. It is offline and airgapped. This means no monitoring is possible. This also means you don't need an open 443 egress port to get updates.


This Airgap functionality is not available by default. Please contact your sales representative if you want to enable it.