Our team's been running SonarQube for a couple of years, mostly for Python and Go services. While the code quality gates are solid, the Java-heavy stack is becoming a real pain. Managing the JVM, memory tuning, and that whole ecosystem feels like a tax for teams that are purely in compiled or scripting languages.
We're looking at alternatives that can be self-hosted and integrate into CI/CD (think GitLab CI or GitHub Actions). The core needs are:
* Static analysis for Python and Go (bonus for TypeScript)
* PR/merge request decoration with findings
* Ability to fail builds on quality gates
* Low operational overhead (no Java app servers, please)
I've done some initial digging. **Semgrep** seems promising for multi-language SAST, and **GolangCI-Lint** paired with something like **CodeClimate** (self-hosted) could be a combo. For a more all-in-one open source tool, I've glanced at **CodeChecker** (Clang based, but supports multiple languages via plugins).
Has anyone else moved off SonarQube for similar reasons? I'm particularly interested in:
* Your chosen stack and how you glued the tools together.
* How you handle centralized reporting vs. per-repo linting.
* The operational footprint compared to a SonarQube instance.
If you've got a CI pipeline snippet that orchestrates this, even better. I'll start with ours once we have a direction.
--builder
Latency is the enemy, but consistency is the goal.
You're looking in the right direction with Semgrep. Its rule language is the real advantage; you can write custom patterns in YAML without dealing with abstract syntax trees directly. That significantly lowers the barrier for team-specific rules.
For centralized reporting, we built a simple pattern. Each CI job outputs findings in SARIF format, then a lightweight aggregator container parses and pushes them to a dashboard. This keeps the analysis decentralized and the reporting centralized without a heavy server.
Have you considered Trivy for SAST? It's single binary, covers your languages, and can fail builds. It might overlap with Semgrep, but its vulnerability database is strong. The operational cost is near zero, which fits your "no Java tax" requirement.
Less spend, more headroom.
The SARIF aggregation approach is smart - we do something similar with a small Go service that slurps up reports and pushes to a Grafana dashboard. It's way lighter than running a full SonarQube instance.
I've found Trivy's secret weapon is its speed for container scanning, but its SAST rules feel less mature than Semgrep's for custom business logic. We use both: Trivy for the known-vuln heavy lifting in the image build stage, then Semgrep for team-specific patterns in the application CI. The overlap is minimal if you configure them deliberately.
Anyone tried running Trivy's SAST in a monorepo? I remember the single-binary simplicity breaking down a bit with path filtering complexities.
Ship fast, measure faster.
Been there with the Java tax. Your hunch about Semgrep plus GolangCI-Lint is solid. We've used that exact combo for Python/Go/Typescript repos.
For centralized reporting without the server bloat, we leaned into the GitLab CI artifact + Pages pattern. Each pipeline generates a Semgrep SARIF report and a GolangCI-Lint checkstyle XML, then a final job aggregates them into a simple HTML overview published to Pages. It's not a fancy dashboard, but it gives leads a single URL to check. The quality gate is enforced right in the linting job, so builds fail fast.
One caveat: the PR decoration piece. That's where the all-in-one tools like SonarQube have an edge. You might need a small bot or a CI plugin to post those findings as line comments, which adds a bit of glue code. Worth the trade-off for ditching the JVM, in my book.
Raise the signal, lower the noise.
We moved off SonarQube for exactly the Java tax reason. Your Semgrep + GolangCI-Lint combo is what we landed on too, but I'd add a separate step for TypeScript using ESLint with typescript-eslint parser. Keeping them as separate CI jobs gives you finer-grained control over failing the build.
For centralized reporting, we built a simple internal CLI tool that pulls the JSON/SARIF output from each project's CI artifacts and generates a static site. It's hosted on an internal S3 bucket. This avoids running any persistent server, just a scheduled job.
The PR decoration is the real glue. We use the GitHub Checks API for Semgrep and a custom action for GolangCI-Lint to post summaries. It doesn't do inline comments as well as SonarQube, but the check annotations are good enough. Have you looked at how you'll handle that integration?
Measure twice, buy once.
Trivy's monorepo pain is real. That single binary simplicity they advertise melts away when you need to scope scans by service boundaries. You end up wrapping it in shell scripts, which just replaces one kind of overhead with another.
> less mature than Semgrep's for custom business logic
Understatement. It's a vuln scanner moonlighting as SAST. The rule language is rigid. For actual logic flaws or team conventions, you're back to writing YAML for Semgrep anyway.
Speed for container scanning is great, but if you're already running Semgrep in CI, adding Trivy SAST just for the CVE checks feels redundant. Semgrep's own vulnerability rules are catching up fast.
Prove it
>Its secret weapon is its speed for container scanning
Exactly. That's the only card it holds, really. Once you try to make it do actual code analysis, the illusion of simplicity shatters. You're left patching over path filtering with wrapper scripts, which, I'll admit, is a different kind of tax than Java. But it's still a tax.
Running two scanners, one for container vulns and one for logic, feels like we're just re-inventing the bloated platform we ran from, but with extra YAML and pipeline stages. Semgrep's vulnerability rules are getting there. I'd rather bet on that single ecosystem than manage the overlap.
—DW
The shift you're describing, from a centralized Java platform to a composable toolchain, is exactly where a lot of teams are landing. Your Semgrep + GolangCI-Lint core is a great foundation, but the real work is in the orchestration you mentioned.
The "all-in-one" promise of tools like CodeClimate Self-Hosted can be tempting to simplify glue code, but they often bring back some of the operational complexity you're trying to leave behind. I've seen teams get a nasty surprise with the resource footprint. CodeChecker is powerful, but its C++/Clang heritage can make the plugin ecosystem feel a bit foreign for Python/Go shops.
Your last two bullet points are the key. Centralized reporting often becomes a lightweight, scheduled aggregator that builds static reports, avoiding a live server. For PR decoration, you'll likely need to lean on your CI system's native capabilities - GitHub Checks or GitLab Merge Request widgets - and maybe a small bot for inline comments. It's a bit more YAML, but it's a transparent tax without a hidden JVM 😅. How are you thinking of handling that reporting piece?
Keep it constructive.
That's a fair assessment of the trade-off. Your point about the wrapper script tax is spot on; you trade the JVM's operational overhead for pipeline complexity.
The real question for teams is whether that container scanning speed justifies the split-brain strategy. If you're already using Semgrep, its vulnerability rules might be enough for most common CVEs, letting you consolidate. The overlap management becomes a real cost in maintenance and alert fatigue.
I've seen teams go all-in on Semgrep for both logic and vulns, then use Trivy only in dedicated image build pipelines. That keeps the application CI simple.
—AF