> 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-cli/administration/mdm-deployment.md).

# MDM deployment

Deploy the SonarQube CLI to managed devices without user interaction using mobile device management (MDM) scripts that run as `root` or `SYSTEM`. The scripts are MDM-agnostic and work with JumpCloud, Microsoft Intune, Jamf, Workspace ONE, or any system that can execute shell or PowerShell commands as a privileged user.

## Prerequisites

Managed devices need outbound HTTPS access to `binaries.sonarsource.com`. This covers both the deployment scripts, which download the SonarQube CLI binary, and the SonarQube CLI itself, which downloads sub-tools on first use.

## Scripts

Reference scripts are in [SonarSource/sonarqube-cli](https://github.com/SonarSource/sonarqube-cli/tree/master/mdm-scripts/direct-sonar-cdn), organized into a subfolder per operating system. macOS and Linux share the same Bash scripts; the Linux scripts detect x86-64 vs. arm64 automatically via `uname -m`.

These scripts are a working example, not a supported product. They run as-is on a machine with outbound HTTPS access to `binaries.sonarsource.com`; consider the scripts as a starting point rather than a one-size-fits-all solution. If your organization's requirements or your MDM system's specifications call for changes, have the specialists who manage your MDM deployment adapt the scripts accordingly.

Version pinning and staged rollouts don't require editing the scripts; set your [environment variables](#configuration) instead. The `{{SONARQUBE_CLI_APPROVED_VERSION}}`-style placeholders near the top of each script are JumpCloud's Custom Variable injection syntax; if you're deploying through Intune, Jamf, Workspace ONE, or another MDM system, replace that injection mechanism with however your platform passes variables into a script. The variable names and the rest of the script's logic stay the same. Avoid changing the artifact URL, install paths, or binary names because they need to match where the SonarQube CLI is actually published.

## Lifecycle operations

Each [platform folder](https://github.com/SonarSource/sonarqube-cli/tree/master/mdm-scripts/direct-sonar-cdn) has the same set of scripts.

Run install and update on a recurring schedule (for example, daily) to keep managed devices current without manual intervention. Run rollback and remove on demand for exceptional cases: reverting a bad release or decommissioning a device.

| Operation | What it does                                                                                                                               |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Install   | Installs the latest version, and replaces any existing standalone install on the machine with a symlink to the MDM binary.                 |
| Update    | Downloads the latest version. Skips if the installed version already matches; replaces it otherwise, or when `SONARQUBE_CLI_FORCE` is set. |
| Rollback  | Downloads and installs the version specified in `SONARQUBE_CLI_ROLLBACK_VERSION`, replacing any existing binary.                           |
| Remove    | Removes the SonarQube CLI binary from every location on the machine where it's found.                                                      |

## Install paths

The binary installs to a system-wide location accessible to all users on the machine.

| Platform        | Binary path                                    | PATH                                                                                                             |
| --------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| macOS and Linux | `/usr/local/bin/sonar`                         | No change needed. `/usr/local/bin` is in the system `PATH` by default on macOS and standard Linux distributions. |
| Windows         | `C:\Program Files\sonarqube-cli\bin\sonar.exe` | The install scripts add the directory to the machine `PATH` so every user picks it up.                           |

## Configuration

Set these as environment variables through your MDM system.

| Variable                         | Used by         | Default                              | When to use                                                                                                                                      |
| -------------------------------- | --------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `SONARQUBE_CLI_APPROVED_VERSION` | Install, update | Latest version from `stable.version` | Pin installs and updates to a specific version instead of always taking the latest. Must be a numeric version string (for example `1.6.0.4255`). |
| `SONARQUBE_CLI_FORCE`            | Update          | Not set                              | Set to `true` to replace the binary even when it's already at the target version, for example to recover a corrupted install.                    |
| `SONARQUBE_CLI_ROLLBACK_VERSION` | Rollback        | None (required)                      | Full build version to roll back to, for example `1.2.0.3278`. Must be a numeric version string.                                                  |

The scripts always download from `binaries.sonarsource.com`; there's no option to point them at an internal mirror.

## Version management

The install and update scripts determine the target version by reading a single file from the artifact server: `https://binaries.sonarsource.com/Distribution/sonarqube-cli/stable.version`. This file contains one line, the full build version string, for example `1.2.0.3278`. Scripts fetch this file at runtime, so the next scheduled run picks up any version change automatically.

Set `SONARQUBE_CLI_APPROVED_VERSION` to pin installs and updates to a specific build, bypassing the `stable.version` file. Use this to certify a version internally before it reaches managed devices, or to adopt a LATEST-1 or LATEST-2 policy instead of always pulling the newest build. Scripts still download from `binaries.sonarsource.com` and verify the SHA256 checksum; only the version selection changes. To move to a newer approved version, update the variable's value and let the next scheduled run pick it up.

The rollback script bypasses `stable.version` entirely and uses `SONARQUBE_CLI_ROLLBACK_VERSION` directly.

> **Important:** Always publish the binary before updating `stable.version`. Scripts attempt to download immediately after reading the version file.

## Integrity verification

Every download is verified against a SHA256 checksum published alongside the binary on the artifact server. If the checksums don't match, the script exits with an error and leaves the existing binary untouched.

## Sub-tool downloads

The MDM scripts install, update, roll back, and remove the main SonarQube CLI binary on each managed device. The SonarQube CLI itself downloads additional sub-tools (`sonar-secrets`, `sca-scanner-cli`, `sonar-context-augmentation`) on demand from `binaries.sonarsource.com` the first time a user runs a command that requires them. No MDM configuration is needed for this; outbound access to `binaries.sonarsource.com` is sufficient.

Sub-tools are cached locally at `~/.sonar/sonarqube-cli/bin/` (macOS and Linux) or `%USERPROFILE%\.sonar\sonarqube-cli\bin\` (Windows) and reused on subsequent runs.

## After installation

After the install script runs, `sonar` is available in every new terminal session. On Windows, new terminal windows pick up the `PATH` change automatically with no restart or sign-out required.

Each developer must run `sonar auth login` once to authenticate with their SonarQube Cloud or SonarQube Server instance before they can use the SonarQube CLI. This is a one-time step per machine.

From each project, run `sonar integrate` to set up integrations with your AI coding agent or Git. See [Commands reference](/sonarqube-cli/using-sonarqube-cli/commands.md#sonar-integrate) for the available subcommands.

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

* [Advanced network configuration](/sonarqube-cli/administration/advanced-network-configuration.md)
* [Updating the CLI](/sonarqube-cli/administration/self-update.md)
* [Uninstalling](/sonarqube-cli/administration/uninstall.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-cli/administration/mdm-deployment.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.