
1.0 SonarQube - Overview
SonarQube is an industry-leading open-source platform for continuous inspection of code quality and security. It performs automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities across 30+ programming languages.
The SonarQube platform consists of several key components:
- SonarQube Server: The central component that provides a web interface, computes code analysis, and stores results in a database.
- SonarQube Database: Stores configuration and analysis results.
- SonarQube Scanners: Client applications that analyze projects and send results to the server.
- SonarQube Plugins: Extensions that add functionality to the core platform.
Key features of SonarQube include:
- Static Code Analysis: Analyzes source code without executing it, checking for issues such as bugs, security vulnerabilities, and code duplication.
- Quality Gates: Defines standards that code must meet to pass analysis, ensuring only high-quality code reaches production.
- Security Vulnerability Detection: Identifies security issues with unrivaled ability to find deeply hidden security vulnerabilities.
- Code Smell Detection: Identifies inefficiencies or non-optimal coding patterns that may lead to maintainability issues.
- DevSecOps Integration: Easily integrates with development workflows through GitHub Actions, GitLab CI/CD, Azure Pipelines, and more.
- Multi-language Support: Analyzes code in 30+ programming languages including Java, JavaScript, C#, Python, Go, and more.
You can find more details at https://www.sonarsource.com/products/sonarqube/
1.1 Prerequisites
The minimal requirements for deploying SonarQube are as follows:
- At least 2 CPU cores
- At least 4 GB of Memory
- At least 20 GB of free disk space
For optimal performance in Azure, we recommend selecting the following VM sizes:
- Standard D-Series v4 & v5: D2as_v4, D4as_v4, D2as_v5 and D4as_v5
2.0 Deploying SonarQube
Now let's begin with the deployment process!
The first step is to create a new Virtual Machine using our Marketplace solution. Log in to the Azure Marketplace

Check the plan details and click "CREATE"

Select a name for your Virtual Machine, choose the appropriate size, configure networking, disk options, etc.

Important: We recommend adding an extra disk to store your SonarQube data. Please check Configuring disk extension for more details.
Review your configuration and create the Virtual Machine. The creation process will take a few minutes.
That's it! Once your VM is ready, you can connect via web browser or SSH.
To access the SonarQube web interface, open your browser and navigate to http://yourvmIP:9000
The default login credentials are:
- Username: admin
- Password: admin
Note: You will be prompted to change the default password on first login.

You can also connect using SSH. For more information, see How to use SSH with Linux on Azure.
$ssh username@yourvmIP
2.1 Configuring disk extension
We recommend adding an extra disk to store your SonarQube data. You can add the extra disk during or after the creation of the solution.
As shown in the image below, we've added an additional 30GB disk for our data. For more information, see how to attach a data disk to a Linux VM

To partition, format, and mount your new disk, SSH into your VM:
$ssh username@yourvmIP
Once connected to your VM, you need to find the disk. In this example, we are using fdisk
to list the disks:
# fdisk -l | grep Disk
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors
Disk label type: gpt
Disk identifier: BDE4368E-CB4D-4467-BEF9-E2665AF59129
Disk /dev/sdb: 80.5 GB, 80530636800 bytes, 157286400 sectors
Disk label type: dos
Disk identifier: 0x1e56eb14
Disk /dev/sdc: 30.0 GB, 30064771072 bytes, 58720256 sectors
We can see the Disk /dev/sdc that we attached to the Virtual Machine.
Format the disk
The following example uses parted on /dev/sdc, which is where the first data disk will typically be on most VMs. Replace sdc
with the correct option for your disk. We are formatting it using the XFS filesystem:
sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%
sudo mkfs.xfs /dev/sdc1
sudo partprobe /dev/sdc1
Now let's check our new partition and copy the UUID as we'll need this value in the next steps:
# sudo blkid
/dev/sda2: UUID="8fad5ef4-9341-44dc-9538-1941f55e4f44" TYPE="xfs" PARTUUID="fd2b2dda-b5cf-4490-a3c5-a1127e1dfd32"
/dev/sdb1: UUID="86b913a0-7220-4749-b436-d439e007c589" TYPE="ext4"
/dev/sda1: UUID="ae9ae61c-c596-4593-8a33-8deeb9820e38" TYPE="xfs" PARTUUID="5c86595d-a28a-43ea-9102-f192eee01417"
/dev/sda14: PARTUUID="593a0311-9927-4e3f-9778-a4953ae15f76"
/dev/sda15: SEC_TYPE="msdos" UUID="38D3-7C4E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="60f61173-b112-4c24-9d65-c7035541eb15"
/dev/sdc1: UUID="7b49425e-4280-41ba-938f-a74daf035ba4" TYPE="xfs" PARTLABEL="xfspart" PARTUUID="2abc4e40-2376-43ee-ae41-9a5667a85380"
Configure SonarQube to use the new disk
First, stop the SonarQube service:
# sudo systemctl stop sonarqube.service
Let's back up the existing data:
# sudo cp -r /opt/sonarqube/data/ /tmp
Mount the filesystem. The following example mounts the /dev/sdc1 partition to a new directory:
sudo mkdir -p /sonarqube-data
sudo mount /dev/sdc1 /sonarqube-data/
Now, let's restore the data and configure the permissions:
# sudo cp -r /tmp/data/* /sonarqube-data/
# sudo chown -R sonarqube:sonarqube /sonarqube-data/
Update the SonarQube configuration to use the new data directory. Edit the SonarQube properties file:
sudo nano /opt/sonarqube/conf/sonar.properties
Find and uncomment (or add) the following line, changing the path to your new data directory:
sonar.path.data=/sonarqube-data
Save the file and start the SonarQube service:
sudo systemctl start sonarqube.service
Persist the mount
To ensure the disk is mounted automatically after a reboot, we need to update the fstab file. We'll use the UUID that we obtained with the blkid
command:
sudo nano /etc/fstab
Add the following line to the file (replace the UUID with your own):
UUID=7b49425e-4280-41ba-938f-a74daf035ba4 /sonarqube-data xfs defaults,nofail 1 2
Save the file and verify that everything is working correctly:
sudo mount -a
2.2 Securing SonarQube
By default, SonarQube uses an embedded H2 database and has the default admin credentials. For production use, we recommend the following security measures:
1. Change the default admin password
On first login, you will be prompted to change the default admin password. If you've already logged in, you can change it by:
- Clicking on your profile icon in the top-right corner
- Selecting "My Account"
- Going to the "Security" tab
- Clicking "Change Password"
2. Configure HTTPS
For production environments, we recommend setting up HTTPS. You can either:
- Configure SonarQube to use HTTPS directly
- Set up a reverse proxy (like Nginx or Apache) with HTTPS
To configure SonarQube for HTTPS, edit the sonar.properties file:
sudo nano /opt/sonarqube/conf/sonar.properties
Uncomment and modify these lines:
sonar.web.https.port=9443
sonar.web.https.keyStore.path=/path/to/keystore.jks
sonar.web.https.keyStore.password=your-keystore-password
3. Use an external database
For production environments, we recommend using an external database like PostgreSQL instead of the embedded H2 database:
sonar.jdbc.username=sonarqube
sonar.jdbc.password=your-strong-password
sonar.jdbc.url=jdbc:postgresql://localhost/sonarqube
4. Set up authentication
SonarQube supports various authentication methods including:
- LDAP/Active Directory
- GitHub/GitLab/Bitbucket OAuth
- SAML
- OpenID Connect
Configure these in the Administration > Configuration > Security section of the web interface.
For more information on securing your SonarQube installation, please refer to the official security documentation.