> 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/system-properties/configuration-methods.md).

# Configuration methods

The system properties are the properties used by SonarQube Server 2026.5 at startup and not stored in the database. They can be configured using different methods.

SonarQube utilizes system properties during startup, which are not stored in the database. These properties can be configured through:

* `sonar.properties` configuration file\
  You can define system properties through sonar properties (`sonar.*`) stored in the `sonar.properties` file.
* Environment variables\
  You can define system properties through environment variables.
* Command line\
  You can define system properties in the command line used to start SonarQube.

The properties set through the command line have precedence over the environment variables which have precedence over the `sonar.properties` file.

See the list of sonar properties considered as system properties, along with the corresponding environment variables:

* [List of properties common to all editions](/sonarqube-server/server-installation/system-properties/common-properties.md)
* [List of DCE-specific properties](/sonarqube-server/server-installation/system-properties/dce-specific.md)

{% hint style="info" %}
Once you have set or changed system properties, you must restart SonarQube to apply the changes.
{% endhint %}

## In a ZIP installation (deprecated) <a href="#zip" id="zip"></a>

The preferred method to manage system properties in a ZIP installation is to edit the `sonar.properties` file which is stored in `<sonarqubeHome>/conf/sonar.properties` where `<sonarqubeHome>` is the location where the SonarQube Server distribution has been unzipped.

To encrypt sensitive system properties stored in `sonar.properties`, see [Sensitive settings](/sonarqube-server/instance-administration/security/encrypting-settings.md).

{% hint style="info" %}
Use only properties documented in the `sonar.properties` file. For any other property, SonarQube Server logs a warning at startup. The property is not ignored, but you cannot manage it from the UI or the Web API, and it may have no effect.
{% endhint %}

## In a Docker installation <a href="#docker" id="docker"></a>

The preferred method to manage system properties in a Docker installation is to use the environment variables.

System properties can also be edited in the `sonar.properties` file which is stored in `<sonarqubeHome>/conf/sonar.properties` where `<sonarqubeHome>` is the installation directory of SonarQube Server within your container. This path is stored in the `SONARQUBE_HOME` environment variable.

## In a Kubernetes installation <a href="#kubernetes" id="kubernetes"></a>

In a Kubernetes installation, a few system properties are set through Helm chart parameters. For example, the Helm chart’s parameter `jdbcOverwrite.jdbcUrl` corresponds to the sonar property `sonar.jdbc.url`.

If you need to set additional system properties, you can set them in the Helm chart through:

* Sonar properties
* Environment variables

In addition, system properties stored in external Secrets or ConfigMaps can be injected into the Helm chart.

### Defining sonar properties <a href="#defining-sonar-properties" id="defining-sonar-properties"></a>

In the SonarQube Helm chart (`values.yaml` file), use the `sonarProperties` parameter as illustrated below. This creates a custom `sonar.properties` file within the Kubernetes cluster.

```yaml
sonarProperties:
   sonar.log.level: DEBUG
   sonar.security.realm: LDAP
   ldap.url: ldaps://organization.com
```

To encrypt sensitive properties stored in the Helm chart, see [Encrypting sensitive data](/sonarqube-server/server-installation/on-kubernetes-or-openshift/encrypting-helm-chart-sensitive-data.md).

{% hint style="info" %}
Only define system properties through `sonarProperties` in the Helm chart. For any other property, SonarQube Server logs a warning at startup, because the parameter creates a `sonar.properties` file. See [#zip](#zip "mention").
{% endhint %}

### Using environment variables <a href="#using-environment-variables" id="using-environment-variables"></a>

In the Helm chart, you can define system properties through environment variables by using `env:`.

### Injecting external Secrets or ConfigMaps <a href="#injecting-external-secrets-or-configmaps" id="injecting-external-secrets-or-configmaps"></a>

In environments where another tool, such as terraform or ansible, is used to provision infrastructure or passwords, configuration may be read, via environment variables, from existing Secrets and ConfigMaps.

To do so, proceed as follows:

1\. Create a `ConfigMap` (or `Secret`) containing key/value pairs, as expected by SonarQube.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: external-sonarqube-opts
data:
  SONAR_JDBC_USERNAME: foo
  SONAR_JDBC_URL: jdbc:postgresql://db.example.com:5432/sonar
```

2\. Set the following in your `values.yaml` (using the key `extraConfig.secrets` to reference Secrets)

```yaml
extraConfig:
  configmaps:
    - external-sonarqube-opts
```

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

* [List of properties common to all editions](/sonarqube-server/server-installation/system-properties/common-properties.md)
* [List of DCE-specific properties](/sonarqube-server/server-installation/system-properties/dce-specific.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/system-properties/configuration-methods.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.