Configuring SonarQube on Your CloudSOE Instance

This guide covers the layout and day-two configuration of the CloudSOE SonarQube image on both AWS and Azure. It assumes you’ve finished one of the getting-started guides (AWS, Azure).

File locations

Services

SonarQube and PostgreSQL are managed by systemd and enabled at boot:

sudo systemctl status sonar postgresql
sudo systemctl restart sonar        # after config changes

The one-time sonarqube-firstboot service only runs until it succeeds once; its marker file stops it re-running.

Database access

SonarQube uses a local PostgreSQL database:

• Database: sonarqube
• User: sonar
• Password: generated at first boot — in /opt/default-sonar-login.txt and in sonar.properties (sonar.jdbc.password)

Connect from the shell:

sudo -u postgres psql sonarqube

If you ever rotate the database password, change it in both PostgreSQL and sonar.properties, then sudo systemctl restart sonar.

Web port and context path

SonarQube listens on port 9000 on all interfaces. To change the port or serve under a path prefix, edit /opt/sonarqube/conf/sonar.properties:

sonar.web.port=9000
#sonar.web.context=/sonarqube

Restart the sonar service and update your security group / NSG rule to match.

Memory settings

Each SonarQube process (web, compute engine, Elasticsearch) defaults to a 512 MB heap. On larger instances you can raise them in sonar.properties:

sonar.web.javaOpts=-Xmx1G -Xms256m
sonar.ce.javaOpts=-Xmx1G -Xms256m
sonar.search.javaOpts=-Xmx1G -Xms1G

Keep the total comfortably below the instance’s RAM — PostgreSQL needs room too.

Kernel and ulimit tuning (already done)

The Elasticsearch requirements that trip up manual SonarQube installs are baked into the image:

• vm.max_map_count=524288 and fs.file-max=131072 via sysctl
• nofile 131072 and nproc 8192 limits for the sonar user
• the systemd unit carries matching LimitNOFILE/LimitNPROC values

No action needed — just don’t undo them.

Putting SonarQube behind HTTPS

SonarQube serves plain HTTP; the vendor-recommended pattern is TLS termination in front of it. Options:

• A reverse proxy on the instance — install nginx, proxy 443 → 127.0.0.1:9000, and use Let’s Encrypt via certbot once a domain points at the instance.
• A cloud load balancer — ALB with an ACM certificate on AWS, Application Gateway on Azure, forwarding to port 9000.

Either way, once TLS is in front, restrict direct access to port 9000 in your security group / NSG.

Next steps

• Tips & tricks — backups, CI integration, performance and troubleshooting