Operating the Server
When installing SonarQube as a service on Windows, the path to the executable should be quoted to prevent unquoted service path attacks.
> "%SONAR_HOME%\bin\windows-x86-64\StopNTService.bat" does a graceful shutdown where no new analysis report processing can start, but the tasks in progress are allowed to finish. The time a stop will take depends on the processing time of the tasks in progress. You'll need to kill all SonarQube processes manually to force a stop.
Stop does a graceful shutdown where no new analysis report processing can start, but the tasks in progress are allowed to finish. The time a stop will take depends on the processing time of the tasks in progress. Use force stop for a hard stop.
On a Unix system using SystemD, you can install SonarQube as a service. You cannot run SonarQube as root in Unix systems. Ideally, you will created a new account dedicated to the purpose of running SonarQube. Let's suppose:
- The user used to start the service is
- The group used to start the service is
- The Java Virtual Machine is installed in
- SonarQube has been unzipped into
Then create the file
/etc/systemd/system/sonarqube.service based on the following:
- Because the sonar-application jar name ends with the version of SonarQube, you will need to adjust the
ExecStartcommand accordingly on install and at each upgrade.
- * The SonarQube data directory,
/opt/sonarqube/data, and the extensions directory,
/opt/sonarqube/extensionsshould be owned by the
sonarqubeuser. As a good practice, the rest should be owned by
sonarqube.service file is created and properly configured, run:
The following has been tested on Ubuntu 8.10 and CentOS 6.2.
Create the file /etc/init.d/sonar with this content:
Register SonarQube at boot time (RedHat, CentOS, 64 bit):
Once registration is done, run:
This section helps you configure the SonarQube Server if you want to run it behind a proxy. This can be done for security concerns or to consolidate multiple disparate applications. To run the SonarQube server over HTTPS, see the HTTPS Configuration section below.
For security reasons, we recommend only giving external access to the main port.
We assume that you've already installed Apache 2 with module mod_proxy, that SonarQube is running and available on
http://private_sonar_host:sonar_port/, and that you want to configure a Virtual Host for
At this point, edit the HTTPd configuration file for the
www.public_sonar.com virtual host. Include the following to expose SonarQube via
mod_proxy at http://www.public_sonar.com/
Apache configuration is going to vary based on your own application's requirements and the way you intend to expose SonarQube to the outside world. If you need more details about Apache HTTPd and mod_proxy, please see http://httpd.apache.org.
We assume that you've already installed Nginx, that you are using a Virtual Host for
www.somecompany.com and that SonarQube is running and available on
At this point, edit the Nginx configuration file. Include the following to expose SonarQube at
Nginx configuration will vary based on your own application's requirements and the way you intend to expose SonarQube to the outside world. If you need more details about Nginx, please see https://www.nginx.com/resources/admin-guide/reverse-proxy/.
Note that you may need to increase the max URL length since SonarQube requests can have URLs longer than 2048.
Note that the setup described in this blog post is not appropriate for SAML through IIS.
© 2008-2023, SonarSource S.A, Switzerland. Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution-NonCommercial 3.0 United States License. SONARQUBE is a trademark of SonarSource SA. All other trademarks and copyrights are the property of their respective owners.