SonarQube Community on Ubuntu 24.04 on Azure User Guide

Overview

SonarQube is the widely used continuous code-quality and static-analysis platform: it inspects your code for bugs, vulnerabilities, security hotspots and code smells across dozens of languages, tracks technical debt over time, and enforces a configurable Quality Gate in your CI pipeline. The cloudimg image installs SonarQube Community Edition (the official SonarSource distribution) under a dedicated non-root sonarqube service user, on the OpenJDK 17 JRE, behind nginx as a reverse proxy. The SonarQube web server listens on 127.0.0.1:9000 and is reached through nginx on port 80; a local PostgreSQL is SonarQube's mandatory backing store and binds to the loopback interface only.

SonarQube embeds Elasticsearch for its search index, which requires the kernel settings vm.max_map_count=524288 and fs.file-max=131072 — these are written to /etc/sysctl.d/99-sonarqube.conf so they persist across every reboot, and Elasticsearch runs as the non-root sonarqube user. SonarQube does not support its embedded H2 database for real use, so this image ships a local PostgreSQL as the backing store. SonarQube's default admin account has its password rotated to a unique per-VM value on the first boot of every deployed VM and written to /root/sonarqube-credentials.txt with mode 0600, so no two VMs share credentials. Backed by 24/7 cloudimg support.

What is included:

• SonarQube Community Edition 10.7 (/opt/sonarqube) on the OpenJDK 17 JRE, run as the non-root sonarqube user
• nginx reverse proxy on :80 in front of the SonarQube web server (bound to loopback :9000), with an unauthenticated /health endpoint
• PostgreSQL as SonarQube's backing database, bound to loopback only
• A dedicated 40 GiB Azure data disk at /var/lib/sonarqube holding the SonarQube data/ and extensions/ directories and the PostgreSQL datadir — separate from the OS disk and re-provisioned with every VM
• Elasticsearch kernel and ulimit requirements persisted in /etc/sysctl.d and /etc/security/limits.d
• Per-VM admin password, rotated at first boot, in a root-only file
• sonarqube.service, postgresql.service and nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended starting point — SonarQube runs a JVM web process, a JVM compute-engine process and an embedded Elasticsearch JVM alongside PostgreSQL, so it needs memory headroom. NSG inbound: allow 22/tcp from your management network and 80/tcp from the networks your users and CI runners will reach SonarQube on (front port 80 with TLS for public exposure — see Enabling HTTPS).

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for SonarQube by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create → Create.

First boot initialisation takes approximately three to five minutes after the VM starts — SonarQube runs its database migrations, bootstraps Elasticsearch and rotates the admin password on first boot.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name sonarqube \
  --image <marketplace-image-urn> \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name sonarqube --port 80 --priority 1010

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the services are running

systemctl is-active sonarqube.service postgresql.service nginx.service
curl -fsS http://127.0.0.1/health
curl -fsS http://127.0.0.1/api/system/status

All three services report active, the open /health endpoint returns ok, and /api/system/status reports "status":"UP", confirming the full stack — nginx, the SonarQube web server, the compute engine, Elasticsearch and PostgreSQL — is serving. On the very first boot allow a few minutes for migrations and the Elasticsearch bootstrap before the status reports UP.

Step 5 — Retrieve your administrator login

SonarQube's default admin password is rotated to a value unique to your VM on first boot and written to a root-only file:

sudo cat /root/sonarqube-credentials.txt

The SONARQUBE_ADMIN_PASSWORD value is your sign-in password; the username is admin. To verify the credentials over the API without a browser, use the open /api/authentication/validate endpoint with basic auth — for example curl -u admin:<SONARQUBE_ADMIN_PASSWORD> http://127.0.0.1/api/authentication/validate, which returns {"valid":true} for the correct password and {"valid":false} for a wrong one.

Step 6 — First sign-in

Open a web browser and navigate to http://<vm-public-ip>/. Sign in with the username admin and the password from /root/sonarqube-credentials.txt.

The SonarQube sign-in page, served through nginx with the per-VM administrator password already rotated at first boot.

Step 7 — Create a project and analyse code

After signing in, choose Create a local project (or import from Azure DevOps, GitHub, GitLab or Bitbucket). Give the project a key and set up the analysis method — for a local project, generate a project analysis token, then run the SonarScanner in your source tree pointing at this server. SonarQube supports Maven, Gradle, .NET, and the standalone SonarScanner CLI; the exact command is shown in the UI once you pick your build system.

Creating the first project — SonarQube can import from Azure DevOps, GitHub, GitLab and Bitbucket, or you can create a local project and analyse with the SonarScanner CLI.

Step 8 — Quality Gates

A Quality Gate is the set of conditions your code must meet to be marked as passing — for example, no new bugs, no new vulnerabilities, and coverage on new code above a threshold. SonarQube ships the built-in Sonar way gate; open Quality Gates in the top menu to review it or create your own, and assign it to your projects so every analysis is enforced consistently in CI.

Quality Gates — the built-in "Sonar way" gate plus any custom gates you define, enforced on every analysis.

Step 9 — Confirm the runtime and system info

The SonarQube version, the Java runtime and the persisted Elasticsearch kernel requirements can be confirmed from the shell, and the running server details are shown under Administration → System:

curl -fsS http://127.0.0.1/api/server/version
java -version
sysctl vm.max_map_count fs.file-max

Administration → System — server ID, edition and version, and the health of the web, compute-engine and search components.

Step 10 — Confirm the data tiers

The SonarQube data/ and extensions/ directories and the PostgreSQL datadir all live on the dedicated 40 GiB Azure data disk mounted at /var/lib/sonarqube:

findmnt -no SOURCE,SIZE,FSTYPE,TARGET /var/lib/sonarqube
sudo -u postgres psql -tAc 'SHOW data_directory'

Enabling HTTPS

For production, serve SonarQube over HTTPS so session tokens and analysis data cannot be intercepted. The image ships with nginx, which certbot can configure automatically. The following assumes a DNS record pointing your fully qualified domain name at the VM's public IP:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d sonarqube.your-domain.example \
  --non-interactive --agree-tos -m you@your-domain.example \
  --redirect

After certbot finishes, set the Server base URL under Administration → Configuration → General Settings to your HTTPS URL so SonarQube generates correct links in notifications and pull-request decorations.

Backup and maintenance

SonarQube keeps all of its state — projects, issues, measures, quality profiles, quality gates and users — in its PostgreSQL backing database on the dedicated data disk. Back it up regularly:

sudo -u postgres pg_dump sonarqube > /tmp/sonarqube-db-$(date +%F).sql

Ship the dump to Azure Blob Storage or another object store, or snapshot the data disk in Azure for a coordinated point-in-time backup. Keep the OS patched with sudo apt update && sudo apt upgrade. To upgrade SonarQube itself, follow the official upgrade guide for your target version, always taking a database backup first; the compute engine migrates the schema on the next start. Elasticsearch's kernel requirements are already persisted, so they survive reboots and upgrades.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and chat for help with deployment, project onboarding, CI integration, upgrades, TLS termination and database administration. Contact support@cloudimg.co.uk.

For general SonarQube questions consult the documentation at https://docs.sonarsource.com/. SonarQube is a trademark of SonarSource SA. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.