Architecture Overview
How FOSSA's services connect inside your on-premises environment, from the network boundary that keeps your code and scan results in your network down to the individual services running in your cluster.
Overview
When FOSSA is installed behind your firewall, the entire analysis pipeline runs inside your organization's network. This page explains how FOSSA's services connect to one another and to the outside world, so you can evaluate the deployment against your security and data-residency requirements.
A sealed environment
When FOSSA runs on-premises, your code and its analysis never leave your network:
- Your proprietary code never leaves your premises. FOSSA clones, builds, and analyzes your code entirely within your intranet.
- Your scan results stay in your environment. Analysis data, signatures, and project findings are stored in your own database, not sent to FOSSA.
- No added InfoSec footprint. FOSSA downloads and analyzes third-party open-source code anonymously from the public web, the same way a developer machine or CI runner already does.
Note
The guarantee applies to your proprietary code and scan results; those stay inside your network. Your FOSSA instance still makes outbound connections to download open-source packages and to receive vulnerability intelligence. Those paths are described under How data flows below.
How data flows
Inside your network, three groups of FOSSA services work together:
- Analysis Cluster: clones and analyzes your code and its open-source dependencies.
- Database / Build Queue: stores analysis results and coordinates scan jobs.
- Web Server Cluster: serves the dashboard, reports, and API to your users.
FOSSA makes two kinds of outbound connection. Both receive data into your instance rather than sending your data out:
| Outbound connection | Purpose | When it's used |
|---|---|---|
| Public package registries & code hosts | Download third-party open-source code to analyze | Optional, only when analyzing dependencies fetched from the public internet |
FOSSA vulnerability feed (vulns.fossa.com) | Keep your vulnerability database current with the latest CVE/CPE intelligence | Required when FOSSA's security (vulnerability) scanning is enabled |
Warning
If you enable FOSSA's security features, your instance must be able to reach FOSSA's vulnerability feed to receive over-the-air vulnerability data updates. Confirm the required egress (and whether an air-gapped or offline data-import option fits your environment) with your FOSSA account team.
For the specific hosts and IP ranges to allow through your firewall, see IP Space Allowlisting.
Inside the FOSSA cluster
The three groups above are a simplification. Internally, FOSSA is a set of cooperating services running in your Kubernetes cluster, backed by several PostgreSQL databases and a Redis cache. This is the same architecture that powers FOSSA's hosted cloud; an on-premises installation runs the identical services, just inside your own infrastructure rather than FOSSA's.
Mapping these services back to the three groups above:
- Web Server Cluster: Core serves the dashboard, reports, and API to your users and the CLI, and orchestrates the other services; Hubble and Sparkle back the component and reporting experiences.
- Analysis Cluster: Fetchers clones and downloads your source code and its open-source dependencies from code hosts and public package registries; Ramjet and Sherlock handle component identification and file-hash analysis; the Vulns service serves vulnerability data for security scans.
- Database / Build Queue: the PostgreSQL databases store customer, analysis, component, and threat data, Redis provides caching, and Faktory runs the asynchronous job queue.
How vulnerability data differs from the cloud
This is the one place where the on-premises topology departs from FOSSA's hosted cloud. In the cloud, the Vulns service aggregates raw vulnerability intelligence directly from upstream sources such as the NVD and security bulletins. On-premises, your instance does not reach out to those upstream feeds. Instead, FOSSA curates that intelligence centrally and publishes it to its vulnerability feed, and a Vulns OTA Updater CronJob in your cluster pulls the prepared snapshots into your local threat database. See On-Prem Vulnerability Database Updates for how to enable and monitor it.
Results flow into your internal tools
FOSSA publishes scan results back into the tools your developers already use, surfacing issues in CI/CD pipelines, issue trackers, notifications, and the FOSSA dashboard. Configuring these connections is covered in Integrations.
What this means for you
- If you have strict data-residency requirements, your source code and analysis results remain within your network boundary.
- Plan your outbound egress around two needs: access to public package registries (when analyzing public open-source code) and access to FOSSA's vulnerability feed (when using security scanning).
- For day-to-day user and access management, see Organization Management. It works the same as the hosted product.