Technical debt cleared, not just tracked. Now inside your own infrastructure.

Most teams running SonarQube Server know exactly how much technical debt they have. The dashboard has been telling them for years. What they have never had is a realistic way to clear it.

Every quarter, the plan is the same. Dedicate a sprint to cleanup but roadmap work wins, and the count goes up.

Until now, all of this required your code to live in SonarQube Cloud. It now runs on SonarQube Server, so teams that self-host for data residency, regulatory or policy reasons get the same agent.

Finding the issues was never the hard part. SonarQube has been listing them for years, and the backlog only grows. The agent is the part that closes them, and it checks each fix against the same analysis that raised the issue before you ever see it.

You enable the agent in your organisation, point it at your SonarQube issues backlog, it generates a fix, applies it in a sandbox, then re-runs the same analysis engine that raised the issue in the first place. If the fix does not clear the issue, or if it introduces a new one, the fix is thrown away.

What you do see is a pull request. Your software developers review it and merge it, the same way they review anything else. Nothing reaches your codebase without a person approving it.

Pull requests arrive grouped by rule and file type. Assign twenty instances of the same rule in the same file type and they come back as one reviewable change rather than twenty.

Assign it yourself. Filter your Issues page for what the agent can fix, select what you want, and assign it. Useful for one rule, one project, or a push before an audit.

Put it on a schedule. Configure it at the organization or project level, pick daily or weekly, and cap how many pull requests you want per run. Then leave it alone.

Either way, the Agent activity page shows every job, running and finished, with status, duration, source, and the pull requests it opened. Everyone on the project can see it.

Teams choose SonarQube Server for a range of reasons: Data residency, compliance, or control over what leaves the network.

An agent that fixes code has to read that code first, so where it runs is not a small detail. On SonarQube Server, the Remediation Agent runs inside infrastructure you already operate, including air-gapped and VPC-restricted environments. Your code does not go to Sonar. It goes to the model endpoint you choose, and nowhere else.

You pick that endpoint. SonarQube Server supports AWS Bedrock and Azure AI Foundry, plus native Anthropic and OpenAI keys and custom gateways. If your organization has already decided where AI inference is allowed to happen, the agent fits that decision instead of asking you to make an exception to it.

The agent works with GitHub, GitLab and Azure DevOps.

C#, Java, JavaScript/TypeScript, and Python.

Inside those languages it handles maintainability, reliability, and select security issues, leaked secrets, and logic flaws found by the SonarQube Hunter Agent.

Three things to note:

SCA dependency remediation is on Cloud today, not yet on Server.
Pull request remediation is triggered from the SonarQube UI.
Verification re-runs Sonar's analysis. That confirms the issue is gone and no new Sonar issue appeared. It does not run your test suite, so your CI and your reviewers still do the job they do today.

The Remediation Agent is available on top of SonarQube Server Enterprise and Data Center editions, billed based on suggestions consumption.

Setup is three steps. Open the AI Capabilities section in your instance administration, connect your DevOps platform with the right permissions, and enable the agent.

Want to see it in action? Join our session on October 14th forSonarQube 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.