Deploy and Host SonarQube Community on Railway

SonarQube is the self-hosted static analysis server that scans your code for bugs, security vulnerabilities, code smells and duplication, tracks the result over time, and fails your CI build when quality drops below a gate you define. This template runs the Community edition on Railway with PostgreSQL attached, persistent storage, and an administrator login that is not the one printed in the manual.

About Hosting SonarQube Community

SonarQube is a Java server with an embedded Elasticsearch node inside it, and that combination is what makes it awkward to host. The embedded search node runs Elasticsearch's production bootstrap checks and refuses to start unless the host kernel's vm.max_map_count is at least 262144 — a sysctl no container on a managed platform is allowed to make. This template removes the requirement rather than the check, so the search node starts on an ordinary unprivileged container.

Two more things bite anyone hosting it by hand. SonarQube will not run a real instance on its embedded database, so PostgreSQL has to be attached and given storage of its own or every scan you have ever run disappears on the next deploy. And the server ships with a documented default administrator login that it does not force you to change — it answers the API, mints admin tokens and creates projects — so a fresh instance on a public URL belongs to whoever finds it first.

This template resolves all three. Postgres is attached with its own volume, the SonarQube service has a volume carrying its plugins and search index, the image is pinned by digest, and the administrator password is generated per deployment. The container refuses to start at all if that password is missing, so there is no path on which this comes up with the default login.

Memory: 2 GB minimum. Measured on this image: OOM-killed at 1 GB after 21 seconds, healthy at 2 GB, steady at roughly 1.8 GiB resident. Railway's Free (0.5 GB) and Trial (1 GB) per-service limits cannot run it — deploy on Hobby or above.

Why Deploy SonarQube Community on Railway?

Railway is a singular platform for deploying your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying SonarQube Community on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Specifically, the parts of SonarQube that are painful to self-host are the parts Railway handles: the Postgres instance is provisioned and networked privately alongside it, storage is attached rather than configured, TLS and a public hostname are given, and redeploying to a new version is a digest change instead of a migration weekend.

Common Use Cases

Quality gate in CI. Point sonar-scanner at the deployed URL with a project token and fail pull requests that introduce new bugs, vulnerabilities or uncovered code.
Security review of an inherited codebase. Run a first scan on a project you have just taken over and get a ranked list of injection risks, hardcoded secrets and unsafe deserialisation.
Tracking technical debt over time. Because history lives in Postgres on a volume, the trend lines survive redeploys and actually mean something a year later.
A private alternative to hosted analysis. Keep source code inside infrastructure you control rather than uploading it to a third-party SaaS scanner.
Monorepo hygiene. Separate projects per service, each with its own quality gate, on one server.

Dependencies for SonarQube Community Hosting

PostgreSQL — included in this template as its own service, with a persistent volume.
A volume on the SonarQube service for installed plugins and the search index.
At least 2 GB of memory on the SonarQube service.

Deployment Dependencies

Implementation Details

The administrator password is generated per deployment into SONAR_ADMIN_PASSWORD. On first boot the server's default administrator login is changed to it, after which the default is rejected. The step is idempotent, so a container killed part-way through the first boot simply retries on the next start, and if you later change the password yourself the template leaves it alone.

Log in as admin with the value of SONAR_ADMIN_PASSWORD from the service variables, then create a project and generate a token to point your scanner at it.