SonarQube on AWS User Guide

SonarQube is the popular open source platform for continuous code quality and static application security testing (SAST). It analyses your source code for bugs, code smells, security vulnerabilities and security hotspots across many languages, enforces a pass/fail Quality Gate on every analysis, and presents the results on a web dashboard with issue tracking, measures and trends.

This cloudimg Amazon Machine Image delivers SonarQube fully installed and configured on Ubuntu 24.04, so a complete code-analysis server is running within minutes of launch. The edition shipped is the free SonarQube Community Build (LGPL-3.0). SonarQube runs on OpenJDK 17 as a dedicated non-root service, backed by a local PostgreSQL database, and is fronted by nginx on port 80. The Elasticsearch kernel requirements that SonarQube needs are already applied and persisted across reboots.

This guide covers connecting to your instance, retrieving the per-instance administrator password, signing in, running your first analysis, reviewing issues and Quality Gates, and enabling HTTPS.

Architecture at a glance

The SonarQube web interface binds to loopback and is exposed only through nginx. The application data, the embedded Elasticsearch index and the PostgreSQL datadir all live on a dedicated, independently-resizable EBS volume, separate from the operating-system disk, so you can grow storage without rebuilding the instance.

Connecting to your instance

Connect over SSH on port 22 as the default login user for your operating-system variant.

ssh -i /path/to/your-key.pem ubuntu@<instance-public-ip>

Replace <instance-public-ip> with the public IPv4 address of your instance (visible in the EC2 console) and /path/to/your-key.pem with the private key you launched the instance with.

Per-instance credentials

On the first boot of every instance, a one-shot service (sonarqube-firstboot.service) generates credentials that are unique to that instance:

• a fresh PostgreSQL role password, and
• a fresh administrator password, rotating the default admin account.

SonarQube ships a default admin / admin account that would normally force a password change on first login. This image rotates that password automatically on first boot, so the default admin / admin login does not work on your running instance. No shared or default credentials ship in the image. Retrieve the generated administrator password with:

sudo cat /root/sonarqube-credentials.txt

The file (mode 0600, root only) contains the administrator username (admin) and the per-instance password:

SONARQUBE_USERNAME=admin
SONARQUBE_ADMIN_PASSWORD=<generated-per-instance>

Verifying the service

The three services that back SonarQube should all report active:

systemctl is-active sonarqube postgresql nginx

Expected output:

active
active
active

SonarQube exposes an open health endpoint at /health (served by nginx) that returns HTTP 200 when the platform is healthy:

curl -s http://localhost/health

ok

Confirm the platform status and version through the API — status reports UP once SonarQube and its embedded Elasticsearch have finished starting:

curl -s http://localhost/api/system/status

{"id":"...","version":"10.7.0.96327","status":"UP"}

Confirm the Elasticsearch kernel requirement is applied and persisted:

sysctl vm.max_map_count

vm.max_map_count = 524288

Confirm the SonarQube data and the PostgreSQL datadir are on the dedicated EBS volume:

df -h /var/lib/sonarqube

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1     40G  1.6G   36G   5% /var/lib/sonarqube

Signing in

Browse to your instance and sign in with username admin and the password from /root/sonarqube-credentials.txt:

http://<instance-public-ip>/

After signing in you land on the Projects page. A fresh instance has no projects yet, so SonarQube shows the "create a project" flow.

We strongly recommend changing the administrator password again to one of your own choosing under My Account -> Security after your first sign-in, and creating individual user accounts rather than sharing the admin login.

Running your first analysis

SonarQube analyses code that is pushed to it by a scanner running in your build. The quickest way to try it is the SonarScanner CLI.

1. In the web UI, choose Create Project -> Local project, give it a key (for example my-project), and follow the prompts to generate an analysis token. Keep the token safe — it is shown only once.

2. On a machine that has your source code, download the SonarScanner CLI, then from your project root run:

sonar-scanner \
  -Dsonar.projectKey=my-project \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://<instance-public-ip> \
  -Dsonar.token=<your-analysis-token>

When the analysis finishes, the scanner submits a report and SonarQube processes it. Refresh the project in the web UI to see the result.

For CI pipelines (GitHub Actions, GitLab CI, Jenkins, Azure DevOps), store the token as a secret and use the matching SonarScanner step or plugin — the same server URL and token apply.

Reviewing results

Each project has an Overview with its Quality Gate result (Passed or Failed) and the security, reliability, maintainability, coverage and duplication measures for the analysed code.

The Issues tab lists every bug, code smell and vulnerability SonarQube found, each with its severity, type, estimated effort to fix, and the rule that raised it. You can filter, assign, and change the status of issues from here.

The Quality Gates and Quality Profiles sections (in the top navigation) let you tune the pass/fail standard and the active rule set applied to your projects. The built-in Sonar way Quality Gate and profiles are enabled by default.

Enabling HTTPS

For production use, put SonarQube behind HTTPS. The image already runs nginx on port 80, so the simplest route is a Let's Encrypt certificate with Certbot. Point a DNS record at your instance's public IP first, then:

sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

Certbot obtains a certificate, rewrites the nginx server block to serve HTTPS on port 443, and sets up automatic renewal. Open port 443 in your EC2 security group. After enabling HTTPS, update the Server base URL under Administration -> General to your https:// address so generated links use it.

Managing the service

SonarQube, PostgreSQL and nginx are ordinary systemd services:

systemctl status sonarqube --no-pager

Restart SonarQube after a configuration change:

sudo systemctl restart sonarqube

SonarQube's configuration is in /opt/sonarqube/conf/sonar.properties; its logs are in /opt/sonarqube/logs/ (sonar.log, web.log, ce.log, es.log). PostgreSQL's datadir is on the dedicated EBS volume under /var/lib/sonarqube/postgresql.

Backups

Two things to back up: the PostgreSQL database (all projects, issues, measures and users) and, if you added plugins, the extensions directory. Both live on the /var/lib/sonarqube EBS volume. A simple database dump:

sudo -u postgres pg_dump sonarqube > sonarqube-backup.sql

For a point-in-time backup of the whole data tier, take an EBS snapshot of the /var/lib/sonarqube volume from the EC2 console. Stop SonarQube first for a consistent snapshot.

Support

This AMI includes 24/7 technical support from cloudimg engineers by email and live chat. Support covers SonarQube deployment, upgrades, PostgreSQL database administration, CI integration, Quality Gate and security-rule configuration, HTTPS setup and performance tuning. Critical issues receive a one-hour average response time.

SonarQube, SonarSource and all related marks are trademarks of their respective holders. Use of them here is for identification only and does not imply affiliation or endorsement.