SonarQube Cloud vs Server for Android CI: Choose the Operating Model First

When an Android team asks whether to use SonarQube Cloud or SonarQube Server, the tempting answer is a feature checklist. That is usually the wrong place to start.

Both products can sit behind a Gradle-based analysis workflow and enforce code-quality policy. The more durable decision is which operating model fits your repository, network, compliance boundary, and appetite for infrastructure ownership.

Use SonarQube Cloud when a managed SaaS service fits your security policy and you want to minimize platform operations. Use SonarQube Server when analysis must remain inside infrastructure you control, or when your organization is prepared to own the server, database, upgrades, backups, availability, and network configuration.

For Android specifically, keep a second principle in mind: Sonar should complement Android Lint, tests, and coverage rather than replace them. The layers catch different classes of problems.

The Decision in One Table

Question	SonarQube Cloud	SonarQube Server
Who operates the analysis platform?	Sonar	Your team or platform team
Hosting model	SaaS	Self-managed infrastructure
Server and database maintenance	Not your operational burden	Your responsibility
Fit for restricted internal networks	Depends on allowed connectivity	Stronger when analysis must stay inside controlled infrastructure
Fastest path to a pilot	Usually simpler	Requires infrastructure first
Control over deployment topology	Limited to the service model	High
Gradle scanner workflow	Supported	Supported
Best default when no hard hosting constraint exists	Often the simpler starting point	Choose when control justifies operations

This is not a pricing table. Plans and commercial packaging change. Architecture lasts longer than a price screenshot.

Start With the Trust Boundary

The first question is not “which dashboard looks better?” It is:

Where is source analysis allowed to run, and where may analysis results be sent?

SonarQube Cloud is a SaaS code-analysis service. Its scanner typically runs in your build environment and sends analysis results to the cloud service for processing and display.

That can be a clean fit for repositories already built in cloud CI, provided the organization’s security and compliance rules allow the integration.

SonarQube Server changes the boundary. You operate the SonarQube service and connect scanners to that instance. This is useful when repositories, CI runners, and analysis services must stay within a private network or organization-controlled environment.

Do not translate “self-hosted” into “more secure” automatically. Self-hosting gives you more control, but it also gives you more responsibilities. A neglected server, weak access policy, stale version, exposed database, or missing backup plan can erase the benefit of that control.

Android Uses the Same Gradle Analysis Shape

For a typical Android project, the scanner is integrated with Gradle. Sonar’s current Gradle documentation notes that Java analysis, including Android projects, requires compiled bytecode. That detail matters in CI.

A simplified Kotlin DSL setup looks like this:

plugins {
    id("com.android.application")
    kotlin("android")
    id("org.sonarqube") version "<pin-a-reviewed-version>"
}

sonar {
    properties {
        property("sonar.projectKey", providers.gradleProperty("sonarProjectKey").get())
    }
}

Keep credentials out of the repository. Inject the authentication token through the CI secret store, then run the required build tasks before analysis.

A conceptual pipeline might be:

./gradlew clean assembleDebug testDebugUnitTest sonar

The exact task graph depends on modules, variants, generated code, and the scanner version you use. The important part is that the analysis job receives the artifacts it needs rather than assuming source files alone are enough.

This is one reason to keep the Sonar step visible instead of hiding it inside a giant “quality” shell script. When analysis fails, the team should immediately know whether compilation, tests, Android Lint, coverage, or the remote quality gate caused the failure.

Do Not Replace Android Lint With Sonar

SonarQube and Android Lint overlap in the broad category of static analysis, but they are not interchangeable.

Android Lint understands Android-specific APIs, resources, manifests, SDK behavior, and platform conventions. A Sonar quality gate gives you a centralized policy layer across code quality and security analysis, plus pull-request and CI integration.

A practical pipeline keeps both:

compile
  -> unit tests
  -> Android Lint
  -> Kotlin/static rules
  -> coverage report
  -> Sonar analysis
  -> quality gate
  -> package or release

If you are still designing the earlier layers, the RayLabs guide to Android static analysis with Lint and Detekt explains why platform checks and Kotlin rules should remain independently diagnosable. Coverage should follow the same evidence-first approach described in Android code coverage in CI.

