Start Free
Latest | Server installation and setup | Reference architectures | Up to 10M LOC

Reference architecture for Developer Edition / Enterprise Edition (up to 10 M LOC)

On this page

Overview SonarQube Host Database DevOps/CI platform Authentication Monitoring Email notifications Resiliency Scalability Related pages

This page describes the architecture of a SonarQube instance that will support up to 10 million lines of code under normal usage patterns in a non-high availability setup. 

Overview

This reference architecture covers the following components:

  • A virtual machine host with SonarQube (Developer or Enterprise Edition) installed and an nginx HTTPS proxy.
  • PostgreSQL database on a dedicated host. 
  • Analysis integrated with GitHub Actions.
  • Authentication through GitHub.com.
  • Monitoring with Prometheus.
  • Outbound email notifications using an SMTP relay.

This architecture favors the use of open-source components when available. These may be substituted with other similarly capable components, and it is recommended that organizations use components that they are comfortable supporting.

SonarQube Host

The SonarQube Host will have the SonarQube software installed as well as nginx acting as an HTTPS proxy.

Host specification
  • VM configuration: 
    • 4 vCPU
    • 8 GB RAM
    • 50GB SSD Local Storage
  • AWS EC2: c5d.large
  • Azure VM: F4s_v2
  •  GCE: c3-highcpu-4
Networking

By source/destination:

  • SonarQube host:
    • Direction: Outbound
    • Port: 5432
    • Purpose: Database
  • SonarQube host:
    • Direction: Outbound
    • Port (Protocol): 25 (SMTP)
    • Purpose:  Email notifications
  • Internal network (user desktops):
    • Direction: Inbound
    • Port (Protocol): 443 (HTTPS)
    • Purpose: Inbound web and API traffic
  • CI platform (GitHub Runners):
    • Direction: Inbound
    • Port (Protocol): 443 (HTTPS)
    • Purpose: Analysis reports
  • DevOps platform (GitHub.com):
    • Direction: Inbound
    • Port (Protocol): 443 (HTTPS)
    • Purpose: Pull Request reports
Software
  • OS - Ubuntu Server (or other Linux distribution)
  • OpenJDK 17
  • SonarQube Developer or Enterprise Edition
  • nginx
    • Configured as a reverse proxy between incoming traffic and SonarQube port 9000. 
    • Secured with SSL. Use of self-signed SSL certificates will require installation of the certificate on all CI build agents, and developer desktops using SonarLint.
    • May be substituted with other reverse proxy (ex. haproxy) or a solution from a cloud provider, such as an AWS Application Load Balancer (ALB).

Database

This architecture utilizes a dedicated PostgreSQL database installed on a separate host.

Host specification
  • VM Configuration:
    • 2vCPU
    • 8 GB RAM
    • 30 GB table space
  • AWS RDS:
    • db.t3.large
    • 30 GB table space
  • Azure SQL:
    • B2ms
    • 30 GB table space
  • Google Cloud SQL:
    • 2 vCPU
    • 8 GB memory
    • 30 GB table space


Database requirements can vary widely based on the usage patterns of each SonarQube installation. Therefore, it is important to monitor and adjust database resources as needed. 

PostgreSQL may be substituted with other supported database platforms.

DevOps/CI platform

Automated analysis of source code is enabled through the installation of the various SonarScanners into continuous integration pipelines. When using GitHub Actions, scanners are initiated through the repository’s workflow YAML file(s). 

Upon analysis completion, SonarQube submits reports back to pull requests to integrate with code review processes. This functionality is enabled in GitHub.com using a GitHub App. 

GitHub.com may be substituted with other supported DevOps and/or CI platforms without changes to other components in this architecture.

Authentication

It is recommended that authentication and authorization be handled through an external identity provider. The architecture utilizes the GitHub App to authorize users and synchronize access to SonarQube projects. 

Other external identity providers such as SAML may be substituted. Features such as group and permission synchronization are not available for all authentication methods.

Monitoring

SonarQube exposes endpoints that are easy to monitor using Prometheus or other monitoring solutions. In addition to the overall system health of both the SonarQube host and database, it is recommended to monitor SonarQube’s Compute Engine performance statistics to ensure incoming analyses are being promptly processed.

Email notifications

Users can be notified of new issues and events via email. SonarQube will deliver these notifications through an SMTP mail relay. The volume of emails is low, dependent on the number of users subscribed, and a dedicated SMTP server is typically not required.

Resiliency

As a single-host installation, this architecture relies on robust monitoring, automated backups of the database, and a rapid recovery process to maximize resiliency. If high availability is critical, SonarQube Data Center edition is recommended.

Scalability

This architecture is designed to support typical production usage for up to 10 million lines of code. Beyond this, it is recommended that organizations use SonarQube Enterprise Edition or Data Center Edition to support high-volume workloads. 

The following use cases are considered outside of “normal usage” and may require additional capacity:

High-frequency analysis

Normal usage assumes a daily scan of main branches and analysis of several pull requests. Scanning code more frequently may require an increase in the number of Compute Engine workers (using SonarQube Enterprise Edition) as well as additional memory and CPU resources allocated to SonarQube’s Compute Engine process. Monitoring of the Compute Engine process will ensure that your installation can keep up with demand.

Large repositories

This architecture assumes analyzed repositories average 50,000 lines of code. If your organization is scanning a majority of very large repositories (where the repositories average 500,000 lines of code or more), additional memory and CPU resources may be required for SonarQube’s Compute Engine process.

Heavy API integration

SonarQube exposes a REST-based API for reporting and automation of administration tasks. This architecture assumes occasional use of this API. Heavy use of this API may require the allocation of additional memory and CPU resources to SonarQube’s Web process.

Third-party plugins

This architecture assumes that no third-party plugins are in use. As these extensions are developed by open-source developers, their impact on the performance of a SonarQube instance varies based on the function being performed and the quality of the implementation. It is recommended that the use of third-party plugins is carefully considered and monitored for performance throughout the life of your SonarQube implementation.

Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License