SonarQube Community Edition self-hosted versus SonarCloud for low-traffic private repositories

Direct answer

For low-traffic private repositories, neither option is automatically cheaper. Self-hosted SonarQube Community Edition has no license fee, but it still requires a virtual machine, PostgreSQL, search infrastructure, storage, backups, and patching, with baseline resource use even when no scan is running. SonarCloud removes that operational work, but its free tier targets open-source projects and private repositories are generally billed by analyzed lines of code. Choose Community Edition only if you can host it on existing or already-paid capacity; otherwise compare SonarCloud's current private-project quote against the full monthly cost of a self-hosted instance.

Confirmed facts

• SonarQube Community Edition supports private repositories without a per-repository license fee.
• Community Edition is self-managed: you provision compute, PostgreSQL, search, storage, backups, and updates.
• SonarCloud handles infrastructure, scaling, and patching, and private repositories typically require a paid subscription based on lines of code.
• Community Edition keeps code and results on infrastructure you control; SonarCloud processes them in SonarSource-managed regions.
• SonarQube resource requirements, including minimum RAM, are version-dependent and should be checked against the LTS documentation.

Likely explanation

Intermittent scanning makes fixed costs more important than per-scan costs. A self-hosted instance costs roughly the same per month whether it runs one analysis or many, so underutilization is the main risk. SonarCloud shifts that fixed cost into a subscription tied to repository size, which can favor very small codebases but becomes more expensive as lines of code grow. For a fixed scan window, SonarCloud's managed capacity is easier to rely on; with Community Edition you must size the instance for peak analysis load, not average load.

Steps for this case

1. Measure the repository's analyzed lines of code and typical weekly scan count.
2. Obtain current SonarCloud private-repository pricing for that volume; do not rely on remembered or outdated tiers.
3. Price a self-hosted instance at the documented SonarQube LTS minimums, including VM, database, search, storage, backups, and administrative time.
4. Run one sample analysis on a test instance at documented minimum resources to verify stability and scan duration.
5. Compare the monthly totals and factor in data-residency requirements before deciding.

Missing diagnostic detail

Provide the repository's analyzed lines of code and required scan window. Without those values, the break-even point and instance size cannot be estimated, so the recommendation remains conditional.