SonarQube Community on an Offshore VPS

SonarCloud is the SaaS version of SonarQube, and it requires uploading your full source tree to Sonar's servers for analysis. For private repos and proprietary projects, that is a significant trust commitment. Even with SonarCloud's encryption and access controls, the source is sitting on someone else's servers, indexed, and analyzed. Self-hosted SonarQube does the same analysis with the same plugins on a server you own. The Community Edition is free and covers the major languages - Java, JavaScript/TypeScript, Python, Go, C#, PHP, Ruby, Kotlin, and more. The Developer and Enterprise editions add branch analysis, PR decoration, additional languages (C/C++, Swift, ABAP), and security analyzers (taint analysis, hardcoded secret detection). For most teams, Community is enough; for security-sensitive teams, the Developer edition's PR decoration on a self-hosted instance is a strong combination. The other reason to self-host is integration with private git remotes and CI runners. SonarCloud only integrates cleanly with GitHub.com, GitLab.com, Bitbucket Cloud, and Azure DevOps Cloud. Self-hosted SonarQube can integrate with self-hosted Gitea, GitLab CE, Bitbucket Server, or any custom git server through generic webhooks. Combine with self-hosted CI runners and your source code never leaves your offshore infrastructure.

SonarQube needs Java 17, an external database (Postgres is the recommended option since 2024), and Elasticsearch (bundled). The combined RAM footprint is 4 to 6 GB minimum for a small instance with a handful of projects, and 8 to 12 GB for instances scanning dozens of projects with full history. The Elasticsearch process by itself uses 2 GB by default and benefits from being given more if you have it. CPU usage spikes during scans and is otherwise low; 4 vCPU is enough for most teams. Postgres can run on the same VPS for small instances - just install postgresql-15 and create a sonar user and database. For larger setups, run Postgres on a separate VPS to isolate database tuning from the application. Disk consumption is dominated by the database (project history, issues, measures) and grows linearly with the number of analyzed commits. Plan on at least 80 GB SSD for a small instance, 200 GB or more for a busy multi-project setup. The Elasticsearch component requires `vm.max_map_count` set to at least 262144. Edit `/etc/sysctl.conf` and add `vm.max_map_count=262144`, then `sysctl -p`. Without this, SonarQube refuses to start. Also raise the open file descriptor limit for the sonar user to at least 131072 in `/etc/security/limits.conf`.

On Ubuntu 22.04, install Java 17 and Postgres 15: `apt install -y openjdk-17-jre-headless postgresql-15 unzip`. Create the database: `sudo -u postgres psql -c "CREATE USER sonar WITH PASSWORD 'STRONG_PASSWORD';" && sudo -u postgres psql -c "CREATE DATABASE sonarqube OWNER sonar;"`. Download SonarQube Community: `cd /opt && wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-10.4.1.88267.zip && unzip sonarqube-*.zip && mv sonarqube-* sonarqube`. Create a dedicated user: `useradd -r sonar && chown -R sonar:sonar /opt/sonarqube`. Edit `/opt/sonarqube/conf/sonar.properties` and set `sonar.jdbc.username=sonar`, `sonar.jdbc.password=STRONG_PASSWORD`, and `sonar.jdbc.url=jdbc:postgresql://localhost/sonarqube`. Also set `sonar.web.host=127.0.0.1` and `sonar.web.port=9000` to bind to loopback and put TLS in front. Apply the sysctl change for Elasticsearch: `echo 'vm.max_map_count=262144' >> /etc/sysctl.conf && sysctl -p`. Write a systemd unit that runs `/opt/sonarqube/bin/linux-x86-64/sonar.sh start` as the sonar user. Start: `systemctl daemon-reload && systemctl enable --now sonarqube`. First boot takes 1 to 2 minutes (Elasticsearch initialization). Put Caddy or Nginx with TLS in front of port 9000, log in at the resulting URL with admin / admin, then immediately change the password and create a project token to start scanning with sonar-scanner from your CI pipeline.