SonarQube review: pricing, alternatives and setup

Analysis starts with a scanner running in your build: the SonarScanner CLI, the Maven or Gradle scanner, the .NET scanner, or the official GitHub Action. The scanner analyses the code where the build runs and sends a report to SonarQube Server or SonarQube Cloud, which processes it in a background task and then computes the quality gate. That split explains two common surprises. A pipeline step can succeed before the gate result exists, so failing the build needs a separate wait. And SonarQube never runs your tests: coverage comes from reports your test tools generate, such as LCOV for JavaScript and TypeScript, which the scanner imports.

Every project has a new code definition: changes since the previous version, within a number of days, since a specific analysis, or relative to a reference branch. For pull requests, new code is whatever differs from the target branch. The built-in Sonar way quality gate applies four conditions to new code only: no new issues, all new security hotspots reviewed, at least 80% coverage, and at most 3% duplication. A fudge factor ignores coverage and duplication conditions until there are at least 20 new lines, so tiny changes are not blocked. Because changed code usually touches old code, the whole codebase improves over time without a clean-up project.

Rules are grouped per language into quality profiles, with Sonar way as the default, and each project uses one profile per language. How issues are classified depends on the instance mode. In Multi-Quality Rule mode, the default for new SonarQube Server instances, a rule can affect several software qualities, security, reliability and maintainability, with a separate severity for each. Standard Experience keeps the older single type per rule: bug, vulnerability or code smell. Instances upgraded from old versions may still run Standard Experience. Sonar is also phasing out security hotspots in favour of security issues, so profiles and gates that refer to hotspots will change over the coming releases.

The Community Build is free and open source under LGPL 3.0, released monthly, covering more than 20 languages including Terraform, Kubernetes and Docker files, with analysis of each project’s main branch. Developer Edition adds branch and pull request analysis, more languages including C, C++, Objective-C, Swift, ABAP, T-SQL and PL/SQL, and injection vulnerability detection. Enterprise Edition adds languages such as Apex and COBOL, custom security configuration and portfolios, and is the edition Sonar’s documentation lists for advanced security analysis. Data Center Edition adds high availability and horizontal scaling. SonarQube Cloud offers the same analysis as a managed service, with Free, Team and Enterprise plans. The edition you buy largely decides which workflow is possible.

Start with the built-in Sonar way profile and gate, and resist enabling every available rule: the extra rules mostly add noise, and a first dashboard with thousands of issues teaches the team to ignore it. Choose a new code definition that matches how you release, usually previous version for versioned products or a reference branch for trunk-based teams, so the gate judges only what changed. Review findings on old code as a backlog, not as a blocker. If a rule produces findings the team consistently rejects, change the profile by extending Sonar way and deactivating it, with the reason recorded, rather than marking hundreds of issues as accepted one by one. Revisit the profile each quarter as the codebase improves.

The official sonarqube-scan-action runs the scanner for SonarQube Server and SonarQube Cloud; the older sonarcloud-github-action is deprecated in its favour. Check out with full history so blame and new code detection work. The scan action does not wait for the gate, so add the official quality gate check action, which polls for the result and fails the job when the gate fails; set its timeout so a slow server does not burn runner minutes. Maven, Gradle and .NET projects should use their own scanners rather than this action.

Tell the scanner which files are tests with sonar.tests and sonar.test.inclusions, and keep them out of sonar.sources. Test code is then excluded from coverage calculations and from the lines of code that commercial licences count. Getting this wrong has visible effects: test files listed as sources drag coverage down, because nothing covers the tests themselves, and inflate the line count you pay for. For end-to-end suites in a separate repository, analyse them as their own project with their own profile, since a Playwright or Selenium framework has different risks from the application it tests.

The fastest feedback comes from the two places outside the main pipeline. With Developer Edition or SonarQube Cloud, configure the DevOps platform integration so pull requests are analysed against their target branch and decorated with new issues and the gate status, then make the gate a required check. In the editor, install SonarQube for IDE and bind it to the project in connected mode, so local analysis uses the project’s own profile and hides issues already accepted on the server. Developers then fix most issues before pushing, and the pull request gate becomes confirmation rather than a surprise.

Run SonarQube Server or Community Build from the official Docker images or the Helm chart; Sonar now describes the ZIP installation as deprecated. Use an external PostgreSQL database, version 15 or later from 2026.5, and never point two instances at the same schema, which Sonar warns will corrupt data. Choose a track: the Community Build releases monthly, while SonarQube Server offers Long-Term Active releases, currently 2026.5, which succeeded 2026.1. Upgrades between LTAs must pass through each one in turn. Back up the database before upgrading, and read the upgrade notes, since 2026.5 also removed Node.js 20 support for JavaScript and TypeScript analysis.