TLDR overview
- Sonar Vortex gives coding agents your project architecture, coding rules and dependency guidance before they write, then checks every change they produce against the same context your CI pipeline already built.
- It runs inside self-hosted infrastructure, including air-gapped and VPC-restricted environments, so code does not leave your network to be guided or checked.
- It works with Claude Code, OpenAI Codex, GitHub Copilot CLI, Cursor and Google Antigravity, through the SonarQube CLI, a SonarQube agent plugin, or a locally running MCP server.
- Available as a separate subscription on Enterprise and Data Center editions, metered in tool calls, with an optional overage cap you set yourself.
Overview
Most teams running SonarQube Server already have software developers using coding agents. What they do not have is a way to say what standard those agents are working to.
Each AI agent gets its context from whatever instruction file somebody wrote months ago, or from nothing at all. It works out where things are by reading files, then reading more files, and every one of those reads is re-billed on every later turn of the conversation. The code comes back looking correct and fitting badly, and you find out at review, or after it ships.
Until now, closing that gap required your code to live in SonarQube Cloud. Sonar Vortex now runs on SonarQube Server, so teams that self-host for data residency, regulatory or policy reasons get the same two halves: guidance going in, and a check on the way out.
How does Sonar Vortex guide a coding agent?
An AI agent cannot follow a standard it was never given. Vortex supplies four kinds of context, drawn from your project rather than typed into a file by hand.
- Coding rules, selected for the task:
Not your whole rule set, but the rules that matter for what the agent is about to do, informed by the issues your project has actually had. If it is about to change a file with a history of resource-handling problems, it gets those rules. - Architecture:
The current architecture graph and the constraints your teams defined, so the agent builds the thing you intended rather than something that merely compiles. - Semantic navigation:
Instead of searching text and reading whole files to find its way, the agent asks for a symbol and gets that symbol with its relationships: what calls it, what it returns, what type owns it. Fewer blind reads, and fewer missed call sites. - Dependency health:
Whether a third-party library is safe to introduce or update, covering known vulnerabilities, supply-chain malware and license compliance, before it ends up in your lock file.
That last point about navigation is where the cost lives. An AI agent in a codebase larger than its context window navigates by searching and reading, and because the whole conversation is re-sent on every turn, a single unnecessary file read is paid for again and again. Published results put the saving at up to 36% lower token consumption.
How does Sonar Vortex check what the agent writes?
Guidance only gets you so far, because guidance is advice. The second half of Vortex checks the result.
Your CI pipeline already does the expensive work. When it analyses a project, SonarQube stores that project context: its dependencies, compiled artifacts, type information and build configuration, tagged by project and branch. When your agent edits a file, Vortex restores that stored context rather than recomputing it, and checks the change against it.
The result is a check with the same inputs as a full pipeline scan, returned in seconds rather than a build. It is not a lighter check that runs sooner. It is the same check, earlier, and it runs on the files the agent just touched without anyone asking for it.
Why running Sonar Vortex on SonarQube Server matters
Teams choose SonarQube Server for a range of reasons: data residency, compliance, or control over what leaves the network.
Guiding and checking an agent means reading the code it is working on, so where that happens is not a small detail. On SonarQube Server, Vortex runs inside infrastructure you already operate, including air-gapped and VPC-restricted environments. Your code does not go to Sonar.
There is a second reason that matters more at scale. One standard, applied the same way to every agent and every team, is the thing nobody can assemble out of instruction files. A file in a repository is advice that an agent may or may not read. The same quality profile that already decides what merges on your instance is something you can point at, report on, and show an auditor.
A Vortex dashboard reports adoption, coverage and impact across your instance. It starts empty and fills in as your developers install it.
How do I set up Sonar Vortex on SonarQube Server?
Sonar Vortex requires a separate subscription alongside SonarQube Server Enterprise or Data Center, metered in tool calls. A tool call is one use of a Vortex tool by an agent, such as retrieving your current architecture or analysing a file, and how many a task consumes depends on the size of the codebase, the difficulty of the task and the agent in use. If you want agents to keep working past your base allowance, you can activate overage and set your own monthly cap.
Setup spans three steps and three roles. An instance administrator adds Vortex to your license. A system administrator deploys the Vortex analysis component alongside SonarQube Server, with shared storage and a signing key. Then an instance administrator turns it on under Administration -> Configuration -> AI Capabilities -> Vortex.
Two things to check before you begin. Your SonarQube Server license has to be activated through LicenseSpring, online or offline, because Vortex is not available with a server ID-based license. And your reverse proxy or ingress needs to allow a request body large enough for analyzer context uploads.
Enabling Vortex does not configure anything on a software developer machine. Each developer installs it in their own AI agent using your instance URL, their own user token and the project key. Nothing reaches their agent until they do.
Want to see it in action? Join our session on October 14th for SonarQube Server 2026.5: The LTA release built to verify what your agents write to discover how this LTA delivers full verification and automated governance directly to your enterprise agentic development pipelines.