Sonar becomes most useful when it aggregates a policy that the team is actually willing to enforce. Adding another dashboard without deciding what blocks a merge only creates another place to ignore warnings.

Choose Cloud When Operations Are the Bigger Cost

SonarQube Cloud is the stronger default when all of these are true:

• your organization permits a SaaS analysis service;
• CI runners can reach the service reliably;
• you want a fast pilot without operating another stateful platform;
• the team would rather spend engineering time on product delivery than Sonar infrastructure;
• the service’s supported integrations and controls satisfy your governance needs.

The hidden benefit is not merely “no server.” It is avoiding a new operational lifecycle.

With a managed service, you do not need to design the Sonar server’s database topology, upgrade procedure, storage persistence, reverse proxy, monitoring, backup policy, and recovery process just to start evaluating code quality.

That makes Cloud a sensible baseline for small and medium teams without a platform group, assuming the trust boundary is acceptable.

Choose Server When Control Is a Requirement, Not a Preference

SonarQube Server makes sense when infrastructure control solves a real constraint.

Typical reasons include:

• CI and repositories live in a network that cannot send analysis to an external SaaS endpoint;
• compliance policy requires organization-controlled hosting;
• platform engineering already operates stateful internal services;
• you need network placement or deployment topology that a SaaS product cannot provide;
• the organization has a documented backup, upgrade, observability, and incident-response model for the service.

Sonar’s installation documentation makes the operational difference explicit: Server requires installation and setup of the server environment and database, followed by scanner configuration.

That means “we can run it in Docker” is not a production plan.

A production decision should answer:

1. Who owns upgrades?
2. Where is the database?
3. How are backups restored and tested?
4. How is the service monitored?
5. What happens when analysis is unavailable during a release?
6. How are tokens rotated?
7. Which CI networks may reach the service?
8. Who owns rule and quality-gate changes?

If those questions have no owner, the team has not chosen SonarQube Server. It has chosen future maintenance debt.

Avoid Coupling Release Availability to a Fragile Gate

A quality gate can protect the main branch, but a remote dependency can also become a delivery bottleneck.

Decide what happens if Sonar itself is unavailable.

For pull requests, failing closed may be reasonable: if the required analysis cannot complete, do not merge yet.

For an emergency production hotfix, the policy may need a controlled override with audit evidence rather than an improvised bypass. The exact policy depends on the risk model, but it should exist before the outage.

Also separate two failures:

scanner failed to execute

and:

scanner succeeded, quality gate failed

The first is an infrastructure or integration problem. The second is a code-policy result. Treating them as the same red CI box makes incident diagnosis slower.

Run a Small Pilot Before Standardizing

Do not migrate every Android repository on day one.

Pick one representative project with:

• multiple modules;
• unit tests;
• Android Lint;
• a real CI pipeline;
• at least one pull-request workflow;
• enough technical debt to make the analysis meaningful.

Then evaluate the workflow rather than the screenshot.

Measure whether developers can answer these questions quickly:

• Why did the gate fail?
• Can the issue be reproduced locally?
• Is the rule actionable?
• Does analysis time fit the feedback loop?
• Are generated sources and variants handled correctly?
• Can a developer find the owning configuration?
• Can the team recover when the service is unavailable?

A successful pilot produces a reusable CI template, a documented quality gate, token-handling rules, and an ownership model.

A Practical Selection Rule

If there is no hard requirement to self-host, start by evaluating SonarQube Cloud. It minimizes infrastructure work and lets the team learn whether centralized analysis improves the development workflow before committing to platform ownership.

If code-analysis data must remain inside organization-controlled infrastructure, or your network architecture makes SaaS unsuitable, evaluate SonarQube Server and include its operational cost in the decision from the beginning.

For Android teams, the product choice is only half the architecture. Keep Android Lint, tests, coverage, and compilation as explicit gates. Feed Sonar the build evidence it requires. Make failures diagnosable. Pin reviewed tool versions. Keep credentials in CI secrets. Document what happens when the analysis service is unavailable.

The best Sonar setup is not the one with the most rules. It is the one whose trust boundary, operational ownership, and quality policy your team can sustain for years.