Most "best AI code review tools 2026" comparisons are written as if the forge were GitHub and the deployment model were cloud. For a team on GitLab Self-Managed, Azure DevOps Server or Bitbucket Data Center, that list falls apart at the point where you try to install something. The features are real, the edition is wrong.
The useful comparison for those teams is not a feature matrix. It is a deployment matrix, because the deployment model decides which entries on the feature list you can run at all. Below is what five tools document for their own supported platforms and editions, read from the vendor pages rather than from comparison posts.
The deployment model decides the shortlist
A vendor's capability page tells you what the reviewer can do. The deployment page tells you where that reviewer can run, and it is usually a separate page with a different answer.
Qodo makes this explicit with a per-provider deployment table that splits four models: multi-tenant, single-tenant, on-premises and air-gapped. The rows matter more than the checkmarks. GitLab Self-Managed is listed as single-tenant, on-prem and air-gapped, with multi-tenant marked out. Bitbucket Data Center is on-prem and air-gapped only, with single-tenant marked out as well.
That table is the single most useful artifact I have found for this beat, because it answers the question a self-managed team actually asks: can this thing run inside my network. Most tools do not publish the answer in one place.
Azure DevOps: Services, Server, and where each tool stops
Azure DevOps is two products with one name. Services is the cloud service (dev.azure.com). Server is the on-premises product, the rebranded TFS line, which is what most regulated and air-gapped teams actually run. Very few vendor pages separate them.
GitHub Copilot code review for Azure Repos is the clearest example of why that separation matters. Per Microsoft's own page for the feature, it is scoped to Azure DevOps Services, is in limited preview with no Service Level Agreement, and requires a linked Azure subscription because usage bills through Azure Cost Management. TFVC repositories are not supported. Enablement is three-scoped: a Project Collection Administrator turns it on for the organization, a Project Administrator handles project defaults and repository overrides, and a repository owner enables it per repo. Version control aside, there is no Server edition of this feature documented.
Qodo's table has a different shape for the same platform. Azure DevOps Cloud gets multi-tenant and single-tenant, and on-prem is marked out. That is a cloud-only path for Azure DevOps, which is a limitation worth knowing before you shortlist Qodo for an Azure DevOps Server migration.
CodeRabbit reaches Azure DevOps through two paths. The cloud quickstart lists Azure DevOps among the platforms you can connect with your existing account, and the self-hosted overview lists Azure DevOps among the platforms covered by the self-hosted agent. That second path is the one that matters for Server, because the agent runs inside your infrastructure and connects to the Git platform with a service account.
I wrote up the Services versus Server split in more detail in the Azure DevOps platform notes if you need the per-feature breakdown rather than the deployment view.
Self-managed GitLab and Bitbucket Data Center
GitLab Self-Managed is where the self-hosted options cluster, because the platform itself is designed to run inside your network.
CodeRabbit self-hosting covers GitLab self-managed directly. The gate is the license, not the platform: the self-hosted agent is Enterprise only, for customers with 500 or more user seats, ships as a container image you run on a server, a container platform or a serverless workload, and the deployment instructions are provided during onboarding rather than published. For a GitLab instance that cannot accept inbound connections, the CodeRabbit Reverse Tunnel keeps all connections outbound from your network. Code and pull request data stay inside your environment, and prompts and source leave it only to reach the LLM provider you configure.
Qodo's row for GitLab Self-Managed is the most complete in that vendor's table: no multi-tenant, yes single-tenant, yes on-premises, yes air-gapped. For an air-gapped GitLab instance, that is one of the few vendor-documented paths I can point to.
Bitbucket Data Center is the tightest of the three. Qodo lists it as on-prem and air-gapped only, with multi-tenant and single-tenant both marked out. CodeRabbit's self-hosted agent covers it. CodeRabbit's cloud quickstart also lists Bitbucket Data Center as a connectable platform, which is worth reading carefully, because the integration runs against your instance while the review runs in CodeRabbit's cloud. Which parts of the pipeline leave your network is the question to ask there, and it is different from the self-hosted case. I covered the native versus third-party breakdown of Bitbucket Data Center in what's native on Bitbucket Data Center and what isn't.
The open-source path, and what it asks you to run
For teams that cannot buy an Enterprise tier, the open-source option is the one that covers the widest set of providers. PR-Agent, now community-owned after Qodo donated it, states support for GitHub, GitLab, Bitbucket, Azure DevOps and Gitea, with deployment through CLI, Docker, self-hosted webhooks or CI. It runs on any model reachable through LiteLLM, which includes Ollama for a fully local setup. The repository also documents a Docker namespace migration: releases from 0.34.2 onward publish under pragent/pr-agent, and anything pinned to the older codiumai/pr-agent namespace is frozen at v0.31. If you are running it in a pipeline, that detail is the difference between a working upgrade and a broken one.
The trade is maintenance. You run the service, you hold the provider key, and you own the prompt configuration. I wrote up the PR-Agent self-hosted path across GitLab, Azure DevOps and Bitbucket separately, including the webhook and pipeline options per forge.
Kodus takes a third approach on licensing. Its pricing documentation puts self-hosting in the free Community tier as well as Enterprise, with reviews unlimited on every plan because the model runs on your own provider key through BYOK. The documented Git integrations are GitHub, GitLab and Bitbucket, and Azure DevOps is not listed. Teams that need a self-hosted reviewer for GitLab or Bitbucket can start on the free tier; a team on Azure Repos should treat Kodus as unavailable rather than as a candidate to evaluate. The same docs put Community at up to 10 rules and 3 plugins, and the 2,000 changed-file cap applies to any plan.
What each tool does with your team's rules
Rules are where a review tool either matches your standards or produces generic comments, so the mechanism matters as much as the label.
CodeRabbit offers path-based instructions on glob patterns plus AST-based instructions written with ast-grep, which lets you target structural code patterns instead of file paths. That is a meaningful distinction in a monorepo, where "all controllers" is easier to express as a syntax pattern than as a path.
Kodus documents rule file detection, which imports rule files you already have from other AI coding tools, along with directory-level settings for targeting folders in a monorepo and inheritance from global to repository to directory level. Kody Rules enforce a standard rather than suggest one, which is the part teams generally want when they say the reviewer should follow their conventions.
PR-Agent takes the simplest route: JSON-based prompt configuration you edit in the repository. It is flexible and entirely on you.
The comparison table
Everything here comes from the vendor pages linked above. Where a vendor does not state something for a platform, the cell says so rather than guessing.
| Tool | Azure DevOps | GitLab Self-Managed | Bitbucket Data Center | Self-hosted / air-gapped | Licensing gate |
|---|---|---|---|---|---|
| GitHub Copilot code review | Services only, limited preview, no SLA; Server not documented | Not stated | Not stated | Not stated for these forges | Azure subscription for billing |
| Qodo | Cloud only; on-prem marked out | Single-tenant, on-prem, air-gapped | On-prem and air-gapped only | Yes, per provider table | On-prem deployments run on your Kubernetes |
| CodeRabbit | Cloud connect and self-hosted agent | Cloud connect and self-hosted agent | Cloud connect and self-hosted agent | Yes, container image; Reverse Tunnel for private networks | Self-hosted is Enterprise, 500+ seats |
| PR-Agent (open source) | Yes | Yes | Yes | Yes, CLI/Docker/webhooks | None; community-maintained, you run it |
| Kodus | Not listed | Yes | Yes | Yes, Community and Enterprise | Free Community self-hosted; BYOK for models |
What to check before you shortlist
Two things decide more outcomes here than any feature comparison.
The first is whether the vendor's platform list includes the edition you run, not the product line. Azure DevOps appears on nearly every list. Azure DevOps Server appears on far fewer, and Copilot code review is documented as Services-only while Qodo's Azure DevOps row marks on-prem out. If you are on Server, those two entries drop off and the shortlist gets short fast.
The second is whether the review runs inside your network. A cloud connector pointed at a self-managed instance is a different security decision from an agent running on your own infrastructure, even when both get the same checkmark on a feature page. CodeRabbit's own documentation draws that line for you: the self-hosted agent keeps orchestration and results in your environment and sends prompts and source only to your configured model provider.
If you want the wider view of what exists per forge, I keep the free and self-hosted options for GitLab, Azure DevOps and Bitbucket in one place, and the CodeRabbit and Qodo self-hosted editions on their own criteria.
The shortlist for a self-managed forge is narrower than the general 2026 comparison suggests, and it is narrower for a reason you can verify on each vendor's deployment page rather than take on faith.
Top comments (0)