At FOSSA, we know that different organizations have different infrastructure and IT needs, which is why we support multiple deployment models. FOSSA customers can choose from a range of SaaS and on-premises options; our engineering and customer success teams have extensive experience ensuring successful implementations no matter which method you select.

With that said, there are important differences between deployment models that we recommend organizations consider before making a final decision. In this blog post, we’ll discuss these differences along with a brief overview of all supported deployment options.

SaaS vs. On-Premises

Before we dive into the specifics of each deployment model, let’s discuss some of the considerations around what’s often the first major decision: SaaS or on-premises.

Although FOSSA supports multiple successful deployments in both scenarios, the vast majority of our customers choose SaaS. This is the case for several important reasons related to user experience:

  • Infrastructure: On-premises installation requires you to deploy and configure your own infrastructure.
  • Deployment: Deploying the actual application requires customization.
  • Debugging: Without direct access to customer infrastructure, time to mitigation (and time to resolution) tends to be higher; our support and engineering teams often need to spend more time researching the issue before making a fix.
  • Upgrading and patching: On-prem customers generally cannot deploy upgrades at the same pace that FOSSA ships them.
  • Cost: FOSSA doesn’t charge more for on-premises deployments, but on-prem is available only to customers at certain subscription levels. There are also expenses associated with the hardware that on-premises users run FOSSA on.

When is On-Prem the Right Fit?

Although we recommend SaaS to the majority of FOSSA users, we certainly understand that on-premises is a requirement for certain types of companies and industries. Generally, organizations with the following IT policies tend to prefer on-premises deployments:

  • Self-manage all infrastructure:
    • No public cloud services
    • No virtual private cloud
      • Unless a GovCloud equivalent
  • Self-manage all tooling
    • No SaaS VCS (GitHub, GitLab)
    • No SaaS-based email (Gmail, Slack, MS 365)
    • No SaaS CI (Jenkins, Circle CI, CodePipelines, ADO, etc)
    • No SaaS registries (Artifactory, ECR, etc)
    • No SaaS productivity tools (Jira, Confluence, Notion, etc)
    • No SaaS analytics (BI, Tableau, Looker, Google Analytics, etc)

Supported SaaS Deployments

Each FOSSA SaaS deployment method offers two primary ways of importing your projects:

  • Through a Version Control System like GitHub; this does require granting FOSSA temporary code access
  • Through our Command Line Interface (CLI); this does not require granting FOSSA code access, but we generally recommend it only for organizations with centralized CIs and/or for high-priority projects to ensure comprehensive coverage.

It’s important to keep this context in mind as you consider FOSSA’s SaaS deployment options; your preferred integration method will likely have a significant impact on your decision.

An important note for organizations considering a VCS integration: FOSSA takes the security and privacy of your code extremely seriously. We don’t store your code — we temporarily clone the repo to determine the full dependency graph. The moment the full dependency graph is complete, FOSSA immediately deletes the cloned repo. Additionally, information is anonymized as FOSSA returns only the packages found in the repo, not any source code.

FOSSA’s supported SaaS deployments are:

1. Public SaaS (Recommended): Public SaaS is the most popular FOSSA deployment model. You won’t have to worry about overhead, resourcing or database storage, upgrades, or patching. Plus, you’ll get features the moment we ship them.

We also offer Public SaaS with broker: If your organization does not have a centralized CI (which may make the CLI integration method a poor fit) — and has concerns about granting FOSSA code access — this option may make sense. (The CLI integration method does not grant FOSSA code access.) It deploys a service on-premises (with code access) that analyzes and uploads the dependency graphs of your code to FOSSA SaaS without the latter having code access.

2. Private SaaS: If your organization requires single tenancy — i.e. tenant isolation for security and/or performance reasons — then our private cloud option provides many SaaS benefits (including faster support, monitoring, and managed upgrades) without the drawbacks of on-premises.

We also offer Private SaaS with broker: This method may make sense if your organization requires single tenancy, doesn't have a centralized CI, and has concerns granting FOSSA access to your code. In this situation, a broker can be used in combination with a private cloud instance.

Supported On-Premises Deployments

FOSSA offers several on-premises installation methods. These include:

  • Self-contained installations: FOSSA can be deployed all-in-one on existing Kubernetes clusters. It ships all of its own external service dependencies, including Postgres and MinIO.
  • Installations with managed external services: FOSSA can also be configured to use managed external hosting for service dependencies like Postgres and S3.

To learn more about our on-premises deployment options, please feel free to contact our product team: product@fossa.com.

Unsupported On-Premises Deployments

It’s important to note that FOSSA does NOT support air-gapped on-premises. This is because of the way our customers interact with open source software. The developers who adopt open source have access to the internet to evaluate (and actually download) packages for their applications. As a result, our current platform assumes that outbound internet access is available. This assumption shows up in many places:

  • To resolve (i.e. download) packages for license scanning
  • To download new versions of the CLI and application components
  • To contact our support team and provide debug bundles
  • To access end-user documentation

Additionally, internet access plays a vital role in enabling code updates and customer success initiatives.

Learn More About FOSSA Deployment Methods

If you’re considering FOSSA and would like more information about deployment options, please contact hello@fossa.com. Or, feel free to ask your sales representative to connect you with one of our product experts.