> 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-community-build/analyzing-source-code/scanners/sonarscanner-for-cargo.md).

# SonarScanner for Cargo

The SonarScanner for Cargo provides an easy way to start the analysis of a Rust project with SonarQube Community Build.

{% hint style="info" %}
**1.0.0** *2026-09-11*

* First generally available release. Runs an analysis with cargo sonar-scanner, configured from the \[package.metadata.sonar] table in Cargo.toml.

[**Download**](https://crates.io/crates/cargo-sonar-scanner) [Release notes](https://github.com/SonarSource/sonar-scanner-cargo/compare/0.2.0-70...1.0.0-105)
{% endhint %}

The SonarScanner for Cargo is the scanner to use for Rust projects built with Cargo. It runs as a Cargo subcommand: an analysis is a single `cargo sonar-scanner` call that reads its configuration from your `Cargo.toml`.

## Prerequisites

* Cargo, the Rust package manager. Install it from [rustup.rs](https://rustup.rs/).
* Clippy, the Rust linter that the Rust analyzer runs by default on SonarQube Community Build. Install it with `rustup component add clippy`.
* See [General requirements](/sonarqube-community-build/analyzing-source-code/scanners/scanner-environment/general-requirements.md) for more details.

See [Rust](/sonarqube-community-build/analyzing-source-code/languages/rust.md) for what the Rust analyzer supports.

## Installation

To install the scanner, run:

```bash
cargo install cargo-sonar-scanner
```

To download a prebuilt binary instead of compiling from source, use [`cargo binstall`](https://github.com/cargo-bins/cargo-binstall):

```bash
cargo binstall cargo-sonar-scanner
```

The binary is called `cargo-sonar-scanner`. Once it is on your `PATH`, Cargo resolves `cargo sonar-scanner`. Verify your installation by running:

```bash
cargo sonar-scanner --help
```

## Use

* Add a `[package.metadata.sonar]` table to the `Cargo.toml` in the root directory of the project. Cargo reserves this table for third-party tools and otherwise ignores it, making it the recommended place to identify your project and define the server connection.

```toml
[package.metadata.sonar]

# must be unique in a given SonarQube Community Build instance
project-key = "my_project"

host-url = "https://sonarqube.example.com"

# --- optional properties ---

# defaults to project key
# project-name = "My project"

# defaults to 'not provided'
# project-version = "1.0"

# Cargo build output is not excluded automatically
# exclusions = ["target/**"]
```

{% hint style="warning" %}
Do not put your token in `Cargo.toml`. The file is committed, and for a library crate it is published inside the `.crate` archive on crates.io, where it cannot be deleted. The scanner warns if it finds one. Use `SONAR_TOKEN` instead.
{% endhint %}

* Set the environment variable `SONAR_TOKEN` with a user token. Note that the token can also be set through the command line argument `-Dsonar.token`.
* Run the command `cargo sonar-scanner` from the project base directory to run the analysis.

`sonar.host.url` is required. With nothing set, the scanner resolves to SonarQube Cloud and your server token is rejected there: a missing host URL surfaces as an authentication failure against an unexpected host. Check the endpoint that `--dry-run` reports before chasing the token.

### Property key naming

Bare keys are written in kebab-case and get a `sonar.` prefix; nested tables become dotted segments:

| You write                                                       | It becomes                          |
| --------------------------------------------------------------- | ----------------------------------- |
| `project-key = "x"`                                             | `sonar.projectKey=x`                |
| `exclusions = ["a/**", "b/**"]`                                 | `sonar.exclusions=a/**,b/**`        |
| `verbose = true`                                                | `sonar.verbose=true`                |
| `connect-timeout = 30` under `[package.metadata.sonar.scanner]` | `sonar.scanner.connectTimeout=30`   |
| `host-url = "…"`                                                | `sonar.host.url=…` (the one alias)  |
| `"sonar.cpd.exclusions" = "…"`                                  | `sonar.cpd.exclusions=…` (verbatim) |

Every analysis parameter is accepted, because the name is derived rather than looked up in a list. The exception is `sonar.host.url`, whose real name is dotted where the convention would produce `sonar.hostUrl`. It has an alias instead. Anything the convention cannot express can be written as a quoted, fully qualified parameter name.

For a list of analysis parameters, see [Parameters not settable in the UI](/sonarqube-community-build/analyzing-source-code/analysis-parameters/parameters-not-settable-in-ui.md).

### Analysis scope

Cargo build output is not excluded from the analysis for you. Exclude it explicitly, otherwise `target/` is indexed along with your sources:

```toml
[package.metadata.sonar]
exclusions = ["target/**"]
```

Adjust the pattern if `CARGO_TARGET_DIR` points the build output somewhere else.

### Workspaces

The scanner analyzes the project in the base directory, which defaults to the directory you run it from. It does not walk up to a workspace root: running it from inside a member crate analyzes that member, configured by that member's own `Cargo.toml`.

In a virtual workspace (a root `Cargo.toml` with no `[package]` section), use `[workspace.metadata.sonar]` instead. When one manifest carries both tables, `[package.metadata.sonar]` wins key by key.

To analyze a directory other than the one you run from, set `sonar.projectBaseDir`.

## Alternatives to the Cargo.toml table

If the analysis cannot be configured in `Cargo.toml`, the alternatives are:

* A `sonar-project.properties` file in the base directory, exactly like when you analyze with the [SonarScanner CLI](/sonarqube-community-build/analyzing-source-code/scanners/sonarscanner.md). This is supported to keep a project migrating from the SonarScanner CLI working.
* Parameters specified directly on the command line, prefixed with `-D`. Example:

```bash
cargo sonar-scanner -Dsonar.projectKey=my_project -Dsonar.host.url=https://sonarqube.example.com
```

* Environment variables. Named parameters such as `sonar.token` use `SONAR_TOKEN` and `sonar.host.url` uses `SONAR_HOST_URL`; any `sonar.scanner.*` parameter maps to `SONAR_SCANNER_*`: `sonar.scanner.connectTimeout` becomes `SONAR_SCANNER_CONNECT_TIMEOUT`.

In all cases, `sonar.projectKey` is mandatory and must be defined either in `Cargo.toml`, in the project configuration file, or on the command line.

When the same parameter is set in more than one place, the command line wins, then environment variables, then `Cargo.toml`, then `sonar-project.properties`. Run `cargo sonar-scanner --dry-run` to print the origin of every resolved parameter, which is the quickest way to answer "where did that value come from?".

For more information, see [Configuration overview](/sonarqube-community-build/analyzing-source-code/analysis-parameters/configuration-overview.md).

## Custom certificates

Behind a TLS-intercepting proxy, or against a server with a private certificate authority, point the scanner at a PKCS#12 truststore:

```bash
cargo sonar-scanner -Dsonar.scanner.truststorePath=/path/to/truststore.p12 \
                    -Dsonar.scanner.truststorePassword=<password>
```

Trust is widened, not replaced: a truststore holding only your corporate root does not cut off anything else. If the server asks for a client certificate, supply a keystore holding the private key and its chain with `sonar.scanner.keystorePath` and `sonar.scanner.keystorePassword`.

A truststore at the default path `<sonar.userHome>/ssl/truststore.p12` is read whether or not you set the parameter. Dropping a `truststore.p12` into `~/.sonar/ssl` is enough on its own. The default password is `changeit`, then `sonar`. The same parameters reach the analysis itself: one truststore covers the whole run. See [TLS certificates on client side](/sonarqube-community-build/analyzing-source-code/scanners/scanner-environment/manage-tls-certificates.md) for more details.

## Troubleshooting

#### Checking the resolved configuration

Start by separating configuration from connectivity. The following command resolves the configuration and makes no network request:

```bash
cargo sonar-scanner --dry-run
```

It prints the endpoint, base directory, every resolved parameter, and the origin of each one. Sensitive values are masked. Add `--verbose` to also show the loaded files in the log.

#### Authentication failures

For a rejected token (HTTP 401), generate or select a token for the target shown by `--dry-run`, then set `SONAR_TOKEN` again. A 403 means the token was accepted but cannot run the analysis; check its analysis permissions and the project parameters.

#### Connection failures

Check the resolved host URL with `--dry-run` first. A certificate error behind a corporate TLS-inspecting proxy is a truststore problem: configure one as described in [#custom-certificates](#custom-certificates), rather than disabling certificate verification. Standard proxy environment variables are used unless scanner proxy parameters override them:

```bash
cargo sonar-scanner -Dsonar.scanner.proxyHost=proxy.example.com \
                    -Dsonar.scanner.proxyPort=3128
```

`sonar.scanner.proxyUser` and `sonar.scanner.proxyPassword` configure proxy credentials when they are required. Increase `sonar.scanner.connectTimeout`, `sonar.scanner.socketTimeout`, or `sonar.scanner.responseTimeout` for slow but healthy connections. All values are in seconds.

#### Download failures

The scanner downloads a Java runtime and the analysis engine to `<sonar.userHome>/cache`, where `sonar.userHome` defaults to `~/.sonar`. Incomplete or corrupted downloads are never installed, and a checksum mismatch is retried once. If it still fails, investigate the network, proxy, or TLS interception before clearing the cache. To skip Java provisioning altogether, see [Managing JRE auto-provisioning](/sonarqube-community-build/analyzing-source-code/scanners/scanner-environment/managing-jre-auto-provisioning.md).

## Related pages

* [Rust](/sonarqube-community-build/analyzing-source-code/languages/rust.md)
* [SonarScanner CLI](/sonarqube-community-build/analyzing-source-code/scanners/sonarscanner.md)
* [General requirements](/sonarqube-community-build/analyzing-source-code/scanners/scanner-environment/general-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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sonarsource.com/sonarqube-community-build/analyzing-source-code/scanners/sonarscanner-for-cargo.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.