> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/server-installation/server-components-overview.md).

# Server components

Overview of the Java processes run by SonarQube Server, the SonarQube Server database, and the optional agentic feature components. This page is for SonarQube Server 2026.5.

SonarQube Server runs the following Java processes:

* **Web**: serves the SonarQube Server user interface.
* **Elasticsearch (ES)**: manages an indexed copy of the database.
* **Compute Engine (CE)**: is in charge of processing code analysis reports and saving them in the SonarQube Server database.

In addition, the Java process **Sonar** is used to manage the availability of these processes.

The SonarQube database is used to store the following:

* Metrics and issues for code quality and security generated during code scans.
* The SonarQube Server instance configuration.
* The report job queue that is populated by the Sonarscanner and processed by the Compute Engine.

Both the Web and the CE process ensure data consistency when writing to the ES and SonarQube databases. In case of a disaster recovery of the ES database, it’s the Web process’s responsibility to rebuild the ES indexes.

The following diagram shows these processes and the data they read and write. The optional agentic feature components are outlined in blue, and sandboxed containers have a dashed border.

```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#F1F6FC', 'primaryBorderColor': '#126ED3', 'primaryTextColor': '#0A0A0A', 'lineColor': '#126ED3', 'secondaryColor': '#F4F6F8', 'tertiaryColor': '#F4F6F8', 'clusterBkg': '#F4F6F8', 'clusterBorder': '#D4D4D4', 'edgeLabelBackground': '#FFFFFF'}}}%%
flowchart LR
    subgraph ci["Automated CI pipeline"]
        SCANNER["SonarScanner"]
    end

    USER["User"]

    subgraph server["SonarQube Server, Developer or Enterprise edition"]
        SYSPROPS["System properties"]
        SONAR["Sonar"]
        WEB["Web"]
        ES["Elasticsearch"]
        CE["Compute Engine"]
        ESDB[("ES database")]
    end

    subgraph ai["Agentic feature components, optional"]
        AO["Agent Orchestrator"]
        RT["Agent runtime"]
        PROXY["Egress proxy"]
        VX["Sonar Vortex"]
    end

    SQDB[("SonarQube database")]
    STORE["Shared storage"]
    LLM["Your LLM provider"]

    USER <-->|"Web UI"| WEB
    SCANNER <-->|"Web API"| WEB
    SONAR -->|"Reads at startup"| SYSPROPS
    SONAR -->|"Starts, monitors, stops"| WEB
    SONAR -->|"Starts, monitors, stops"| ES
    SONAR -->|"Starts, monitors, stops"| CE
    WEB -->|"Reads from and writes to ES database"| ES
    CE -->|"Writes to ES database"| ES
    ES <--> ESDB
    WEB -->|"Writes"| SQDB
    CE -->|"Reads and writes"| SQDB
    WEB -->|"Trigger job"| AO
    AO <-->|"Job state"| SQDB
    AO -->|"Dispatches jobs"| RT
    AO <--> STORE
    RT <--> STORE
    RT --> PROXY
    PROXY -->|"Prompts"| LLM
    WEB <-->|"Signed calls, Remediation only"| PROXY
    WEB <-->|"Analysis requests"| VX
    VX <--> STORE

    classDef neutral fill:#FFFFFF,stroke:#D4D4D4,color:#0A0A0A
    classDef external fill:#F4F6F8,stroke:#D4D4D4,color:#0A0A0A
    classDef subject fill:#FFFFFF,stroke:#126ED3,color:#0A0A0A
    classDef sandbox fill:#FFFFFF,stroke:#126ED3,color:#0A0A0A,stroke-dasharray: 5 5
    class SYSPROPS,SONAR,WEB,ES,CE,ESDB,SQDB neutral
    class USER,SCANNER,LLM external
    class AO,VX,PROXY,STORE subject
    class RT sandbox
    style ci fill:#F4F6F8,stroke:#D4D4D4
    style server fill:#F4F6F8,stroke:#D4D4D4
    style ai fill:#F1F6FC,stroke:#126ED3
```

## Agentic feature components <a href="#agentic-feature-components" id="agentic-feature-components"></a>

The agentic features add a further set of components. Unlike the processes described here, they don't run inside SonarQube Server: they're containers that you deploy alongside it, and they have their own release cycle.

| Component          | Role                                                                                                                                                                                                                                  |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agent Orchestrator | Coordinates every agentic job. Reads and writes job state in the SonarQube Server database                                                                                                                                            |
| Agent runtime      | Runs agentic jobs in sandboxed containers. Runtimes are long-lived and scale out with the job queue                                                                                                                                   |
| Egress proxy       | A container that all runtime traffic leaves through, restricting what a job can reach to an allow list. Deployed on both Docker Compose and Kubernetes, where network policies constrain the runtimes so they have no other route out |
| Sonar Vortex       | Analyzes single files on demand for SonarQube Server, including verifying the Remediation Agent's fixes                                                                                                                               |
| Shared storage     | Carries source code snapshots and job results between the Orchestrator and the runtimes. You provision it                                                                                                                             |

These components are optional. SonarQube Server runs without them, they require the Enterprise or Data Center edition, and each agent requires a separate subscription.

{% hint style="info" %}
The agentic feature components are available as containers only. You can still install SonarQube Server itself from the ZIP file, but the components have no ZIP equivalent, because the sandbox needs a container runtime.
{% endhint %}

## Related pages <a href="#related-pages" id="related-pages"></a>

* [Deploying AI agents](/sonarqube-server/server-installation/ai-agents.md)
* [Agentic features architecture](/sonarqube-server/server-installation/reference-architectures/agentic-features-architecture.md)
* [Server host requirements](/sonarqube-server/server-installation/server-host-requirements.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sonarsource.com/sonarqube-server/server-installation/server-components-overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.