SonarQube Architecture
SonarQube looks like a single website, yet four cooperating parts work behind every page. Knowing these parts helps you install the tool correctly, fix slow analysis, and plan hardware for a growing team.
The Restaurant Picture
Imagine a busy restaurant. A waiter takes your order, a kitchen cooks the meal, an index card tells the cook where each ingredient sits, and a storeroom keeps everything long term. SonarQube follows the same pattern.
- Web Server works like the waiter. It shows pages and answers your clicks.
- Compute Engine works like the kitchen. It processes each analysis report.
- Search Server works like the index card. It finds issues in milliseconds.
- Database works like the storeroom. It keeps every result for the long term.
The Big Picture
Developer / CI Server
┌──────────────────┐
│ SonarScanner │ reads code, builds a report
└────────┬─────────┘
│ sends report
▼
┌──────────────────────────── SonarQube Server ───────────────────────────┐
│ │
│ ┌────────────┐ queue ┌────────────────┐ index ┌─────────────┐ │
│ │ Web Server │ ────────► │ Compute Engine │ ────────► │ Search │ │
│ │ (port 9000)│ │ (background) │ │ Server │ │
│ └─────┬──────┘ └───────┬────────┘ └─────────────┘ │
│ │ read │ write │
└────────┼──────────────────────────┼─────────────────────────────────────┘
▼ ▼
┌──────────────────────────────┐
│ Database │
└──────────────────────────────┘
Core Components
Web Server
The web server hosts the dashboard, the web API, and the login system. Every browser request and every scanner upload lands here first. The server listens on port 9000 by default.
Compute Engine
The Compute Engine runs in the background and handles one analysis report at a time per worker. It calculates metrics, applies the quality gate, and stores the final numbers. A long queue on the Background Tasks page signals that this component needs more memory or more workers.
Search Server
SonarQube bundles Elasticsearch as its search layer. Searching thousands of issues across many projects feels instant because of this index. The index is a copy of database data, so SonarQube rebuilds it automatically when it goes missing.
Database
The database holds the permanent record: projects, rules, issues, users, and history. Production setups use PostgreSQL on a separate, backed-up machine. The built-in H2 database suits quick personal trials only.
Scanners
Scanners live outside the server. A scanner runs on a developer laptop or a build machine, reads your source files, and produces an analysis report. The report travels to the server, where the Compute Engine takes over. Scanners exist for the command line, Maven, Gradle, .NET, Jenkins, and other build tools.
Life of One Analysis
- A developer pushes code, and the build server starts a scanner.
- The scanner checks files against the active quality profile rules.
- The scanner uploads the report to the web server.
- The web server places the report in the Compute Engine queue.
- The Compute Engine calculates metrics, finds new issues, and evaluates the quality gate.
- The Compute Engine saves results in the database and refreshes the search index.
- The dashboard shows the updated results.
Separate Processes, Separate Memory
The web server, the Compute Engine, and the search server each run as their own Java process. Each process has its own memory limit in the configuration file. A busy team can raise the Compute Engine limit without touching the others, which keeps tuning simple and targeted.
Planning Tips
- Place the database on fast storage with regular backups.
- Give the search server a solid-state disk for quick index reads.
- Keep scanners on build machines, never on the SonarQube server.
- Watch the Background Tasks page to spot a growing queue early.
- Open port 9000 to developers and build servers only.
Quick Recap
A scanner creates the report, the web server receives it, the Compute Engine processes it, the database stores it, and the search server makes it fast to browse. Every installation, upgrade, and tuning task maps to one of these five parts.
