Installation Prerequisites, Database Planning, and First Server: Configuration, Design Patterns, and Trade-Offs

1. Start with operating requirements, not the easiest command

A Docker one-liner and a ZIP extraction can both produce a local SonarQube UI, but they do not answer production questions: who owns the process, where durable state lives, how search I/O behaves, how secrets are injected, how upgrades are performed, or how traffic is authenticated and encrypted.

Design from required state and trust boundaries first. Packaging comes later.

2. ZIP/service versus container path

Chapter 04 will teach container mechanics in depth. Here the design lesson is that packaging changes process/file delivery but not the fundamental database, search, host, identity, and trust requirements.

3. Evaluation database versus supported production database

H2 optimizes the first five minutes of a lab. PostgreSQL/SQL Server/Oracle support a durable production lifecycle. The choice should follow recovery, concurrency, availability, vendor operations, and supported-version requirements—not “which one started with zero configuration.”

At this authoring date, current Community Build documentation lists PostgreSQL 14–18, SQL Server 2017/2019/2022, and Oracle 19C/21C/23ai family support. Re-check this table against the exact SonarQube release before every real deployment.

4. Least-privilege service identity

The SonarQube process needs enough authority to read its software and write its configured data/log/temp directories. It does not need root as its normal Unix identity. A dedicated account improves auditability and makes permission failures visible during deployment instead of being hidden by superuser access.

On Windows, the same principle applies to a service account: use the minimum filesystem, service-logon, network, and database rights required by the documented deployment.

5. Search storage and filesystem design

SonarQube’s embedded search is I/O-sensitive. Current host guidance specifically warns against remote-mounted storage such as NFS/SMB/NAS for the search data path. Fast local/block storage and sufficient free space reduce latency variance and search failure risk.

For ZIP installs, production guidance also recommends keeping data and temp outside the versioned installation directory. That makes upgrades cleaner and makes it explicit which directories are mutable state versus replaceable software.

# Illustrative production-shaped paths
sonar.path.data=/var/sonarqube/data
sonar.path.temp=/var/sonarqube/temp

6. Local bind versus reverse-proxied production endpoint

A local lab at 127.0.0.1:9000 has a small trust boundary. A production endpoint normally introduces DNS, reverse proxy/ingress, TLS, forwarded headers, firewall rules, authentication, and monitoring. Those are separate layers; exposing :9000 directly to broad networks because “it works” bypasses the opportunity to design them.

Do not disable TLS verification to solve certificate problems. Diagnose certificate trust, proxy forwarding, and endpoint identity at their owning layers. Deeper proxy/TLS administration belongs to later chapters.

7. Worked decision matrix

8. Rollback means state compatibility, not “put the old ZIP back”

SonarQube upgrades can migrate database state. Therefore the presence of an older ZIP or image does not prove you have a supported rollback. A real rollback plan starts with tested database backup/restore, exact release compatibility, plugins, Java/database versions, and documented update paths.

For a first installation, record enough to recreate the service from nothing: binary/image identity, JDK, host limits, database version and schema owner, paths, service identity, network path, plugins, and configuration. This turns installation into infrastructure evidence rather than workstation folklore.

9. Why this matters in DevOps

The deployment pattern determines who can recover, upgrade, audit, and scale the service. A “working” server with undocumented database state, root execution, mutable network shares, floating images, or direct public exposure creates operational debt before the first repository is analyzed. Good platform engineering makes every boundary visible and reviewable.

Knowledge check

Official references and version notes

• SonarQube Community Build downloads — current Community Build release identity and download entry point.
• Server host requirements — current JDK, OS, CPU/RAM/disk, and embedded-search requirements.
• Installing database — supported databases and the H2 non-production boundary.
• Linux pre-installation — current vm.max_map_count, file-descriptor, thread, and seccomp prerequisites.
• ZIP installation overview — required installation sequence and initial login baseline.
• Basic ZIP installation — database, data/temp paths, web connection, and healthy startup guidance.
• Starting and stopping from ZIP — current platform start/stop commands and graceful-stop semantics.
• Running as a service — Windows service and Linux service-account guidance.