Skip to main content
Contact Support

Firewall and internal server configuration for Flow

Tags:

Many customers host their Git repositories on internal servers using GitHub Enterprise, GitLab, Bitbucket Server, Jira, or similar products. Flow needs to access these servers in order to collect the data used to calculate your metrics. To receive emails from Flow and Pluralsight in general, also allowlist these email domains.

This can be accomplished securely by allowing access via HTTPS or SSH access to internal repositories. This ensures that all data transmitted to Flow is transmitted over a secure protocol.

Setup

To make sure Flow can access your data:

  1. On your internal Git server, add Flow's static IP addresses to your allowlist:
    Flow static IP addresses
    52.89.66.218
    52.88.145.188
    52.34.18.208    		 54.185.167.177
    52.12.105.163
    54.148.234.120    		 3.132.140.21
    3.128.138.77
    3.129.193.109
  2. Open up a port on your network.
  3. Once we have confirmed a secure connection with Flow, you may import your repos via one of our supported vendors or HTTPS.

Note: If you use an internal Git or ticketing server to integrate with Flow, ensure port 443 is open for Flow to connect to your instance to ingest git, PR, and ticket data. You may have an additional web application firewall (WAF). If so, allowlist these IPs for that firewall and adjust your WAF rate limits as needed.

Connecting Flow to self-hosted servers behind an API gateway or reverse proxy

For Flow to ingest your data, your self-hosted git and ticket servers must be reachable via a public domain. This public domain is configured as your Base URL during integration setup. When Flow makes the initial connection with your git or ticket systems, it retrieves a list of available projects with their associated URLs. However, if your git or ticket servers sit behind a reverse proxy or API gateway, the returned project URLs will be associated with your private domain and not reachable by Flow. It requires additional configuration to properly map these internal URLs to your public domain. 

This diagram outlines the steps our ingestion process follow and which URL domains Flow receives in response.

A data ingestion diagram detailing the API calls Flow makes to ingest data when the customer has a private domain, the response codes it receives in return, and the public and private domain URLs returned with each call. Step 1 is the credentials validation with 200 OK status. Step 2 is Flow's project discovery from the public domain with the vendor responding with private domain URLs. Step 3 is Flow's attempt to process data from those vendor URLs and receiving a DNS error in response since the private domain URLs aren't reachable outside of the firewall.

If your git or ticket servers sit behind a reverse proxy or API gateway, please reach out to your Pluralsight contact or contact Pluralsight Support to provide the fully qualified domain name of your public domain. Flow will map the private domain retrieved from your integration to your public domain to transform the URLs to ingest data. This public domain should be in the form of either:

  • public.domain.com
  • public.domain.com/<some>/<path>
  • public.domain.com:<port number>
  • public.domain.com:<port number>/<some>/<path>

Once Flow maps your domains, your data may need to be ingested and processed again for the changes to take effect.

Note: If you have a reverse proxy which limits the size of outgoing data, make sure the data limit is set to be larger than your largest repo so Flow can correctly complete data ingestion.

Related articles