# Networking requirements

## Network topology

The diagram below shows the network topology for SonarQube Community Build:

* The DevOps platform, the SonarScanner, the user (Web browser), the IDE in connected mode, and any other external system, will connect to SonarQube through the Web API. You must use a reverse proxy if you want to use HTTS. 
* An external Identity Provider (other than GitHub, Bitbucket Cloud, or GitLab) can be used with one of the following authentication methods: OAuth, LDAP, SAML, or OpenID.
* SonarQube connects to its database through JDBC.
* SonarQube authenticates to the DevOps platform via OAuth and sends the quality gate status report via HTTP(S).
* SonarQube sends quality gate webhooks to the CI/CD platform via HTTP(S).

<figure><img src="broken-reference" alt="SonarQube Server topology network"><figcaption></figcaption></figure>

{% hint style="info" %}
The CI platform may be integrated into the DevOps platform.
{% endhint %}

## SonarQube base URL

The SonarQube base URL needs to be a public URL if SonarQube expects to receive information from an external system. This is relevant if:

* You use SCIM (since it requires SonarQube to be reachable by the Identity Provider).
* You use Cloud-hosted CI pipelines.

## HTTPS

For most production instances, traffic encryption (and therefore HTTPS) is required. As SonarQube only supports plain HTTP for inbound traffic, a reverse proxy is necessary to terminate SSL/TLS encryption before SonarQube. For more information, see [securing-behind-proxy](https://docs.sonarsource.com/sonarqube-community-build/server-installation/network-security/securing-behind-proxy "mention").

## Network rules

You can define network rules to enhance the network security. For more information, see [network-rules](https://docs.sonarsource.com/sonarqube-community-build/server-installation/network-security/network-rules "mention").