MDM deployment
Deploy SonarQube CLI to enterprise-managed devices using mobile device management (MDM) tools. Covers install, update, rollback, and remove with JumpCloud, Intune, Jamf, or Workspace ONE.
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, 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 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 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.
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.
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.
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.5.0.4123).
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 sonar integrate for the available subcommands.
Related pages
Last updated
Was this helpful?