Category: Development
Managed SonarQube: code quality and security in your pipeline
Static code analysis in every pipeline, with a server that does not fall over for lack of memory, a database with backups and upgrades that follow the official path.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Community Build: LGPLv3. Developer and Enterprise: commercial
In short
SonarQube is a static analysis platform that checks code for bugs, vulnerabilities and technical debt before it reaches production. We install it in your account on PostgreSQL, tune the system for its internal Elasticsearch, connect it to your GitLab CI or other continuous integration and take care of backups and upgrades.
What do we take care of?
SonarQube tends to be installed on a Friday as a trial and stay that way, with the stock H2 database, the admin user with its initial password and a pipeline nobody looks at. Static code analysis is only useful if the server always responds and the quality gate has consequences. This is what we maintain:
Web server
The interface, the API the scanners use and sign-in, behind a proxy with HTTPS.
Compute engine
Processes the reports sent by the pipelines in a queue; we make sure the queue does not pile up.
PostgreSQL
Projects, rules, history and users. It is the only thing that needs backing up to recover the server.
Internal Elasticsearch
System limits, memory and fast disk for the index, which rebuilds itself if needed.
Continuous integration
Scanner, tokens and quality gate in every pipeline, with reusable templates.
Rules
Quality profiles per language, agreed with the team and versioned.
What architecture do we recommend?
For the vast majority of teams, a single well-sized node. High availability with several nodes only exists in Data Center Edition and is rarely worth it for a small team.
Pipeline
The scanner runs on your CI runner, analyses the code and sends the report to the server.
SonarQube server
Receives the report, processes it in its compute engine and updates the search index.
PostgreSQL
Off the server if the provider offers it as a managed service, with low latency between the two.
Quality gate
The pipeline checks the result and stops if the new code does not pass.
The scanner does not run on the server: it uses CPU on your runners. That is why we size both together and, if analyses are slow, we look at the runners first.
What problems do we find in a self-hosted SonarQube?
- H2 database in production: the stock one is for testing and has no upgrade path.
- Server that will not start after a reboot: vm.max_map_count was set by hand and did not survive the reboot.
- Container running as root: Elasticsearch refuses to start that way.
- A decorative quality gate: the analysis runs, but the pipeline carries on even if it fails.
- Personal tokens in the CI: if that person leaves and their user is deleted, every pipeline stops analysing.
- Upgrades that skip steps: someone tries to jump from an old version to the latest and the database migration stops.
How do we handle backups and upgrades?
What needs keeping is in PostgreSQL: projects, history, rules and configuration. The Elasticsearch index is regenerated from the database, so we do not back it up. We take a daily backup of the database off the server, keep the configuration and plugins separately, and every so often bring up a test SonarQube from the backup to check that the projects appear and that a new analysis is processed.
In the paid editions we follow the official upgrade path between LTA versions, with a backup before each jump and a test on a replica of your database, because the schema migration can take a while on instances with a lot of history. Community Build has no LTA and releases often; we keep it up to date so that jumps do not pile up. In both cases we check that third-party plugins are compatible before touching anything.
How do we protect the server?
SonarQube holds a very detailed description of your code’s weak points, so we do not treat it as a minor tool. We change the initial admin account, connect sign-in to your GitLab or your identity provider, use project or analysis tokens instead of personal tokens and restrict who can see each project. If there is no need for access from outside, the server stays on the internal network only or behind the VPN, reachable by the runners.
How do we roll it out without slowing the team down?
We do not switch on a blocking quality gate on day one over old code, because everything would fail. We start by measuring, apply the gate only to new code and we tighten it once the team is used to it. If you already have an old SonarQube on H2, we migrate the projects to a fresh installation on PostgreSQL and export the rule profiles to keep them.
It fits with the work on CI/CD pipelines and infrastructure as code and, if you are looking for a broader review, with the reliability and security audit.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Cloud server with SonarQube and PostgreSQL run by us on the private network, and backups to Hetzner Object Storage, which is S3-compatible. | Hetzner offers no managed database. We choose a server with plenty of memory, because Elasticsearch is what uses the most. |
| AWS | SonarQube on EC2 or ECS on EC2, with RDS for PostgreSQL and access behind an application load balancer. | On ECS the host needs the vm.max_map_count settings; Fargate does not allow changing them, so we avoid it. |
| Google Cloud | Compute Engine or GKE with Cloud SQL for PostgreSQL. | On GKE we set the kernel parameter on the nodes with an init container or a DaemonSet. |
| Azure | Virtual machine or AKS with Azure Database for PostgreSQL. | Sign-in connects to Microsoft Entra ID over SAML in the editions that include it. |
| DigitalOcean | Droplet with SonarQube and a DigitalOcean managed PostgreSQL database. | Enough for small teams; we size the Droplet's memory before its CPU. |
| OVH | Public Cloud instance with the OVHcloud managed database for PostgreSQL. | |
| Own server | SonarQube and PostgreSQL on a virtual machine or in containers on your servers. | The CI runners need to reach the server; if everything is internal, there is no need to publish it on the internet. |
What is included
- SonarQube in your cloud account or on your server, in your company's name, with the configuration in your repository.
- PostgreSQL as the database, never the built-in H2, with daily backups and a test restore.
- System limits and memory tuned for the internal Elasticsearch, persistent across reboots.
- Integration with GitLab CI, GitHub Actions, Jenkins or another CI, with per-project tokens and a quality gate that blocks the pipeline.
- Sign-in with your GitLab, your identity provider or SAML, depending on the edition.
- Quality profiles and quality gates agreed with the team, instead of unreviewed defaults.
- Upgrades following the official path between LTA versions, tested first on a copy.
- Alerts for server down, a stuck analysis queue, disk and certificates.
Frequently asked questions
Is SonarQube Community Build enough or do we need a paid edition?
To get started, it is often enough. Community Build is free and analyses the main branch for the most common languages. If you want to analyse branches and see the results inside each merge request, or you need languages such as C or C++, you need Developer Edition or higher. You take out that licence with SonarSource, in your company's name; we apply it and run the server.
How does SonarQube integrate with GitLab CI?
We add an analysis job to the pipeline with the right scanner, a per-project token stored as a protected variable and a wait for the quality gate, so that the pipeline fails if the new code does not pass it. With Developer Edition or higher, the results also appear as comments on the merge request.
Why does SonarQube fail to start or crash while indexing?
Almost always because of its internal Elasticsearch. If the kernel has vm.max_map_count at the default value, 65530, Elasticsearch stops with the error «max virtual memory areas vm.max_map_count [65530] is too low». The official documentation asks for at least 524288, as well as a minimum number of file descriptors and threads. We put it in /etc/sysctl.d so that the value survives reboots.
What is an LTA version and why does it matter?
LTA stands for long-term active: the version SonarSource keeps fixing for the longest. In the paid editions it is the reference for upgrading: you go from LTA to LTA following the official path, without skipping steps. Community Build has no LTA; it is upgraded to the latest version.
Can we move from SonarQube Cloud to our own server?
Yes, but the analysis history does not come with it: projects, profiles and quality gates are set up again, and the history builds up again with the following analyses. We export the rule profiles first so they do not have to be redone by hand.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
- SonarQube Server Docs: Linux pre-installation (system limits)
- SonarQube Server Docs: Determining the update path
Reviewed on